Amazon Opensearch Service

AWSOfficialPublished by AWS

Skill
Workflow
Cloud and DevOps
Apache-2.0
Low risk

From the author

Guides migration, provisioning, search, log-analytics, trace-analytics, and Agentic AI Assistant workflows for Amazon OpenSearch Service and Serverless across six capabilities — migration (Solr/ES/self-managed into AOS/AOSS, schema/query translation, sizing, cutover); provisioning (domain + AOSS lifecycle, upgrades, FGAC, monitoring); search (vector / semantic / hybrid / RAG with Bedrock); log-analytics (PPL, OSI, anomaly detection, Dashboards); trace-analytics (OTel spans, service maps, Data Prepper); ai-assistant (natural language data exploration, incident investigation, root cause analysis). Triggers on OpenSearch, AOS, AOSS, Elasticsearch, Solr, vector/k-NN/semantic/hybrid search, RAG, log analytics, PPL, trace analytics, ISM, FAISS, HNSW, Migration Assistant, UltraWarm, OR1, query my data, analyze logs, investigate errors, root cause analysis.

— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a unified framework for interacting with Amazon OpenSearch Service (AOS) and OpenSearch Serverless (AOSS). It covers the full lifecycle of OpenSearch operations, including migration from legacy systems like Solr or Elasticsearch, infrastructure provisioning, advanced search implementation (including vector and RAG), and observability through log and trace analytics. It also features an Agentic AI Assistant for natural language data exploration and incident investigation, ensuring users can navigate complex cluster management and data analysis tasks without manual query crafting.

What it does

Guides migration workflows from Solr, Elasticsearch, or self-managed OpenSearch to AOS/AOSS.
Assists with provisioning, lifecycle management, and monitoring of domains and collections.
Facilitates implementation of vector, semantic, and hybrid search, including RAG with Bedrock.
Supports log and trace analytics using PPL, OpenTelemetry, and anomaly detection.
Provides an Agentic AI Assistant for natural language querying and automated incident root cause analysis.
Enforces operational best practices for sharding, storage tiering, and security configurations.

When to use it

When planning a migration from legacy search engines to Amazon OpenSearch Service.
When setting up or optimizing search capabilities, including vector search and RAG.
When troubleshooting cluster health, performance, or shard allocation issues.
When performing log or trace analysis to investigate system incidents.
When you need to generate optimized PPL or DSL queries using natural language.

Advantages

Centralizes complex operational knowledge across six distinct OpenSearch capabilities.
Reduces manual query complexity by leveraging the Agentic AI Assistant.
Provides clear, actionable guidance on production failure modes and migration blockers.
Standardizes interactions through consistent CLI and data-plane patterns.
Promotes architectural best practices for scaling and cost-effective storage tiering.

Usage examples

“How do I migrate my existing Solr index to Amazon OpenSearch Service?”: The agent identifies the migration capability, explains that Solr to OpenSearch is a refactor migration, and guides you through using the Migration Assistant for data backfill.
“Why is my cluster status yellow and how can I fix it?”: The agent uses the AI Assistant capability to analyze cluster health, check shard allocation, and provide specific commands or steps to resolve unassigned shards.
“Help me set up a RAG pipeline using Bedrock and my OpenSearch domain.”: The agent routes to the search capability, providing instructions on configuring Bedrock connectors and vector index mappings for semantic retrieval.
“Find the root cause of the 503 errors in my application logs from the last hour.”: The agent utilizes the AI Assistant to query logs, perform time-series analysis, and correlate findings to identify the likely root cause of the errors.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/aws/amazon-opensearch-service/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip amazon-opensearch-service.zip -d .agents/skills

Documentation by AWS

Amazon OpenSearch Service — the unified skill

This skill answers anything about Amazon OpenSearch Service or Serverless across six capabilities. Step 0 below routes the question to ONE capability and points at that capability's entry-point reference. Everything else — when to dispatch, sub-references, capability-specific facts, cross-capability links — lives in the entry-point reference for that capability.

AWS MCP server is recommended, not required. Capability references show standard AWS CLI commands as the primary syntax (e.g., aws opensearch describe-domain, aws opensearchserverless create-collection). Where the AWS MCP server is available, its call_aws tool offers a streamlined alternative — but every operation in this skill MUST work via the AWS CLI alone. Data-plane HTTP calls against AOS / AOSS use awscurl for SigV4-signed requests; this works in both contexts.

