Amazon OpenSearch Service: What It Is and When to Use It

Definition

Amazon OpenSearch Service is the fully managed AWS service for running OpenSearch — the open-source fork of Elasticsearch 7.10 — and older Elasticsearch-compatible versions. It combines distributed search, log analytics, and vector search in a single engine, packaged as managed domains (traditional clusters) or OpenSearch Serverless (auto-scaling pay-per-capacity-unit). OpenSearch Service includes OpenSearch Dashboards (a Kibana fork) for visualization, built-in Ingestion (Data Prepper-based) pipelines, and alerting, anomaly detection, and k-NN vector search plugins enabled by default.

How It Works

An OpenSearch domain is a managed cluster of data, master, and optional warm/cold nodes. AWS handles provisioning, OS patching, engine upgrades, backups, and node replacement. You choose:

• Engine version — OpenSearch (1.x, 2.x) or legacy Elasticsearch (through 7.10).
• Data node instance type and count — r7g, m7g, i4g, etc.
• Dedicated master nodes — recommended for 10+ data-node clusters for cluster-state stability.
• Storage tier — hot (instance SSD or gp3 EBS), UltraWarm (S3-backed read-only warm tier), and Cold (archive tier queryable on demand).
• Network: public endpoint or VPC, with fine-grained access control (FGAC) via IAM or internal users, Cognito integration for Dashboards, and encryption in transit and at rest.

OpenSearch Serverless skips cluster management. You create a collection (Search, Time Series, or Vector Search type), and the service auto-scales OpenSearch Compute Units (OCUs) — one OCU ≈ 6 GB RAM and ~2 vCPU — behind the scenes. Data is stored in S3-class storage separated from compute, and collections bill per OCU-hour plus per-GB-month.

OpenSearch Ingestion is a managed Data Prepper service that ingests logs, traces, and metrics from Kinesis, S3, HTTP, and OTLP sources. Legacy paths include Logstash, Fluent Bit/Fluentd, or direct Bulk API writes.

Key Features and Limits

Search capabilities

• Full-text search with BM25 scoring, tokenizers, analyzers, multilingual support.
• Structured search and aggregations for analytics dashboards.
• k-NN vector search (HNSW, IVF, faiss) for semantic search, RAG, recommendations.
• Neural search plugins generate embeddings server-side via Bedrock/SageMaker.
• SQL and PPL query languages alongside the DSL.

Storage tiers

• Hot — instance SSD or gp3 for active queryable data.
• UltraWarm — S3-backed, queryable, ~90% cheaper than hot.
• Cold — minimal compute footprint; attached on demand.
• Index State Management (ISM) automates rollover and tier migration.

Availability

• Multi-AZ with Standby deployments place one replica per AZ across three AZs, with a standby AZ that guarantees failover within 60 seconds and consistent performance.
• Domains without Standby can span two or three AZs with fewer guarantees.

Security

• VPC isolation, IAM-based domain access, FGAC for index/document/field-level security, SAML/Cognito for Dashboards SSO, KMS encryption, audit logs to CloudWatch.

Limits (selected)

• Up to ~200 data nodes per domain, 3 AZs per domain.
• 1,000 shards per node recommended ceiling (soft).
• Serverless: up to 200 OCUs per account per Region (soft limit).

Common Use Cases

1. Log analytics — CloudWatch Logs, VPC Flow Logs, ALB/CloudFront access logs, application logs ingested via Firehose or OpenSearch Ingestion, visualized in Dashboards.
2. Application and product search — full-text product catalog search with typo tolerance, synonyms, faceted filtering, and autocomplete.
3. Security analytics / SIEM — threat detection rules, anomaly detection, correlation across logs; OpenSearch Security Analytics plugin provides prebuilt detectors.
4. Observability — traces (OpenTelemetry), metrics, and logs in a unified dashboard; integrates with AWS X-Ray.
5. Vector search / semantic search / RAG — store embeddings in a Vector Search collection and retrieve nearest neighbors for LLM context.
6. Operational dashboards — business metrics, KPIs, real-time ops views driven by time-series indices.

Pricing Model

Managed domains

• Instance-hours per data node (and master/UltraWarm nodes), based on instance type.
• EBS storage per GB-month for gp3/io2 volumes (instance SSD types include storage in the hourly rate).
• UltraWarm and Cold storage per GB-month at lower rates.
• Reserved Instances — 1- or 3-year commits save up to ~50%.
• Data transfer — standard AWS rates.

OpenSearch Serverless

