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://mp-staging.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/security.md

Security — Amazon OpenSearch controls

Every assessment / recommendation MUST include a Security section that confirms each control below.

Three security layers

[Network] → [Domain Access Policy] → [Fine-Grained Access Control (FGAC)]
1. Network
PatternWhen
VPC + Interface VPC endpointProduction. Private connectivity from your VPC to AOS.
VPC + ENI (older pattern)Production legacy. ENI in VPC subnets.
Public endpoint + IAMDev/test, or when external SaaS integration requires public access
Public endpoint + IP allowlistTightening public — pair with Domain Access Policy IP filter

VPC ↔ AOS endpoint traffic is regional; cross-AZ data transfer within an AOS cluster is FREE.

2. Domain Access Policy (resource-based)

JSON policy on the domain itself. Controls which IAM principals can call https://<domain>/*. Cluster-level coarse grain.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<account>:role/<app-role>" },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:<region>:<account>:domain/<domain-name>/*"
    }
  ]
}
3. Fine-Grained Access Control (FGAC)

Adds document-level / field-level / role-based authorization on top.

Requirements (once enabled, cannot be disabled):

  • OpenSearch / Elasticsearch 6.7+

  • HTTPS enforced

  • Encryption at rest enabled

  • Node-to-node encryption enabled

Master user is either:

  • An IAM principal (signed Sig v4 requests) — no password

  • A username/password in the internal user database

The master user is automatically mapped to all_access and security_manager roles.

IAM master vs internal user database
IAM master userInternal user master
AuthenticationSig v4 signed requestsHTTP basic auth (username/password)
AuthorizationFGAC roles (NOT IAM permissions)FGAC roles
Best forApp-to-AOS integrationsHuman users, dashboards, simple setups
Password rotationN/A (use IAM role rotation)AOS API or dashboards

IAM master gotcha: IAM is just authentication. Authorization is by FGAC permissions, NOT IAM permissions.

FGAC built-in roles

RoleUse
all_accessMaster user; do not assign to humans
security_managerManage internal users + roles
kibana_user / dashboards_userRead-only Dashboards access
readallRead all indexes
manage_snapshotsCreate/restore snapshots
ultrawarm_managerManage UltraWarm migrations (AWS-only role)
cold_managerManage Cold storage migrations (AWS-only role)
ml_full_accessManage ML Commons models (AWS-only role)
notifications_full_access / notifications_read_accessNotification destinations

AWS does NOT offer: observability_full_access, observability_read_access, reports_read_access, reports_full_access (these are upstream-only roles).

Custom FGAC role example

PUT _plugins/_security/api/roles/app-readonly
{
  "cluster_permissions": ["cluster_composite_ops_ro"],
  "index_permissions": [{
    "index_patterns": ["app-*"],
    "allowed_actions": ["read"],
    "fls": ["~secret_field"],
    "masked_fields": ["pii_email"],
    "dls": "{ \"term\": { \"tenant_id\": \"${attr.internal.tenant}\" } }"
  }],
  "tenant_permissions": [{
    "tenant_patterns": ["app_tenant"],
    "allowed_actions": ["kibana_all_read"]
  }]
}
  • DLS (Document-Level Security): query that filters which docs the role can see

  • FLS (Field-Level Security): which fields are visible (~field excludes; field includes)

  • Field masking: hash or pattern-mask field values

Authentication backends (FGAC)

OpenSearch FGAC supports multiple backends:

BackendWhen
Internal user databaseSimple setups; AOS-stored usernames + bcrypt passwords
IAM SigV4App-to-AOS; AWS principals only
SAMLEnterprise SSO; map SAML attributes to FGAC roles
OpenID ConnectModern SSO; OIDC providers like Auth0, Keycloak, Okta
LDAP / Active DirectoryOn-prem or hybrid AD setups
CognitoAWS-native user pool with SAML/OIDC federation
AnonymousPublic read-only data; rare
Common pattern: Cognito + FGAC
  1. Create Cognito user pool + identity pool

  2. Configure AOS domain to use Cognito for OpenSearch Dashboards

  3. Map Cognito groups to FGAC backend roles

  4. Users sign in via Dashboards; Cognito hands off to FGAC for authorization

Encryption

ControlDefaultNotes
At-rest encryptionON for new domainsKMS-managed (AWS-managed key by default; can use customer-managed CMK)
Node-to-node encryptionON when FGAC enabledTLS between cluster nodes
In-transit (HTTPS)TLS 1.2+ mandatory; TLS 1.3 supported
Custom HTTPSOptional ACM certFor VPC clusters with custom domain