Step 0: detect the capability — first thing you do

Pick one of the six capabilities below. State the detected capability in your first sentence (e.g., "Detected capability: SEARCH — semantic search setup with Bedrock embeddings."). Then load the entry-point reference; that file describes when to dispatch, indexes the rest of the capability's files, and routes you to the next step.

Capability	Entry-point reference
migration — Solr / Elasticsearch / self-managed OpenSearch into AOS or AOSS. Schema/query translation, sizing, cutover.	`references/assessment-workflow.md`
provisioning — Provisioning and managing AOS domains and AOSS collections. Lifecycle, upgrades, storage tiers, FGAC, monitoring.	`references/provisioning-reference.md`
search — Vector / semantic / hybrid / sparse / dense / RAG retrieval. Bedrock connectors, FAISS HNSW vs Lucene.	`references/search-semantic-search-guide.md`
log-analytics — Log search, observability, PPL, OSI ingestion, anomaly detection, OpenSearch Dashboards. Splunk/Datadog/ELK alternatives.	`references/log-analytics-guide.md`
trace-analytics — Distributed traces with OpenTelemetry. Span queries, service maps, Data Prepper.	`references/trace-analytics-trace-queries.md`
ai-assistant — Agentic AI Assistant: auto-discovers indices, generates optimized PPL/DSL queries, summarizes results, and investigates incidents end-to-end. No manual query crafting needed.	`references/ai-assistant.md`

If a prompt spans capabilities (e.g., "migrate from Solr AND set up RAG on the new domain"), pick the dominant capability for the response and close with a one-line handoff to the other capability's entry-point ref.

Universal rules (apply to ALL capabilities)

These rules apply to every response, regardless of capability. Capability-specific rules (sizing math, shape detection, Migration Assistant for Amazon OpenSearch Service capability matrix, k-NN engine selection) live in the entry-point references, not here.

Report header (every multi-section response). Begin every multi-section response with a single fenced metadata block: > Generated: <ISO 8601 timestamp> | Skill: amazon-opensearch-service v<N>. Get the time by calling the current_time tool (returns ISO 8601 in UTC). Read the skill version from this file's frontmatter version: field. For one-line answers (terse FOCUSED_OPERATIONAL replies, anti-pattern refusals) the header is optional; for any multi-section deliverable it is REQUIRED. Place it immediately after the report title and before the first ## heading.
No dollar estimates (HARD CONSTRAINT). Never produce $X/month, ~$1,500, or any dollar figure. Route every cost question to https://calculator.aws and stop. If a sub-reference contains dollar figures, treat them as informational context only and do NOT pass them through to the user.
No credential leakage (HARD CONSTRAINT). Never include master usernames, KMS key ARNs, VPC endpoint URLs, instance IPs, or account IDs in generated output.
Pick one for every A-vs-B decision. Name a primary recommendation in one line with a one-sentence reason. A "go with B if..." caveat is allowed AFTER the primary; never lead with conditional-only guidance.
Source restatement. The first 2–3 sentences must restate the source (engine + version + scale) when known, or restate the customer's question in concrete terms. The very first text the user sees must NOT be tool narration, meta-commentary, the report title, or simply restating the question verbatim.
No marketing tone. Do NOT use "seamless", "robust", "best-in-class", "production-hardened", "enterprise-grade", "world-class", "cleanly", "elegant". Do NOT stack 3+ vague hedges ("typically", "generally", "usually", "in most cases") in a single recommendation — be specific about when it does and does not apply.
Cross-capability handoff. When a user prompt spans capabilities (e.g., "migrate from Solr AND set up RAG on the new domain"), pick the dominant capability for the response, then close with a one-line handoff: "For <other capability>, see references/<other-capability>-<entry>.md."

Cross-cutting references (used across multiple capabilities)

These references are not capability-prefixed because they apply across capabilities. Capability entry-point references load them when relevant; SKILL.md never loads them directly.

