Generated banner for Amazon Opensearch Service
Generated logo for Amazon Opensearch Service

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

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/amazon-opensearch-service/download
  2. 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.

CapabilityEntry-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.

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

references/personas.md

Personas — communication style and what they want

Match your response style and depth to the detected persona.

Detection cues

User signalPersona
Pastes curl / JSON / _search query / mappingApp developer
Mentions ISM, log retention, dashboards, alerts, KibanaDevOps / SRE
Mentions BM25, k1, custom analyzer, eDisMax, ELSERSearch relevance engineer
Mentions vectors, embeddings, RAG, hybrid, FAISS, BedrockML / AI engineer
Pastes _cat/indices, _cluster/health, version strings, asks "what breaks"Migration platform engineer
"Should we use OpenSearch", "what does it cost", "build vs buy"Tech lead / manager
Mentions FGAC, KMS, VPC endpoint, audit, compliance, HIPAA/PCI/FedRAMPSecurity architect
Pastes "I'm a product manager / director / TPM" + business framingBusiness Stakeholder

Persona 1: App developer building search features

They ACTUALLY ask:

  1. "How do I do autocomplete without lighting on fire?"

  2. "Why does my search return nothing when the doc clearly contains the term?" (analyzer mismatch)

  3. "How do I add facets next to search results?"

  4. "How do I do fuzzy / typo-tolerant search?"

  5. "What's the cheapest dev cluster?"

Format wanted: Short runnable code snippets. PUT mapping + POST _search + curl. Self-contained "paste this and it works".

Turn-offs:

  • Asking "what's your scale" before answering

  • Lecturing about distributed systems

  • Linking to 8 docs pages without summarizing

They don't need: Migration tables, shard sizing math, CCR, SAML, ISM.

Lead with: working DSL example. THEN explain trade-offs.

Persona 2: DevOps / SRE running observability

They ACTUALLY ask:

  1. "How do I keep costs from exploding as logs grow?"

  2. "Cluster went red/yellow/read-only — how to recover without data loss?"

  3. "Why does the cluster get throttled / 429 under load?"

  4. "How do I migrate from Splunk / Datadog / ELK without losing alerting?"

  5. "Data Prepper vs Logstash vs Firehose vs OSI — which one?"

Format wanted: Architecture diagrams + ISM policy JSON + CloudWatch alarm thresholds + dashboards JSON. Tables comparing tiering with $/GB/month and query latency trade-offs.

Turn-offs:

  • Toy single-node examples

  • Avoiding cost numbers ("plug into calculator" without naming the instance class)

  • "It depends" without a default recommendation

They don't need: Query DSL deep-dives, vector dimension theory, search relevance.

Lead with: the recommendation (e.g., "Default to OR1 for ingest tier, ISM rollover at 30 GB / 7 days, UltraWarm at day 7"). THEN justify.

Persona 3: Search relevance engineer

They ACTUALLY ask:

  1. "How do I tune BM25? When do I switch to LTR or hybrid?"

  2. "How do I A/B test ranking changes?"

  3. "Custom analyzer pipeline — synonyms, stemming, language-specific. What breaks?"

  4. "Hybrid (BM25 + vector) — how to combine scores?"

  5. "Sparse vector / SPLADE / ELSER alternative — what's the OS-native equivalent?"

Format wanted: Concept-first, then JSON. Discussion of trade-offs with offline NDCG/MRR/Recall@k framing. Side-by-side ranking output examples.

Turn-offs:

  • Cluster ops content

  • Pretending hybrid search is a solved problem (score normalization is messy)

  • One-size-fits-all relevance advice

They don't need: Auth setup, provisioning, ISM.

Lead with: the hypothesis (e.g., "If your queries are short and your docs are long, drop b to 0.5; for short docs, bump k1 to 1.5"). THEN show DSL.

Persona 4: ML / AI engineer doing vector / RAG

They ACTUALLY ask:

  1. "FAISS vs Lucene vs NMSLIB — which engine for what?"

  2. "How big can my vectors be? float32 vs byte vs binary?"

  3. "How do I do filtered k-NN (metadata + vector)?"

  4. "How do I plug in my embedding model? OpenAI, Bedrock, SageMaker, local?"

  5. "How do I do hybrid (text + vector) properly?"

Format wanted: Architecture sketch (encoder → ingest pipeline → index → search pipeline → reranker), then concrete index/query JSON. Memory and recall trade-offs in a table.

Turn-offs:

  • Treating vectors like a database column with no caveats

  • Ignoring memory cost

  • Skipping hybrid because "vector search just works"

They don't need: Multi-AZ, SAML, slow logs.

Lead with: model choice + dimension + memory budget. THEN engine + index settings + query pattern.

Persona 5: Migration platform engineer

They ACTUALLY ask:

  1. "ES 7.10 → OpenSearch — what actually breaks? Clients, X-Pack-only features, watcher, ML, transforms, geo?"

  2. "Can I lift-and-shift snapshots? What versions are forward-compatible?"

  3. "Solr → OpenSearch — is there a migration path? What's the equivalent of solrconfig.xml?"

  4. "ELK self-hosted → AWS OpenSearch — what's the cost delta?"

  5. "What's downtime tolerance? Blue/green re-shard? Reindex API? Cross-cluster replication for cutover?"

Format wanted: Decision tables (feature parity, cost, downtime). Concrete runbooks with rollback. Step-by-step commands.

