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-gotchas.md

Gotchas — production failure modes

The traps experienced practitioners hit on Amazon OpenSearch. Each one is a real failure mode that silently breaks plans. Cite by number when the profile matches.

Each entry carries a **Category:** tag that determines which lane it surfaces under in the FULL_ASSESSMENT §7 split (and which assets it deducts from in readiness-rubric.md):

Category	Meaning	Lane in §7
`TRUE_BLOCKER`	No clean fix; constrains target choice or forces rearchitecture. Deducts from Compatibility weight.	Risks/blockers
`MIGRATION_SPECIFIC`	The migration plan already includes a documented remediation (transformer, sanitizer, config override). Does not deduct unless customer action is required.	Migration specifics
`OPERATIONAL_CONSIDERATION`	Default-behavior thing to know about; affects sizing or operations rather than correctness.	Risks/blockers (when actionable) or Migration specifics (when path-handled). Use judgment.
`COST_TCO`	Pricing/billing trap that affects TCO model accuracy but doesn't block the migration.	Migration specifics — reframe the TCO model.
`CLARIFICATION`	The gotcha is "the customer's claim is wrong / ambiguous"; resolution is pre-work, not a remediation.	Surface as a question, not in either §7 lane.

1. Solr → OpenSearch is document-level, NOT segment-level

Category: TRUE_BLOCKER

There is NO snapshot path between Solr and OpenSearch — different codecs, schema layouts. Schema, queries, configs all need translation.

Detect: "lift and shift Solr to OpenSearch", "snapshot Solr" Fix: State explicitly that this is a refactor migration. Use Migration Assistant for Amazon OpenSearch Service Solr backfill (Historical Data Migration) or document-level export+bulk for small datasets.

2. ES ≥ 7.11 snapshot/restore is NOT supported on AOS

Category: TRUE_BLOCKER

ES 7.11+ relicensed to ELv2/SSPL (Jan 2021). Snapshot/Restore from those versions to Amazon OpenSearch Service is NOT supported.

Detect: ES version ≥ 7.11 in source fingerprint; customer plans snapshot path Fix: Use Migration Assistant for Amazon OpenSearch Service Historical Data Migration, or _reindex from remote for small datasets (<100 GB).

3. Lucene 8 → 10 segment-format wall at OS 3.0

Category: TRUE_BLOCKER

OS 3.x ships Lucene 10. Pre-2.x indexes carry Lucene 8 segments. Lucene's segment format is forward-only — Lucene-10 cannot read Lucene-8.

Detect: OS 1.x source upgrading to OS 3.x; ES 7.10 indexes; any pre-OS 2.0 indexes Fix: Reindex affected indexes before upgrading to OS 3.x. Applies to hot, UltraWarm, and cold storage.

4. Per-node shard cap

Category: OPERATIONAL_CONSIDERATION

Detect: shard count > 800/node trending up. Fix: see sizing.md §Topology defaults for current cluster-manager + shard-cap values; source of truth is bp.html#bp-sharding. Architectural rule: Multi-AZ-with-Standby clusters cap at 1000/node regardless of OS version.

5. Cold storage is NOT directly queryable

Category: OPERATIONAL_CONSIDERATION

Cold storage holds detached indexes — must reattach to UltraWarm before querying. Migration is one index at a time, queue depth 100. Watch WarmToColdMigrationQueueSize.

Detect: "occasional queries on archived data" Fix: Accept warm-up latency (minutes-to-hours), keep data in UltraWarm permanently, or use S3+Athena for true on-demand archives.

6. Serverless redundancy adds an OCU floor

Category: COST_TCO

Architectural rule: Redundancy ON adds an idle OCU floor (separate indexing + search minimums billed continuously).

Detect: Bursty/low-volume customer thinking "I'll only pay for what I use" Fix: For current OCU minimums, see sizing.md §OCU model and serverless-scaling.html. For tiny non-prod workloads, consider small Managed t3.medium.search. NEVER t2.* or t3.small.search in prod.