references/sizing.md — sizing math, instance family details, OR1 trade-offs, watermarks, JVM heap rules.
references/vector-knn.md — k-NN engines, memory math, RAG ingestion patterns, ELSER alternatives.
references/observability.md — log analytics patterns, ISM, UltraWarm/Cold tiering, Splunk/Datadog migration playbooks.
references/security.md — FGAC, encryption, VPC patterns, audit logs, compliance posture.
references/personas.md — communication style per persona.
references/assessment-gotchas.md — production gotcha catalog (cite by number in Migration specifics or Risks/blockers tables; each gotcha carries a Category: tag that determines its lane).
references/assessment-knowledge-retrieval.md — topic → tool → URL recipe for batched verification.

Assets (assets/): report templates for FULL_ASSESSMENT renderings (Solr-source, ES-source, executive summary).

What this skill does NOT do

Estimate dollar costs. Pricing changes monthly and account-specific (RI, Savings Plan, EDP) discount math is outside this skill's reliable scope. Use https://calculator.aws.
Move data. Use Migration Assistant for Amazon OpenSearch Service (Historical Data Migration for backfill, Live Traffic Migration for live cutover).
Build embedding models. Use Amazon Bedrock or SageMaker.
Replace Splunk SPL or Datadog APM 1:1. Some queries / detectors / dashboards need rewriting.
Tune relevance for a specific catalog. Use OpenSearch Benchmark big5 workload + your own judgment list.

Guardrail — where this skill's own files live (MCP vs local install)

This skill can be loaded two ways, and they resolve the skill's own bundled files from different places. Determine how the skill was loaded before reading a reference or running a script:

Loaded through the AWS MCP server's retrieve_skill tool: The skill is not installed on the local filesystem. You MUST fetch each reference or script via retrieve_skill with the file parameter (e.g. file="references/architecture.md" or file="scripts/deploy.py"), and run the script from the returned content. Do NOT file_read these paths locally — they do not exist on disk.
Installed locally (e.g. .kiro/skills/your-skill/ or ~/.claude/skills/your-skill/): Read and run files from the local skill directory using relative paths.

This distinction applies only to the skill's own packaged files. User data and session artifacts are always read from and written to the user's working directory. Never fetch or write customer data through retrieve_skill.

Files

ATTRIBUTION.mdAdded by AutoGineer930 B
LICENSELicence file added by AutoGineer9.9 KiB
NOTICELicence file added by AutoGineer67 B
SKILL.md9.2 KiB
assets/elasticsearch-gap-register.md5.1 KiB
assets/elasticsearch-index-template-skeleton.md4.2 KiB
assets/elasticsearch-report-template.md7.8 KiB
assets/executive-summary-template.md3.0 KiB
assets/report-template.md12.9 KiB
assets/solr-gap-register.md3.8 KiB
assets/solr-index-template-skeleton.md3.7 KiB
assets/solr-report-template.md5.9 KiB
assets/tech-deepdive-template.md6.2 KiB
references/ai-assistant.md18.0 KiB
references/assessment-gotchas.md17.1 KiB
references/assessment-knowledge-retrieval.md9.3 KiB
references/assessment-shape-anti-pattern-pushback.md10.4 KiB
references/assessment-shape-comparative-decision.md12.9 KiB
references/assessment-shape-focused-operational.md9.9 KiB
references/assessment-shape-full-assessment.md20.7 KiB
references/assessment-shape-overview.md12.1 KiB
references/assessment-shape-schema-conversion.md8.9 KiB
references/assessment-shape-sizing-only.md9.4 KiB
references/assessment-shape-translation.md12.3 KiB
references/assessment-workflow.md48.4 KiB
references/compatibility-rubric.md5.9 KiB
references/log-analytics-guide.md18.0 KiB
references/log-analytics-osi-pipelines.md8.6 KiB
references/log-analytics-troubleshooting.md1.6 KiB
references/observability-ppl-reference.md15.1 KiB
references/observability.md14.5 KiB
references/personas.md10.4 KiB
references/provisioning-agentic-setup.md4.8 KiB
references/provisioning-domain-deploy-search.md2.2 KiB
references/provisioning-domain-provision.md3.4 KiB
references/provisioning-monitoring.md3.4 KiB
references/provisioning-reference.md6.8 KiB
references/provisioning-serverless-agentic-setup.md14.9 KiB
references/provisioning-serverless-deploy-search.md6.7 KiB
references/provisioning-serverless-deprovision.md4.0 KiB
references/provisioning-serverless-provision.md8.8 KiB
references/provisioning-storage-tiers.md2.1 KiB
references/provisioning-troubleshooting.md8.0 KiB
references/provisioning-upgrades.md5.4 KiB
references/readiness-rubric.md3.4 KiB
references/search-bedrock-connectors.md3.8 KiB
references/search-dense-vector-models.md5.5 KiB
references/search-document-processing-guide.md7.7 KiB
references/search-evaluation-guide.md5.3 KiB
references/search-index-config.md2.4 KiB
references/search-recipes.md12.9 KiB
references/search-semantic-search-guide.md18.2 KiB
references/search-sparse-vector-models.md4.9 KiB
references/search-troubleshooting.md1.9 KiB
references/security.md9.3 KiB
references/sizing.md12.2 KiB
references/source-elasticsearch.md6.7 KiB
references/source-opensearch.md4.8 KiB
references/trace-analytics-trace-ingestion.md3.3 KiB
references/trace-analytics-trace-queries.md13.9 KiB
references/trace-analytics-troubleshooting.md1.6 KiB
references/vector-knn.md12.9 KiB

