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-sizing-only.md

Recipe — `SIZING_ONLY`

Concrete instance class + node count + storage formula. Not a migration plan, not a full assessment, not a 9-section report. The user wants to know what to provision and why in as few words as possible.

When to dispatch here

Use this recipe when the user asks one of:

"What instance class should I use for X GB of data / Y QPS?"
"We have N nodes of r5.4xlarge on self-managed — what's the AOS equivalent?"
"Size this cluster for 200 GB of logs / 50M vectors at dim 768."
"How many r7g.large.search do I need for 80 GB indexed?"
"What's the right node count for <workload>?"

The hallmark: there is a workload to size, but no migration question, no schema paste, no 'should I use OpenSearch' framing. The user already chose AOS — they want a baseline today.

Detection signals

Signal	Example
Capacity ask without migration verbs	"size for", "provision for", "what should I run"
Specific scalar inputs	data volume in GB/TB, doc count, QPS, vector count + dim
Source cluster spec they want mapped	"we run 6 × `r5.2xlarge` today"
No `schema.xml`, no ES mapping, no "translate this query", no traffic-and-readiness mix	—
Vector-search collection sizing without ingestion-pipeline questions	"50M × 768 vectors"

If the user pastes an _cat/indices, traffic numbers, AND asks for a migration plan → that is FULL_ASSESSMENT, not SIZING_ONLY. If they ask "Managed vs Serverless" → COMPARATIVE_DECISION. If they ask "should I even use OpenSearch for 200 MB of Postgres rows" → ANTI_PATTERN_PUSHBACK.

Required output template

Produce exactly these four blocks. No headings beyond what is shown — keep the response tight.

1. Detected shape line (one sentence)

Detected shape: SIZING_ONLY — baseline for <source_size> <workload_type> on Amazon OpenSearch Service.

2. Baseline (one sentence + bullets)

Lead with a single concrete recommendation:

*Run 3 × r7g.large.search data nodes + 3 × m7g.large.search dedicated cluster managers across 3 AZs, 1 replica, EBS gp3 sized to <storage_number> GiB per data node.*

Then 3-5 bullets with numeric justification — instance choice rationale, replica setting, cluster-manager sizing rationale, storage rounding, AZ count.

3. Storage math (inline derivation)

ALWAYS show the formula and substitute numbers, even when inputs are estimated:

min_storage = source × (1 + replicas) × 1.45
            = 80 GiB × (1 + 1) × 1.45
            = 232 GiB total cluster storage
            ≈ 78 GiB per data node (3 nodes), round to 100 GiB gp3

If source data is unknown, present the tiered band instead (see below) — never invent a single number.

4. References (one line, max ~3 URLs)

References: bp-instances · bp-sharding · https://calculator.aws.

That's it. No other sections.

Match-source rule (CRITICAL)

When the user names their existing self-managed/EC2 cluster, match the source profile instead of falling back to a greenfield baseline:

6 × r5.2xlarge self-managed → recommend 6 × r7g.2xlarge.search (Graviton equivalent), not "3 × r7g.large is our default."
4 × m5.xlarge self-managed → recommend 4 × m7g.xlarge.search.
The customer has already proven their working set fits that RAM-to-data ratio. Downsize only if you can show the source was over-provisioned (e.g., JVMMemoryPressure consistently <40%).

Only fall back to "3 × r7g.large.search" greenfield baseline when the source size is <100 GB AND the user provided no source cluster.

Tiered band sizing (UNKNOWN inputs)

When source size is not specified, do NOT guess. Present three bands and ask the user to confirm:

Band	Source data	Suggested baseline	Notes
Small	<100 GiB	3 × `r7g.large.search` data + 3 × `m7g.large.search` cluster manager, 1 replica, gp3 100 GiB/node	Smallest prod-credible footprint
Medium	100–500 GiB	3 × `r7g.xlarge.search` data + 3 × `m7g.large.search` cluster manager, 1 replica, gp3 sized via formula	Most common SMB workload
Large	>500 GiB	6+ × `r7g.2xlarge.search` data + 3 × `m7g.large.search` cluster manager, OR1 if write-heavy logs	Consider OR1/UltraWarm tiering

Always close the tiered version with: "Confirm source size and I will collapse to one recommendation."

NOT REQUIRED — explicitly OMIT

Do NOT produce any of the following in a SIZING_ONLY answer:

Timeline & Resourcing — REMOVED FROM SUITE. Never write "engineer-weeks", "Phase 1 / Phase 2", "T+0 / T+30 days", or any sequencing language.
Executive Summary, Source Inventory, Target Topology, Migration Path, Readiness Checklist, Risk Register, Citations section, Open Questions.
Migration verbs: "cutover", "Historical Data Migration", "snapshot", "_reindex from remote", "Migration Assistant for Amazon OpenSearch Service".
Customer-specific trade-off narrative ("if your team prefers...", "if you have RIs in...").
Cost discussion beyond the calculator.aws link. Never write "$X/month".
JVM heap tuning advice (heap is service-managed; mention only in passing if the user asks).
Schema conversion, query DSL examples, FGAC setup.
Long instance-family compendium — pick one family and move on.

If the user asks for any of the above, route them: "That's outside SIZING_ONLY — for migration path see FULL_ASSESSMENT, for cost open https://calculator.aws."

Worked exemplar (~250 words)

User asks: "We have 80 GB of product-search data on a self-managed Elasticsearch 7.10 cluster running 4 × r5.xlarge. What should we run on AOS?"

Response:

Detected shape: SIZING_ONLY — baseline for 80 GiB product-search workload on Amazon OpenSearch Service, sized to match an existing 4 × r5.xlarge source.

Run 4 × r7g.xlarge.search data nodes + 3 × m7g.large.search dedicated cluster managers across 3 AZs, 1 replica, EBS gp3 at 80 GiB per data node.

Match-source: the existing 4 × r5.xlarge already proves the working set fits that RAM-to-data ratio; mapping to Graviton (r7g.xlarge.search) preserves the profile and gains ~20% price/perf.
Master nodes: required because data-node count ≥ 3; m7g.large.search × 3 covers up to 30 nodes / 15K shards on OS 2.17+ — well above this footprint.
Replicas = 1 (one primary copy + one replica); 3 AZs gives plain Multi-AZ (99.9% SLA). Multi-AZ-with-Standby (99.99% SLA) is NOT enabled here — it requires a multiple-of-3 data-node count and ≥ 2 replicas (see gotcha #19); this 4-node / 1-replica layout does not qualify. Re-shape to 3 (or 6) data nodes with 2 replicas if Standby is required.
Shards: for a search workload, target 10–30 GiB per shard. 80 GiB / 20 GiB → 4 primary shards, aligned to data-node count. Final layout: 4 primary × 2 (1 replica) = 8 shards across 4 nodes.
Heap is service-managed — sized automatically at 50% of RAM, capped at 32 GiB. Not a customer knob.

min_storage = source × (1 + replicas) × 1.45
            = 80 GiB × (1 + 1) × 1.45
            = 232 GiB cluster total
            ≈ 58 GiB per data node (4 nodes); round to 80 GiB gp3

References: bp-instances · bp-sharding · https://calculator.aws.

Pre-emit checklist (specific to SIZING_ONLY)

Tick every box before sending. If any box is unticked, fix the response — don't ship it.

[ ] First sentence is the shape declaration, not a greeting, not a restatement of the question.
[ ] Baseline is one sentence with instance class + count + AZ count + replica count + storage number.
[ ] Storage formula is shown with numbers substituted, not just stated abstractly. Even if source size is a band, at least one band has the math worked.
[ ] Match-source rule applied when user named their current cluster — Graviton equivalent of their current family at the same size, not a greenfield default.
[ ] Tiered bands used (and only used) when source size is genuinely unknown.
[ ] Cluster managers explicitly addressed — present when ≥3 data nodes or ≥10 indexes; called out as m7g.large.search × 3 (or larger per the cluster-manager-sizing table in sizing.md).
[ ] Current-generation Graviton by default (r7g/r8g family). r6g only with explicit user justification.
[ ] No dollar figures. Single calculator.aws link is the only cost reference.
[ ] No Timeline & Resourcing. No "engineer-weeks", no phased rollout, no "T+N days".
[ ] No migration content. No Historical Data Migration, snapshot, _reindex.remote, Migration Assistant for Amazon OpenSearch Service.
[ ] No 9-section scaffold. No Executive Summary, no Risk Register, no Readiness Checklist.
[ ] References footer is one line with at most three URLs (bp-instances, bp-sharding, calculator.aws).
[ ] Heap mentioned (if at all) as service-managed, never as a customer-tunable knob.
[ ] Total response ≤ ~300 words unless tiered bands forced expansion. If you wrote more, you drifted into FULL_ASSESSMENT — trim back.

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