Category: COST_TCO

Architectural rule: a vector search collection can't share OCUs with search and time series collections, even with same KMS key. Adding one vector collection adds a separate idle floor.

Detect: Mixed keyword + vector workload; user assumes one bill Fix: For current OCU minimums, see sizing.md §OCU model and serverless-scaling.html. If vector is exploratory, run k-NN on existing Managed cluster instead.

8. Serverless ignores most user-supplied index settings

Category: MIGRATION_SPECIFIC

Number of shards, intervals, refresh interval are NOT modifiable on Serverless. index.translog.* and index.routing.allocation.* are dropped. Cannot restore a snapshot to Serverless directly.

Detect: Plan involves restoring an existing snapshot to Serverless Fix: Use Migration Assistant for Amazon OpenSearch Service's metadata-migration Serverless sanitizer, or hand-strip settings before bulk. Re-validate post-load with GET <idx>/_settings.

9. NextGen TIME_SERIES does NOT exist

Category: TRUE_BLOCKER

NextGen Serverless supports only Search and Vector Search types. TIME_SERIES is Classic-only.

Detect: Customer wants time-series collection AND mentions "NextGen" Fix: Use Classic for TIME_SERIES; or use Managed Domain with ISM-managed time-series indexes (often a better fit at scale).

10. NMSLIB removed in OS 3.0

Category: TRUE_BLOCKER

Detect: source uses NMSLIB engine, target is OS 3.x. Fix: reindex into FAISS HNSW or FAISS IVF before the 3.x upgrade. Engine matrix and reindex recipe live in vector-knn.md; source of truth for current engines is knn.html.

11. `q.op=AND` divergence (Solr → OpenSearch)

Category: MIGRATION_SPECIFIC

Solr defaults q.op=OR; if user sets AND, OpenSearch defaults must explicitly match. OpenSearch's default operator on query_string is OR.

Detect: Solr source with <q.op>AND</q.op> or eDisMax with q.op=AND in solrconfig.xml Fix: Set default_operator: AND on query_string, OR operator: AND on match. Most common cause of result divergence.

12. `fielddata: true` on text fields will OOM data nodes

Category: MIGRATION_SPECIFIC

Pre-ES 2.0, text fields used in-memory fielddata for sort/agg. ES 1.x mappings still carry "fielddata": true and will OOM AOS data nodes on first aggregation.

Detect: Source = ES 1.x or 2.x; mapping JSON contains fielddata Fix: Strip fielddata. Add a .keyword subfield: "title": {"type":"text", "fields": {"keyword": {"type":"keyword"}}}. Migration Assistant for Amazon OpenSearch Service transformer does this automatically; hand-rolled _reindex MUST do it explicitly.

13. ES 7 → OS 1 `_type` removal

Category: MIGRATION_SPECIFIC

ES 7 still allows the placeholder type _doc; OS 1.0 removed types entirely. Templates with "_doc": {...} blow up _reindex/_bulk with [mapper_parsing_exception] unsupported parameters: [_doc].

Detect: ES 7 source with index templates Fix: Migration Assistant for Amazon OpenSearch Service metadata transformer, OR pre-flatten with jq 'del(.mappings._doc) | .mappings = .mappings._doc' template.json.

14. NAT Gateway charges silently inflate VPC OpenSearch bills

Category: COST_TCO

A private cluster fetching plugins, Bedrock embeddings, IDP metadata, or external knowledge sources accumulates NAT-Gateway charges. NAT Gateway charges per VPC pricing.

Detect: Private VPC cluster with external integrations Fix: Use VPC endpoints for S3, Bedrock, STS, OpenSearch Service. Project residual NAT egress per VPC pricing.

15. Manual snapshots bill against YOUR S3 bucket

Category: COST_TCO