references/assessment-shape-full-assessment.md

Shape recipe: FULL_ASSESSMENT

Loaded by SKILL.md Step 0 when the prompt is rich enough to warrant a structured assessment report.

What this shape is

A full migration / adoption assessment with 9 named sections, a numeric readiness score (0–100, GREEN/YELLOW/RED), inline math derivations, ≥3 timestamped citations, ≥2 named gotchas, and a Next Steps handoff (concrete pointers to other skills, CLI commands, AWS docs, and the Pricing Calculator). Output is the longest of any shape in this skill — typically 800–2,000 words depending on artifact density. The customer is asking for something they could hand to a director, an architect, or a steering committee; not a one-liner.

This shape does not include Timeline & Resourcing (engineer-weeks, calendar weeks, or "phase 1 = 2 weeks"). That section was removed from the suite — see NOT REQUIRED below. Cost estimates are also omitted; route to https://calculator.aws.

When to dispatch here (detection signals)

Pick this shape when ≥2 of the following are true. If only ONE is true, prefer a more focused shape (focused-operational, schema-conversion, sizing-only).

Strong signals (any one is sufficient):

Phrases: "produce an assessment", "give me a full assessment", "complete migration plan", "end-to-end report", "write up a recommendation", "prepare a doc for my director / architect / VP".
Customer pasted ≥2 substantial artifacts: schema.xml + solrconfig.xml, _cat/indices + _cluster/health + _nodes/stats, or any combination of ≥40 lines of structured config.
Customer specifies workload context AND constraints AND a goal in the same prompt (e.g., "30 indexes, 4 TB, 8k QPS peak, GDPR, must finish before Q3, recommend the path").

Weaker signals (need a second one):

Mention of source engine + version + region + scale numbers (docs / GB / QPS).
Multiple personas implied ("for our DevOps and search-relevance teams").
Mention of compliance, SLA, or audit context (HIPAA, PCI, SOC2, FedRAMP, GDPR, multi-region DR).
Explicit ask for a readiness score, risk register, or gap analysis.

Counter-signals (do NOT dispatch here):

Question fits in one sentence with no artifacts → overview or focused-operational.
Single artifact, single ask (e.g., "map this schema") → schema-conversion.
Pure A-vs-B decision → comparative-decision.
Wrong-fit migration (Postgres + transactional + small) → anti-pattern-pushback.

Required output template