• Per OCU-hour for indexing and search compute (billed at 30-minute minimum per OCU in use).
• Per GB-month for managed storage in S3.
• No instance management, no EBS, no master-node sizing.
• Cost model can be surprising for sporadic workloads — the minimum OCU floor is a planning consideration.

Pros and Cons

Pros

• Managed OpenSearch/Elasticsearch without operational toil.
• Rich analytics, search, and vector capabilities in one engine.
• UltraWarm/Cold tiers slash time-series retention costs.
• Serverless removes cluster management for unpredictable workloads.
• Deep AWS integration: VPC, IAM, KMS, Cognito, Firehose, CloudWatch.

Cons

• Shard and indexing-strategy mistakes are still your problem.
• Engine version upgrades require planning even though AWS runs them.
• Serverless minimum OCUs set a non-trivial idle floor.
• Dashboards for fine-grained permissions and tenant isolation require careful setup.
• Large-scale log workloads can cost more than pure-S3 solutions like Athena.

Comparison with Alternatives

| | OpenSearch Service | CloudWatch Logs Insights | Athena on S3 | | --- | --- | --- | --- | | Engine | OpenSearch/Elasticsearch 7.10 | Proprietary log query | Presto/Trino SQL | | Retention cost | Hot+UltraWarm+Cold | Per-GB ingested + storage | S3 storage only | | Full-text search | Excellent | Basic | Basic | | Vector search | Built-in (k-NN) | No | No | | Best for | Search, log analytics, vector | Quick ad-hoc log queries | Large historical data in S3 |

Pick OpenSearch Service when you need full-text search, rich dashboards, alerts, or vector search. Pick CloudWatch Logs Insights for quick, low-volume ad-hoc log queries. Pick Athena for massive, cold log volumes stored in Parquet on S3.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — log analytics pipelines with Firehose → OpenSearch → Dashboards; Multi-AZ and Multi-AZ with Standby; VPC vs public access.
• Data Analytics (legacy DAS-C01) / Data Engineer (DEA-C01) — ingest patterns (Kinesis, Firehose, OpenSearch Ingestion), index lifecycle, UltraWarm economics.
• Security Specialty (SCS-C02) — FGAC, KMS encryption, audit logging, Security Analytics plugin.
• Database Specialty (DBS-C01) — when OpenSearch is the right answer (search, log analytics, vector) vs a relational or NoSQL database.

Exam trap: "centralize and visualize logs" → OpenSearch Service (or OpenSearch Ingestion). "semantic search over embeddings" → OpenSearch Serverless Vector Search collection. "occasional log queries, don't want to manage anything" → CloudWatch Logs Insights or Athena, not OpenSearch.

Frequently Asked Questions

Q: What's the difference between OpenSearch Service domains and OpenSearch Serverless?

A: Domains are traditional managed clusters — you pick instance types, counts, AZs, and storage, and you pay per instance-hour even when idle. They offer the most control, all engine features, UltraWarm/Cold tiers, and plugins. OpenSearch Serverless is collection-based and auto-scales OpenSearch Compute Units (OCUs) up and down in response to traffic, billing per OCU-hour plus storage with no instance management. Serverless supports three collection types — Search, Time Series, and Vector Search — and is ideal for unpredictable workloads and vector/RAG use cases.

Q: How does UltraWarm save money on log retention?

A: UltraWarm is a read-only storage tier backed by S3 plus a small hot-node cache. Because storage lives in S3 rather than on EBS/instance volumes, per-GB cost is roughly 90% lower than hot tier. Queries against UltraWarm are slower than hot but still interactive for most analytics. A typical pattern is ISM-managed rollover: new indices start on hot, migrate to UltraWarm after 7–30 days, then to Cold or deletion after 90+ days. Time-series workloads can cut storage spend dramatically with no loss of queryability.

Q: Is OpenSearch Service the right place to run vector / semantic search?

A: Yes — OpenSearch has first-class k-NN vector search (HNSW, IVF, faiss), hybrid scoring that combines vector similarity with lexical BM25, and neural search plugins that generate embeddings server-side via Bedrock or SageMaker. OpenSearch Serverless Vector Search collections are optimized specifically for this use case, with auto-scaling compute and storage. Alternatives worth comparing include Amazon Aurora PostgreSQL with pgvector, which is a better fit when you already store relational data with the embeddings; and OpenSearch Serverless when vectors are a first-class, high-scale workload on their own.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon OpenSearch Service documentation before making production decisions.