AOS automated snapshots: kept 14 days (hourly, up to 336), no additional charge, in AOS-preconfigured bucket. Manual snapshots: stored in YOUR S3 bucket at standard S3 rates plus PUT charges.

Detect: Compliance retention > 14 days; cross-region snapshot requirements Fix: Add S3 line to sizing model: data_size × retention_days / 30 × $/GB-mo plus PUT cost.

16. UltraWarm `uw.medium` cannot host k-NN indexes

Category: TRUE_BLOCKER

The instance lacks RAM headroom to hold k-NN graphs.

Detect: k-NN indexes scheduled for UltraWarm migration on uw.medium Fix: Use ultrawarm1.large.search instead. For current UltraWarm RAM-per-instance figures and circuit-breaker sizing, see ultrawarm.html.

17. OR1 trades RAM-bound aggregations for indexing throughput

Category: OPERATIONAL_CONSIDERATION

OR1 stores segments in S3 with local NVMe cache. ~2× r6g indexing throughput, replica=1 sufficient (S3 durable). Loses to r-family on cache-miss aggregations and k-NN graphs (RAM-bound).

Detect: k-NN, large-cardinality aggs, or cache-miss-sensitive workloads on OR1 Fix: Use OR1 only when peak_indexing × avg_doc_size > 50 GB/day/node. Use one replica unless durability model demands more. Migration to OR1 is irreversible.

18. Cluster goes read-only at flood-stage watermark (95%)

Category: OPERATIONAL_CONSIDERATION

When any node hits 95% disk, AOS applies index.blocks.read_only_allow_delete: true to all indexes with shards on that node. Releases automatically when below high (90%).

Detect: Cluster size near 90%; observability indexes growing fast Fix: Alert on FreeStorageSpace < 25 GB or storage > 80%. Add storage / shrink shards / move data to UltraWarm BEFORE this hits.

19. Multi-AZ ≠ Multi-AZ with Standby

Category: CLARIFICATION

Multi-AZ: 99.9% SLA. Multi-AZ with Standby: 99.99% SLA. Standby pre-positions one zone as inactive, sub-minute failover. Standby requirements: 3 AZs, 3 dedicated cluster managers, 3 (or multiple of 3) data nodes, ≥2 replicas, Auto-Tune ON, GP3 storage.

Detect: Customer expects "no downtime ever" without Standby Fix: Recommend Multi-AZ-with-Standby for tier-1 production. Standby is "available at no extra cost" but applies caps on per-shard size and total cluster shard count. For current Standby caps, see managedomains-multiaz.html.

20. Logstash default distro license check rejects OpenSearch

Category: MIGRATION_SPECIFIC

Default Logstash distro has Elastic license check that rejects OpenSearch. Two workarounds:

Detect: Customer using Logstash with new Amazon OpenSearch destination Fix: Use OSS distro of Logstash (Apache 2.0) OR logstash-output-opensearch plugin. Better: switch to OpenSearch Ingestion (managed Data Prepper) or Fluent Bit.

21. Cross-AZ data transfer is FREE within AOS clusters

Category: COST_TCO

Self-managed Elasticsearch on EC2 across AZs pays cross-AZ data-transfer at the standard regional rate for primary→replica replication. Amazon OpenSearch Service does NOT bill for intra-cluster cross-AZ replication.

Detect: Customer's current TCO model includes a cross-AZ line item for self-managed ES replication Fix: Call this out as a savings the migration unlocks. Cross-AZ data transfer between customer-owned resources (e.g., app tier ↔ AOS endpoint, or NAT Gateway egress) is still billed normally.

22. AOS-managed gp3 storage is priced separately from raw EBS gp3

Category: COST_TCO

The exact AOS-managed gp3 list price (volume + baseline IOPS + service overhead) is published on the AOS pricing page, NOT the raw EBS rate. TCO calculators reusing raw EBS underestimate.