Begin with the report title (# Migration Assessment: <name>), then a single fenced metadata header showing the generated time and skill version, then the 9 sections.

Header (mandatory — placed immediately after title, before §1)

Call the current_time tool (returns ISO 8601 UTC) and read the skill version from the version: field in SKILL.md frontmatter. Emit:

> Generated: 2026-06-02T16:45:30Z | Skill: amazon-opensearch-service v1

If the current_time tool is unavailable, fall back to a placeholder <UTC ISO 8601> and call this out — never invent a timestamp.

9 sections

Produce these 9 sections, in this order, with these names. Each section header is a level-2 heading (##).

1. Executive Summary (3–5 bullets, ~80 words)

Source restatement (engine + version + scale) — first sentence.
Recommended target shape (Managed vs Serverless NextGen vs Classic) + recommended migration tool.
Readiness score with tier: e.g., 74/100 — YELLOW.
One named risk-blocker or top migration specific (cite gotcha # if applicable).
Pricing handoff line: "plug sizing into https://calculator.aws for monthly cost".

2. Source

A 4–8-row table: engine, version, post-fork status, total docs, total GB, index count, plugin/custom-lib count, fork-rule applicability. Mark UNKNOWN explicitly — do NOT invent values. If artifact density is rich, include a collapsible JSON fingerprint.

3. Target

Recommended deployment: Managed Multi-AZ-with-Standby / Managed Multi-AZ / Serverless NextGen / Serverless Classic. State the decision driver (e.g., "Multi-AZ-with-Standby because 99.95% SLA was named", "Serverless NextGen because <100 GB vector workload with bursty traffic"). Name the engine version target (OS 2.19 or OS 3.x) and the upgrade-path implication.

4. Migration Path

Frame the migration around the 3 components (see references/assessment-workflow.md § "Components of a migration"):

Historical Data Migration — required unless greenfield.
Live Traffic Migration — required only when the read-only window cannot cover the time HDM takes.
Application Code Rewrite — required for Solr → OpenSearch, X-Pack ports, language-binding swaps.

For each component the customer needs, pick ONE primary strategy in bold with a one-sentence reason, then a ranked table over the candidate strategies for that component:

Strategy	Score (0–10)	Pros	Cons

Apply the always-true rules from assessment-workflow.md (post-fork lockout, Migration Assistant for Amazon OpenSearch Service Solr-target restrictions, _source: false HDM-only, etc.). For ES ≥ 7.11 sources <100 GB with ≥30 min cutover window, the primary HDM strategy must be _reindex from remote — Migration Assistant for Amazon OpenSearch Service Historical Data Migration is overkill at that scale.

5. Sizing

Show math inline. Do not produce a single point estimate without a derivation chain. Example formula:

storage_gb_per_node = (raw_gb × (1 + replicas) × (1 + overhead_0.15) × (1 + headroom_0.25)) / data_node_count

Required outputs:

Compute: <N>× <instance_class> for data nodes (e.g., 6× r7g.2xlarge.search) — Graviton r7g/r8g default.
Cluster managers: 3× <instance> for ≥6 data nodes (e.g., 3× m7g.large.search).
Storage: GB per node + storage type (gp3 vs io2 vs Instance Store).
Shards: shard count derivation (target shard size 10–50 GB).
JVM heap implication: 50% RAM, capped at 32 GB. Cite OS 2.17+ shard-cap rule (gotcha #4) if shards/node trends >800.

If inputs are UNKNOWN, present 2–3 tiered bands (small / medium / large) — never invent a single point estimate.

6. Readiness

Numeric score 0–100, weighted breakdown across these 7 dimensions:

Dimension	Weight
Compatibility	25%
Operational readiness	15%
Sizing fitness	15%
Data movement complexity	15%
Cutover complexity	10%
Sizing-input completeness	10%
Stakeholder alignment	10%

Tier rule:

GREEN ≥80 — proceed; surface top items to flag in §7 (split across Migration specifics and Risks/blockers).
YELLOW 60–79 — run a PoC + spike on the lowest-scoring dimension before committing.
RED <60 — do not commit; weakest dimension first.

7. Risks & migration specifics

Two-table section. Citations into references/assessment-gotchas.md are by gotcha number (e.g., "#2 — ES ≥ 7.11 snapshot/restore lockout"). For Solr sources, prefer #1, #11, #12. For ES sources, prefer #2, #3. For vector workloads, prefer #7, #10.

Migration specifics — items with a known, well-trodden remediation. Frame these as "this is how the migration handles X", not as risks. The prescribed fix is part of the path, not a hazard. Each row: gotcha number, one-line spec, the remediation in concrete terms (config change, transformer flag, alternate tool). Most #11–#13 type items, and most "Solr → OpenSearch refactor" semantics items, belong here.

Risks / blockers — items that genuinely constrain the migration: no known fix, capacity-plan implications, irreversible target choices, or dependencies on customer action that can fail late. Each row: gotcha number, severity (HIGH / MEDIUM), what breaks if unaddressed, decision needed. #1 (Solr→OS document-level), #3 (Lucene 8→10 segment wall), #16 (uw.medium k-NN), and any "no equivalent on Serverless" items typically belong here.

Include ≥2 named gotchas across the two tables. Always reflect workload-specific trade-offs the customer mentioned in the prompt — do NOT recycle a generic list. If a gotcha has a clean remediation that the migration plan already includes, it belongs in Migration specifics, not Risks.

8. Next Steps

Concrete handoffs the customer can take to ACT on this assessment. Required if a migration path is recommended. Each next step MUST be one of:

Other AWS skill / capability to load when their next question lands in that domain. Mark with the aws- prefix when applicable. Examples:
- "For the post-migration sizing PoC, load amazon-opensearch-service shape SIZING_ONLY with measured peak QPS."
- "For deploying Migration Assistant for Amazon OpenSearch Service on EKS, route to the aws-eks skill."
- "For VPC + KMS-CMK setup, route to the aws-security skill."
- "For Bedrock Titan embeddings on the RAG side-pipeline, route to amazon-bedrock (capability: knowledge-bases-setup)."
Concrete AWS / OpenSearch CLI commands the customer should run next. Examples:
- "Run aws opensearch describe-domain-config --domain-name <name> to confirm the source target region."
- "Pull Migration Assistant for Amazon OpenSearch Service prerequisites with kubectl apply -f https://raw.githubusercontent.com/opensearch-project/opensearch-migrations/main/...."
- "Run GET /_cat/plugins?v on the source cluster to inventory plugins for the gap register."
AWS docs links to the canonical procedure for the chosen path (NOT for general background — those go in Citations). Examples:
- "Migration Assistant for Amazon OpenSearch Service — solution implementation: https://docs.aws.amazon.com/solutions/latest/migration-assistant-for-amazon-opensearch-service/solution-overview.html"
- "Cluster sizing best practices: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/bp.html"
AWS Pricing Calculator with the specific sizing inputs you derived. State "plug instance class + count + storage from §5 into https://calculator.aws" — not generic.
MCP / agent commands — if the user is operating an agent harness, surface relevant commands (e.g., "call the AWS MCP aws___get_regional_availability tool to verify r7g.2xlarge.search in us-west-2").

Format:

| # | Action | Pointer |
|---|---|---|
| 1 | Stand up Migration Assistant for Amazon OpenSearch Service on EKS | https://docs.aws.amazon.com/solutions/latest/migration-assistant-for-amazon-opensearch-service/solution-overview.html |
| 2 | Run sizing PoC | Load `amazon-opensearch-service` shape SIZING_ONLY with measured peak QPS |
| 3 | Plug sizing into Pricing Calculator | https://calculator.aws (use 6× r7g.2xlarge.search, 3× m7g.large.search, gp3 300 GB) |
| 4 | Provision security stack | Route to `aws-security` skill |
| 5 | Inventory source plugins | `GET /_cat/plugins?v` on source |

5–7 rows is typical. Each pointer is either a skill name, a CLI command in backticks, or a full URL. Generic "talk to your DevOps team" or "do testing" entries do NOT count — point at a specific resource.

9. Citations

≥3 entries. Each entry must include:

Source URL (full).
Retrieval timestamp (UTC, ISO-8601 — 2026-06-02T14:32Z).
One-sentence claim summary (what version-volatile fact you used it for).

Required URLs (pick the ≥3 you actually used): the AWS best-practices page for sizing math, the AWS upgrade-path page, the Migration Assistant for Amazon OpenSearch Service doc when Migration Assistant for Amazon OpenSearch Service is recommended, the Serverless NextGen comparison page when relevant, and https://calculator.aws for the cost handoff.

NOT REQUIRED — explicitly omit

Timeline & Resourcing — REMOVED FROM SUITE. Do NOT produce a "Phase 1 = 2 weeks" table, "engineer-weeks" estimates, "critical path = …" lines, or any calendar-based commitment. If you find yourself reaching for words like "timeline", "engineer-weeks", "resourcing", "calendar", "weeks of effort", STOP and delete the section. The customer will plan timeline using their own program-management practices.
Dollar / cost estimates. No $X/month, ~$1,500, ≈ $40k/year. Hard route to https://calculator.aws.
A 6-question business intake. This shape assumes the customer already gave you the artifacts. If you find yourself wanting to ask 6 questions, the shape was probably misdetected — re-route to overview.
Per-claim inline citations. Citations are batched in section 9.
Tool narration ("I will now check…", "Let me load…"). First sentence must restate source/version/scale.

Worked exemplar (~330 words)

Detected shape: FULL_ASSESSMENT — pasted schema.xml, solrconfig.xml, and traffic numbers; explicit "prepare a doc for our architect".
Migration Assessment: Acme Search Platform
Generated: 2026-06-02T16:45:30Z | Skill: amazon-opensearch-service v1
You're on Apache Solr 8.11 SolrCloud, 3 collections, ~120 M docs, ~600 GB on disk, ~2.5k QPS sustained / 8k peak, target Amazon OpenSearch Service in us-west-2 for a Search Relevance Engineer + DevOps audience — here's the assessment.
Executive Summary. Recommend Managed OpenSearch 2.19 Multi-AZ-with-Standby, migrated via Migration Assistant for Amazon OpenSearch Service Solr backfill (Historical Data Migration) — Solr → OS is document-level only (gotcha #1), and at 600 GB the single-shot _reindex path is too slow. Readiness 72/100 — YELLOW. Top blocker: 4 custom plugin JARs in <lib> directives need port. Plug sizing below into https://calculator.aws.
Source. Solr 8.11 · 3 collections · 120 M docs · 600 GB · <uniqueKey>doc_id</uniqueKey> · 4 custom JARs · q.op=AND · 2 <copyField> · NMSLIB-equivalent: N/A.
Target. Managed OpenSearch 2.19 Multi-AZ-with-Standby (the named 99.95% SLA forces Standby; OS 2.19 chosen because OS 3.x requires reindex of any pre-2.x indexes — already moot on a refactor migration, so 2.19 is the conservative landing). Upgrade to OS 3.x is in-scope post-cutover.
Migration Path. Migration Assistant for Amazon OpenSearch Service Historical Data Migration — primary (backfill the 600 GB), with Migration Assistant for Amazon OpenSearch Service Live Traffic Migration for the cutover window. _reindex from remote scored 4/10 (Solr is not a remote source). Snapshot/Restore scored 0 (no Solr→OS snapshot path).
Sizing. (600 × 2 × 1.15 × 1.25) / 6 = 287.5 GB/node → 6× r7g.2xlarge.search + 3× m7g.large.search cluster managers, gp3 300 GB/node. 18 primary shards × 1 replica ≈ 33 GB/shard (in target band). JVM 32 GB heap → shard cap 2,000/node (gotcha #4).
Readiness. Compatibility 18/25 (custom JARs −5, q.op −2). Operational 12/15. Sizing 14/15. Data movement 9/15 (Solr is document-level only — no segment-level path). Cutover 7/10. Sizing-input 6/10 (no peak ingest rate). Stakeholder 6/10. Total 72/100 — YELLOW.
Migration specifics. #11 — if the source solrconfig.xml sets q.op=AND, set default_operator: AND on every translated query_string handler. #12 — Migration Assistant's metadata transformer strips fielddata from text fields automatically and adds the .keyword subfield.
Risks / blockers. #1 Solr→OS is document-level, not segment-level (HIGH) — the 600 GB backfill goes via Migration Assistant Historical Data Migration, no snapshot path exists. Custom JARs require port to the OS plugin API (HIGH) — not supported on Serverless NextGen, so this constrains the target.
Next Steps. (1) Deploy Migration Assistant for Amazon OpenSearch Service on EKS — https://docs.aws.amazon.com/solutions/latest/migration-assistant-for-amazon-opensearch-service/solution-overview.html. (2) Port 4 custom JARs to OS plugin API. (3) Run sizing PoC — load amazon-opensearch-service shape SIZING_ONLY with measured peak ingest rate. (4) Plug 6× r7g.2xlarge.search + gp3 300 GB into https://calculator.aws. (5) GET /_cat/plugins?v on source to complete plugin inventory.
Citations. 3 URLs with retrieval timestamps follow.

Pre-emit checklist (specific to this shape)

Tick each before sending. If any box is unchecked, fix or restart.

[ ] Metadata header present immediately after title: > Generated: <ISO 8601 timestamp> | Skill: amazon-opensearch-service v<N> — timestamp pulled from current_time tool, version from SKILL.md frontmatter.
[ ] First sentence (after the header) restates source engine + version + scale + target region + persona.
[ ] All 9 section headers present, in order, named exactly as in this recipe.
[ ] Numeric readiness score (0–100) + GREEN/YELLOW/RED tier.
[ ] Math derivation shown inline in Sizing — no naked single-point estimates without a formula.
[ ] Graviton current-gen instances (r7g/r8g, m7g/m8g) — older families only with explicit justification.
[ ] Migration Path names the required components (Historical Data Migration / Live Traffic Migration / Application Code Rewrite — only those that apply), and for each, picks ONE primary strategy in bold + a ranked table of candidate strategies.
[ ] ≥2 named gotchas cited by number across §7 (Migration specifics + Risks/blockers; e.g., #2, #11).
[ ] ≥3 citations in section 9, each with URL + UTC timestamp + claim summary.
[ ] Customer-specific trade-offs in §7 (not a generic recycled list).
[ ] Items with a known fix routed to Migration specifics, not lumped under Risks/blockers.
[ ] Next Steps section (§8) present with 5–7 concrete pointers — each pointer is a skill name, a CLI command, an AWS docs URL, or https://calculator.aws with derived inputs. No generic "talk to your team" entries.
[ ] NO Timeline & Resourcing section, no engineer-weeks, no calendar weeks, no Phase 1 = X weeks.
[ ] NO dollar estimates; pricing handoff line points at https://calculator.aws.
[ ] No marketing tone ("seamless", "robust", "best-in-class", "production-hardened").
[ ] UNKNOWN inputs marked explicitly OR presented as tiered bands — no invented numbers.
[ ] If the target is OS 3.x crossing from any 1.x or 2.x source: the Risks/blockers half of §7 MUST cite (a) the Lucene segment wall — "Lucene 10 cannot read Lucene 8 segments — segment format is forward-only, so every pre-2.x index must be reindexed before reaching 3.x" — AND (b) at least one named OS 3.x breaking change beyond the segment wall: JDK 21 minimum runtime, Security Manager → Java agent migration for plugins, NMSLIB engine removal (forces reindex into FAISS), or renamed k-NN settings. Both items are required when crossing the 3.x boundary. (Plain transformer-handled items go in Migration specifics.)
[ ] If the response recommends an AOS in-place upgrade: the mechanism is named blue/green (the literal word) at least once. Do NOT describe it as a "long minor-version chain" or invent step-by-step minor hops (e.g., 2.5 → 2.7 → 2.9 → 2.11 → 2.19). AOS supports multi-version blue/green jumps within 2.x and within 3.x; the only mandatory waypoints are 1.3 (for sources < 1.3) and 2.19 (for any 1.x/2.x → 3.x crossing). State the ACTUAL hops the customer needs (typically two: source → 2.19 → 3.x, or source → 2.19 if already 1.3+), not a fake per-minor chain.
[ ] If the response recommends migration steps inline (FULL_ASSESSMENT shape): name the migration tool / strategy by its proper name in §4 — Migration Assistant for Amazon OpenSearch Service Historical Data Migration, Snapshot/Restore, _reindex from remote, OSI, in-place blue/green, etc. Do NOT punt with "see the migration capability" or "follow assessment-workflow.md" — those references are for YOUR own routing, not for the user. The user receives a self-contained Migration Path section.
[ ] If the prompt named ≥3 simultaneous hard constraints (e.g., zero-downtime + zero-data-loss + no-third-party-tooling + EU residency, or any 3+ from the constraint-trilemma list in assessment-shape-comparative-decision.md § 2.5): the Executive Summary AND § 4 Migration Path MUST explicitly name the constraint conflict and recommend a relaxation. Phrasing template: "At <scale>, constraints {X, Y, Z} are mutually inconsistent without compromise. Recommend relaxing <constraint> by <quantified trade-off> — this converts the problem to <tractable shape> and Migration Assistant <strategy> applies cleanly." Do NOT silently claim a single tool path satisfies all named constraints simultaneously — the response will fail if it asserts an impossible feasibility. If the proposed path uses dual-write, also include the dual-write reconciliation rule ("application-layer dual-write authored by your team is customer code, not third-party tooling").

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server

Security

What our scanner noticed· Low risk

Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

AWS

Publisher

AWS (Official)

Source

aws/agent-toolkit-for-aws · plugins/aws-data-analytics/skills/amazon-opensearch-service · commit 0a218f8

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
NOTICE (added by AutoGineer from NOTICE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

Also distributed in

aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download amazon-opensearch-service.zip