Customer-managed KMS gives you key rotation control + audit. Use when compliance requires it.

Audit logs

Two log types pushed to CloudWatch Logs:

Log typeWhat
Audit logsAuthentication / authorization events, query logs (configurable)
Slow logsSlow queries / indexing operations
Index slow logsSlow indexing
Search slow logsSlow searches
Application logsErrors, warnings

Audit log levels: BASIC, EXTERNAL_ONLY (no internal API calls), READ_AND_WRITE (verbose).

CloudWatch Logs charges apply (storage + ingestion). Use selective log enablement, not all-on.

Compliance

Amazon OpenSearch Service is in scope for (verify current per-service status):

  • HIPAA (with BAA)

  • PCI DSS

  • SOC 1 / 2 / 3

  • ISO 27001 / 27017 / 27018

  • FedRAMP Moderate (commercial regions) / High (GovCloud)

  • IRAP, Cyber Essentials Plus, ENS High, SecNumCloud, MTCS, GxP

Always verify the latest compliance status at https://aws.amazon.com/compliance/services-in-scope/ before attesting in a customer report.

Network architecture patterns

Pattern A: Private domain (production)
[App in VPC subnet] ─→ [VPC Interface Endpoint] ─→ [AOS domain in private subnet]
  • AOS deployed with VPC endpoint

  • App accesses via VPC private DNS

  • Cross-AZ data transfer inside AOS is FREE

Pattern B: Public domain + IAM (lighter footprint)
[App] ──signed-Sig-v4──→ [AOS public endpoint]
  • AOS in public DNS

  • IAM Sig v4 signed requests

  • Apply IP allowlist via Domain Access Policy for additional defense

Pattern C: Public domain + FGAC for humans
[Human user] ─→ [Cognito] ─→ [Dashboards] ─→ [AOS public]
  • Cognito user pool + identity pool

  • AOS configured for Cognito

  • FGAC roles mapped to Cognito groups

Security checklist for assessment reports

- [ ] Network: VPC vs Public clearly stated; rationale documented
- [ ] FGAC enabled; master user pattern documented
- [ ] Encryption at rest: AWS-managed or CMK chosen
- [ ] Node-to-node encryption: ON
- [ ] HTTPS: enforced; minimum TLS 1.2
- [ ] Audit logs: scope chosen, retention documented
- [ ] Slow logs: selective enablement (not all indexes)
- [ ] DLS / FLS / field masking: applied where multi-tenancy exists
- [ ] Backend role mapping: SAML/Cognito/OIDC group attribution documented
- [ ] Master user: NEVER an IAM principal in production app paths (use scoped role instead)
- [ ] Compliance: checked against latest aws.amazon.com/compliance/services-in-scope/
- [ ] Snapshots: appropriate destination + retention; no manual snapshots without S3 cost note
- [ ] No credentials, master usernames, or VPC endpoint URLs in the report

Data privacy / sensitive data

  • PII in indexed documents: use FLS or field masking. For HIPAA workloads, also consider tokenization at ingest.

  • Search logs can leak sensitive query terms — disable search request logging when PII may appear in queries.

  • Slow logs can leak query content — pair with restrictive CloudWatch IAM.

  • Snapshot encryption: manual snapshots inherit S3 bucket encryption. Use SSE-KMS with CMK for compliance.

Threat model headlines

  1. Public domain + open Domain Access Policy = data exposed. Always pair public endpoints with IAM signing or FGAC + IP allowlist.

  2. FGAC misconfiguration (e.g., IAM master with overly broad policy) gives unintended access.

  3. Pre-FGAC domains can have IAM-only auth without document/field controls — risky for multi-tenant data.

  4. Snapshot bucket in your account: if its bucket policy is too permissive, snapshots are exfiltrable.

  5. CloudWatch Logs for audit/slow logs — restrict who can read them.

  6. Master user password if internal user database — store in Secrets Manager, rotate regularly.

What this skill MUST NOT do

  • Embed credentials, master usernames, VPC endpoint URLs, or KMS key ARNs in generated reports. They propagate to chat logs and may end up in unapproved repos.

  • Recommend disabling FGAC. Once enabled it cannot be disabled — the right answer is rebuild domain, not "turn off security".

  • Recommend cluster.routing.allocation.disk.threshold_enabled: false as a fix for read-only clusters. The right answer is more storage / smaller shards / move data, NOT disabling watermarks.

  • Recommend public domains for production without explicit IAM + FGAC + IP allowlist.

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.

Download ZIP

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