Detect: Customer-built TCO calculator uses raw EBS rates Fix: Plug AOS-managed gp3 rate from https://calculator.aws into customer's TCO model. RI / Savings Plan / EDP discounts apply only there.

23. Cluster manager sizing scales with cluster size

Category: OPERATIONAL_CONSIDERATION

Architectural rule: 3 dedicated cluster managers (formerly "master node"), odd quorum. NEVER 1, 2, 4, or 5.

Detect: Cluster scaling beyond 30 nodes; shard count growth Fix: For current cluster-manager sizing (heap-to-nodes / shard tier), see sizing.md §Topology defaults.

24. Migration from Managed → Serverless requires reindex

Category: MIGRATION_SPECIFIC

There is NO automatic migration from Managed Domain to Serverless. Must reindex.

Detect: Customer wants "easy switch" from Managed to Serverless Fix: Plan a reindex migration. Use Migration Assistant for Amazon OpenSearch Service or _reindex from remote. Validate sizing on Serverless before cutover.

25. Authentication complexity is the #1 setup blocker

Category: OPERATIONAL_CONSIDERATION

Forum data: 60%+ of new-user issues are auth-related. FGAC + IAM + Cognito + SAML + master-user combinations have many failure modes.

Detect: Any auth question; first-time AOS user Fix: See security.md for the FGAC + IAM + Cognito + SAML decision tree. Common pattern:

Internal users only → IAM SigV4 from app
External / human users → Cognito user pool + FGAC mapped to Cognito groups
Enterprise SSO → SAML to FGAC backend role mapping

26. ELSER is proprietary to Elastic — not on Amazon OpenSearch

Category: TRUE_BLOCKER

Don't promise ELSER on AOS. Use neural sparse search with SageMaker-hosted SPLADE/equivalent, or dense vectors via Bedrock Titan / Cohere.

Detect: Customer asks for ELSER on AOS Fix: Recommend neural_sparse query with SageMaker-hosted sparse encoder, OR hybrid (BM25 + dense vectors). Most ELSER use cases work fine with hybrid.

27. Painless scripts not supported on Serverless

Category: TRUE_BLOCKER

Inline scripts work on Managed but not Serverless. If customer relies on script_score, script_fields, or update-by-script, they need Managed.

Detect: Customer mentions Painless / script_score / scripted fields with Serverless target Fix: Move to Managed, OR rewrite scripted logic into ingest pipeline / search pipeline / function_score.

28. ES Runtime fields have only partial parity in OpenSearch

Category: TRUE_BLOCKER

OpenSearch added "derived fields" in 2.15 — limited functionality compared to ES Runtime fields. Not full parity.

Detect: ES source heavily uses Runtime fields; OS target Fix: For each Runtime field, decide: (a) pre-compute at ingest, (b) use derived fields if simple, or (c) move logic to query-time scripted fields (Managed only).

29. ILM JSON does NOT import as ISM

Category: MIGRATION_SPECIFIC

Elasticsearch ILM and OpenSearch ISM are conceptually similar but JSON formats differ. Must rebuild policies.

Detect: Customer has many ILM policies and assumes they "just work" on OS Fix: Translate each ILM policy to ISM. Common patterns: rollover, force_merge, warm/cold migration, delete. AWS-specific ISM operations: warm_migration, cold_migration, cold_delete.

30. AOS automated snapshots are NOT a backup strategy

Category: OPERATIONAL_CONSIDERATION

See #15 (canonical) — automated snapshots are kept only 14 days and are not a DR strategy.

Detect: Customer plans to "use automated snapshots for DR" Fix: See #15. Set up manual snapshots to your own S3 bucket with appropriate retention; build a cross-region snapshot strategy if DR is in scope.

31. FAISS HNSW IS supported on Serverless Vector Search

Category: CLARIFICATION