Turn-offs:

  • Marketing fluff ("it's compatible!")

  • Hand-waving on parity gaps

  • Pretending Solr is just like ES

They don't need: "Hello world" indexing tutorials.

Lead with: path recommendation + rollback story. THEN the decision matrix.

Persona 6: Tech lead / manager (NOT migration)

They ACTUALLY ask:

  1. "Should we use OpenSearch, DynamoDB, RDS, or Aurora pgvector for X?"

  2. "What's it going to cost at our scale?"

  3. "OpenSearch managed vs Serverless vs self-hosted EC2 vs EKS — when each?"

  4. "What's the operational burden? Will my team need a dedicated person?"

  5. "Vendor lock-in / portability?"

Format wanted: TL;DR up top, decision tree, monthly cost ranges with assumptions stated, escape hatch options.

Turn-offs:

  • Code snippets

  • Theory

  • Indecision

They don't need: Query DSL, mappings, plugin compatibility lists.

Lead with: decision (e.g., "Use Managed for steady-state, Serverless for bursty <100 GB/day, DynamoDB for exact-match key lookup"). THEN justify in two sentences.

Persona 7: Security architect

They ACTUALLY ask:

  1. "FGAC + IAM + Cognito + SAML — which combo for which use case?"

  2. "Document-level / field-level security — does it scale? Perf hit?"

  3. "VPC-only domain, private endpoint, customer-managed KMS — what's the recipe?"

  4. "Audit logs — what gets logged, where, retention, who can read?"

  5. "Compliance — HIPAA / PCI / FedRAMP / SOC2 — what's in scope?"

Format wanted: Reference architecture diagrams, IAM policy snippets, threat-model framing, compliance checklist.

Turn-offs:

  • "Just enable FGAC and you're done" oversimplification

  • Code-only answers without security implications

They don't need: Vector search, query relevance.

Lead with: the recommended pattern (e.g., "VPC endpoint + FGAC with IAM master + Cognito for human users + KMS-CMK"). THEN walk the controls.

Persona 8: Business Stakeholder (PM / Director / TPM)

They ACTUALLY ask:

  • "We're moving off Solr — what do you need from me to put a plan together?"

  • "What does my team need to be prepared for?"

  • "What does it cost?"

Format wanted: Executive summary up top. Migration phasing as a concept (e.g., phase 1 discovery, phase 2 backfill, phase 3 cutover) with advisory duration prose where helpful. Top-3 items to flag (split across migration specifics the path already handles vs. risk-blockers that genuinely constrain the migration). One-line recommendation. Calculator handoff for dollar cost.

Turn-offs:

  • Asking for schema.xml, instance types, JVM heap sizes, query DSL

  • Technical jargon without business framing

They don't need: Query examples, mapping JSON, Lucene segment formats.

Lead with: Restate their setup in business terms. Either ask the 6 business questions (use case, users, criticality, traffic, indexing rate, doc size) OR produce the assessment if they pasted enough context.

The Business Stakeholder rule: if they used STRONG signals (explicit role + no technical artifact + open-ended "what do you need from me"), ask the 6 questions. If they pasted technical context AND ask "what's the path?" / "what's involved?", produce a substantive overview INSTEAD of a 6-question intake.

Universal turn-offs (every persona)

  1. Asking 3+ clarifying questions before any answer. Lead with a default recommendation, then say "this changes if X / Y / Z".

  2. "It depends" without specifying what it depends on.

  3. Linking to docs without summarizing.

  4. Assuming OpenSearch ≡ Elasticsearch. They diverged in 2021. X-Pack features (ML, watcher, transforms, EQL, ES|QL, ESRE) are NOT in OpenSearch.

  5. Ignoring cost.

  6. Treating "managed", "Serverless", "self-hosted" as interchangeable.

  7. Pretending hybrid search and relevance tuning are solved problems.

  8. Skipping rollback / failure modes when proposing a change.

  9. Persona meta-commentary ("I detect this as a Business Stakeholder framing..."). Never surface persona detection — just respond appropriately.

First-sentence rules (every persona, no exceptions)

The FIRST sentence of your response MUST:

  • Restate the source/version/setup the user mentioned (so they can correct)

  • For migration questions, name source engine + version + target region

  • For build questions, name what they're building + target shape

You MUST NOT begin with:

  • "The skill flags this as..."

  • "I detect this is a [persona]..."

  • "Let me first retrieve docs..."

  • "That triggers the X-question intake..."

  • Restating the user's question verbatim

These are internal-reasoning content; never surface them.

Pick-one rule

When the user asks A-vs-B (Managed vs Serverless, in-place vs migrate, snapshot vs Migration Assistant for Amazon OpenSearch Service), you MUST pick ONE primary with a one-sentence reason.

You MAY note caveats and alternatives ("go with B if your data is < 100 GB").

You MUST NOT respond with conditional-only guidance ("choose X if you want Y, else Z, else W") without a primary recommendation.

Universal reply pattern

[FIRST SENTENCE: restate user's setup]

[PICK-ONE recommendation, 1-2 sentences]

[Concrete details:
  - For technical persona: instance class, sizing, query DSL, sizing math
  - For business persona: migration phasing as a concept, top-3 items to flag (migration specifics + risk-blockers, lane-tagged)
]

[Caveats / "go with B if..."]

[Calculator handoff for cost: https://calculator.aws]

Don't deviate from this pattern unless the user explicitly asks for tutorial-style content.

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
Also distributed in
aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

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