Architectural rule: FAISS HNSW is the underlying engine on BOTH Serverless Vector Search collection types (NextGen and Classic). The difference is configurability, not support. Saying 'FAISS HNSW is unavailable on Serverless' is WRONG.

For the per-config breakdown of NextGen vs Classic Vector Search (which engines/parameters each surfaces, what pins a workload to Managed Domain), see vector-knn.md.

Detect: Customer claims FAISS HNSW is unavailable on Serverless; vector workload routing decision Fix: Affirm FAISS HNSW availability on both Serverless Vector Search variants. Use vector-knn.md to decide whether the workload pins to Managed Domain.

32. OS 1.x version line

Category: CLARIFICATION

There is NO OS 1.7 GA release. OS 1.x had GA releases up through 1.3. For the current canonical version list, see version-migration.html.

If a customer says 'OS 1.7' they likely mean:

Elasticsearch 1.7 (different product, pre-fork era), OR
Misremembered OS 1.3 (the latest 1.x), OR
Confusion with a 2.x or 3.x version

Clarify before proceeding with upgrade plan.

Detect: Customer cites "OS 1.7" or any OS 1.x version above 1.3 Fix: Confirm the actual source version (ES 1.7 vs OS 1.3 vs OS 2.x/3.x) before scoping the upgrade. The Lucene-segment-format wall (#3) and other version-specific gotchas hinge on knowing the true source.

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

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by AWS

Amazon OpenSearch Service — the unified skill

Step 0: detect the capability — first thing you do

Universal rules (apply to ALL capabilities)

Cross-cutting references (used across multiple capabilities)

What this skill does NOT do

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

Files

references/assessment-gotchas.md

Gotchas — production failure modes

1. Solr → OpenSearch is document-level, NOT segment-level

2. ES ≥ 7.11 snapshot/restore is NOT supported on AOS

3. Lucene 8 → 10 segment-format wall at OS 3.0

4. Per-node shard cap

5. Cold storage is NOT directly queryable

6. Serverless redundancy adds an OCU floor

7. Vector Search collections cannot share OCUs with Search/TimeSeries

8. Serverless ignores most user-supplied index settings

9. NextGen TIME_SERIES does NOT exist

10. NMSLIB removed in OS 3.0

11. q.op=AND divergence (Solr → OpenSearch)

12. fielddata: true on text fields will OOM data nodes

13. ES 7 → OS 1 _type removal

14. NAT Gateway charges silently inflate VPC OpenSearch bills

15. Manual snapshots bill against YOUR S3 bucket

16. UltraWarm uw.medium cannot host k-NN indexes

17. OR1 trades RAM-bound aggregations for indexing throughput

18. Cluster goes read-only at flood-stage watermark (95%)

19. Multi-AZ ≠ Multi-AZ with Standby

20. Logstash default distro license check rejects OpenSearch

21. Cross-AZ data transfer is FREE within AOS clusters

22. AOS-managed gp3 storage is priced separately from raw EBS gp3

23. Cluster manager sizing scales with cluster size

24. Migration from Managed → Serverless requires reindex

25. Authentication complexity is the #1 setup blocker

26. ELSER is proprietary to Elastic — not on Amazon OpenSearch

27. Painless scripts not supported on Serverless

28. ES Runtime fields have only partial parity in OpenSearch

29. ILM JSON does NOT import as ISM

30. AOS automated snapshots are NOT a backup strategy

31. FAISS HNSW IS supported on Serverless Vector Search

32. OS 1.x version line

Requirements and compatibility

Security

Attribution and licence

Related skills

Modal

Cloud Infrastructure Network Engineer

Deployment Validation Cloud Architect

Airflow Dag Patterns

Cost Optimization

Hybrid Cloud Networking

Download ZIP

11. `q.op=AND` divergence (Solr → OpenSearch)

12. `fielddata: true` on text fields will OOM data nodes

13. ES 7 → OS 1 `_type` removal

16. UltraWarm `uw.medium` cannot host k-NN indexes