
Cargando...
Managed OpenSearch & Dashboards for full-text search, log analytics, and AI-powered vector similarity at scale
Amazon OpenSearch Service is a fully managed service that makes it easy to deploy, operate, and scale OpenSearch clusters in the AWS Cloud. It supports full-text search, real-time application monitoring, log analytics, clickstream analytics, and — critically for modern AI workloads — k-NN vector similarity search for RAG (Retrieval-Augmented Generation) pipelines. OpenSearch Service includes built-in OpenSearch Dashboards (formerly Kibana) for visualization and integrates natively with services like Amazon Bedrock, Kinesis Data Firehose, AWS Lambda, and Amazon S3.
Provide managed, scalable full-text search and analytics with native vector search support for both operational and AI/ML use cases, eliminating the undifferentiated heavy lifting of cluster management.
Use When
Avoid When
Full-text search with relevance scoring (BM25)
Default similarity algorithm; supports custom scoring
k-NN vector similarity search
Supports HNSW and IVF algorithms; critical for RAG with Amazon Bedrock
OpenSearch Dashboards (built-in)
Successor to Kibana; included with every domain
UltraWarm (warm storage tier)
S3-backed, read-optimized; up to 90% cost reduction vs. hot
Cold storage tier
Detaches indices to S3; must migrate back before querying
Automated snapshots (hourly, 14-day retention)
Free; stored in AWS-managed S3 bucket
Manual snapshots to customer S3
Standard S3 storage charges apply
Multi-AZ with Standby
99.99% SLA; requires even number of data nodes across 3 AZs
Dedicated master nodes
Recommended for production; use 3 or 5 (odd number)
Encryption at rest (AWS KMS)
Must be enabled at domain creation
Node-to-node encryption (TLS)
Must be enabled at domain creation
Fine-grained access control (FGAC)
Document-level and field-level security
VPC deployment
Mutually exclusive with public endpoint
SAML authentication for Dashboards
Enables SSO via corporate IdP
Amazon Cognito authentication
For Dashboards access control
AWS CloudTrail integration
API call logging for audit
Amazon CloudWatch metrics
Cluster health, JVM pressure, search latency, etc.
Auto-Tune
Automatically optimizes JVM heap, thread pools, and queue sizes
Anomaly detection (ML-powered)
Built-in unsupervised ML for time-series anomaly detection
Alerting
Trigger notifications via SNS, Slack, PagerDuty, etc.
Index State Management (ISM)
Automate index lifecycle: rollover, delete, migrate to warm/cold
Cross-cluster replication
Replicate indices across OpenSearch domains for DR
OpenSearch Serverless
Serverless option; separate pricing model (OCUs)
SQL query support
OpenSearch SQL plugin for SQL-like queries
Piped Processing Language (PPL)
Log analytics query language
Trace Analytics
Distributed tracing with OpenTelemetry
Learning to Rank (LTR)
ML-based relevance tuning
FIPS 140-2 endpoints
Available in GovCloud regions
RAG Vector Store
high freqUse OpenSearch k-NN vector search as the retrieval layer in a RAG pipeline. Amazon Bedrock generates embeddings (via Titan Embeddings or third-party models), stores them in OpenSearch vector search collections, and retrieves semantically similar documents at query time to augment LLM prompts. OpenSearch is the CORRECT service for vector similarity search — not DynamoDB, not RDS.
Real-time Log Analytics Pipeline
high freqFirehose delivers streaming data (logs, events, clickstreams) directly to OpenSearch domains without custom code. This is the canonical AWS log analytics architecture: source → Kinesis Data Streams (optional) → Firehose → OpenSearch → Dashboards. Firehose handles buffering, batching, and retry logic automatically.
Event-driven Index Population
high freqLambda functions triggered by DynamoDB Streams, S3 events, or SNS/SQS messages transform and index documents into OpenSearch. Common pattern for keeping OpenSearch in sync with a primary data store (DynamoDB or RDS) — OpenSearch serves as a search replica, not the source of truth.
Log Archival and Rehydration
high freqUse Index State Management (ISM) to automatically migrate aging indices from hot → UltraWarm → cold (S3). For compliance, raw logs are archived to S3 Glacier; OpenSearch cold storage links to S3 Standard. Rehydrate cold indices back to warm/hot for ad-hoc analysis.
Cluster Health Monitoring
high freqCloudWatch receives OpenSearch cluster metrics (ClusterStatus.red/yellow, JVMMemoryPressure, SearchLatency, IndexingLatency, FreeStorageSpace). Set CloudWatch Alarms on these metrics to trigger SNS notifications or Auto Scaling actions. This is the primary monitoring mechanism — NOT VPC Flow Logs or CloudTrail for performance issues.
Search Offload from Relational Database
high freqRDS remains the authoritative OLTP store; OpenSearch provides full-text search capabilities that RDS LIKE queries cannot efficiently serve. Lambda or DMS captures CDC events from RDS and syncs to OpenSearch. This is the correct pattern when questions ask about adding search to an existing RDS application.
ML-Enhanced Search
medium freqSageMaker hosts custom embedding models or reranking models; inference results (embeddings) are stored in OpenSearch for vector search. For Learning to Rank, SageMaker trains ranking models deployed as OpenSearch plugins. This pattern avoids the need to build custom infrastructure for ML-augmented search.
Intelligent Document Search
medium freqTextract extracts text and structured data from PDFs/images → Bedrock generates embeddings → OpenSearch stores vectors and text for hybrid search (keyword + semantic). This enables enterprise document Q&A and compliance search use cases.
Secured Dashboards Access
medium freqAmazon Cognito User Pools authenticate users; Cognito Identity Pools provide temporary AWS credentials for OpenSearch Dashboards access. This enables corporate SSO without exposing OpenSearch endpoints publicly. Alternative: SAML 2.0 integration for direct IdP federation.
NLP-Enriched Search Index
medium freqComprehend extracts entities, sentiment, and key phrases from text documents; these enrichments are stored as additional fields in OpenSearch documents, enabling faceted search by entity type, sentiment filtering, and improved relevance. NOTE: Comprehend does NOT generate embeddings — use Bedrock Titan Embeddings or SageMaker for that.
OpenSearch is THE correct answer for vector similarity search (k-NN) in RAG architectures on AWS — not DynamoDB, not RDS, not ElastiCache. When a question asks about storing and searching embeddings for a generative AI application, choose OpenSearch (or OpenSearch Serverless with a vector search collection).
Dedicated master nodes must be an ODD number (3 or 5) to prevent split-brain. Using 2 dedicated master nodes provides NO additional fault tolerance over 1. This is one of the most frequently tested OpenSearch architecture questions across SAA-C03, SAP-C02, and DOP-C02.
Encryption at rest, node-to-node encryption, and VPC vs. public endpoint are ALL immutable settings set at domain creation. If a question asks 'how do you enable encryption on an existing unencrypted OpenSearch domain?' — the answer is always: create a new encrypted domain and reindex data.
The three storage tiers — Hot (EBS/OR1), UltraWarm (S3-backed warm), and Cold (detached S3) — are the core cost optimization pattern for time-series log data. Use Index State Management (ISM) to automate transitions. Cold storage indices are NOT queryable until migrated back to warm or hot.
For monitoring OpenSearch cluster health, the primary tool is Amazon CloudWatch metrics (ClusterStatus.red, JVMMemoryPressure, FreeStorageSpace). API throttling issues (HTTP 429) are application-level, not network-level — do NOT use VPC Flow Logs or CloudTrail to diagnose throttling.
OpenSearch = ONLY native AWS vector similarity search (k-NN) service for RAG. DynamoDB, RDS, and ElastiCache CANNOT perform vector similarity search natively. When you see 'embeddings + similarity search + RAG' in a question, choose OpenSearch.
Dedicated master nodes MUST be an odd number (3 or 5). Two master nodes = no quorum protection = same risk as one master. This is tested repeatedly across SAA-C03, SAP-C02, and DOP-C02.
Encryption at rest, node-to-node encryption, and VPC/public endpoint are ALL immutable after domain creation. The ONLY way to change them is: create a new domain with correct settings + reindex all data.
OpenSearch Serverless has a MINIMUM cost floor of 2 OCUs for indexing + 2 OCUs for search = 4 OCUs always running. For low-traffic or dev/test workloads, a small provisioned domain (e.g., t3.small.search) may be significantly cheaper. Serverless excels at unpredictable, spiky, high-scale workloads.
Amazon Cognito integration with OpenSearch Dashboards is the recommended way to add authentication to Dashboards for end users. SAML 2.0 is the alternative for direct IdP integration. Fine-grained access control (FGAC) enables document-level and field-level security for multi-tenant scenarios.
Automated snapshots are taken hourly, retained for 14 days, stored in AWS-managed S3 (not your account), and are FREE. Manual snapshots go to YOUR S3 bucket, cost standard S3 rates, and have no retention limit. For cross-region disaster recovery, you must use manual snapshots.
OpenSearch Serverless collection type is immutable — choose Search (optimized for low-latency queries), Time series (optimized for sequential append and time-based queries), or Vector search (optimized for k-NN) at creation time. Wrong collection type = poor performance and no way to change without recreating.
Cross-cluster replication in OpenSearch enables active-passive DR between two OpenSearch domains. The leader cluster replicates specified indices to follower clusters in real time. This is distinct from snapshot-based DR (which has RPO measured in hours) — cross-cluster replication provides near-zero RPO.
Auto-Tune automatically adjusts JVM heap size, thread pool settings, and connection queue sizes based on observed cluster performance. It can schedule changes during off-peak hours. Enable Auto-Tune for production domains to reduce operational toil — this is the managed alternative to manual JVM tuning.
Common Mistake
DynamoDB can perform vector similarity search, making it suitable as a vector store for RAG applications
Correct
DynamoDB is a key-value/document store optimized for exact lookups and range queries — it has NO native k-NN or vector similarity search capability. For RAG/vector search on AWS, use Amazon OpenSearch Service (k-NN plugin), OpenSearch Serverless (vector search collection), or Amazon Aurora pgvector extension.
This is the #1 misconception in AIF-C01 and SAA-C03 questions about generative AI architectures. The exam will present DynamoDB as a plausible answer for 'where to store embeddings' — it's a trap. DynamoDB stores the embeddings as data but cannot search them by similarity.
Common Mistake
Amazon Comprehend can generate vector embeddings for use in RAG pipelines
Correct
Amazon Comprehend performs NLP tasks (entity recognition, sentiment analysis, key phrase extraction, language detection) but does NOT generate vector embeddings. For embeddings, use Amazon Bedrock (Titan Embeddings), Amazon SageMaker (custom or built-in embedding models), or open-source models via SageMaker JumpStart.
Comprehend and Bedrock are both 'AI services' and candidates conflate their capabilities. Remember: Comprehend = ANALYZE existing text for meaning; Bedrock Titan Embeddings = TRANSFORM text into vectors. OpenSearch then SEARCHES those vectors.
Common Mistake
Using 2 dedicated master nodes provides better availability than 1 master node
Correct
2 dedicated master nodes provides NO additional availability benefit over 1. With 2 masters, if one fails, the remaining node cannot achieve quorum (majority) to elect itself as master, causing cluster instability. Always use 3 or 5 (odd numbers) for quorum-based master election.
This is a classic exam trap in SAA-C03 and DOP-C02. The question will show a cluster with 2 master nodes and ask if it's properly configured for HA. The answer is NO — you need 3. Remember: odd numbers only (3 or 5), never even.
Common Mistake
Cold storage in OpenSearch allows you to query data directly without any migration step
Correct
Cold storage detaches indices from the cluster and stores them in S3. Cold indices are NOT queryable while detached. You must explicitly migrate cold indices back to UltraWarm or hot storage before running queries. This migration takes time and incurs compute costs.
Candidates assume all three tiers (hot/warm/cold) are queryable at all times. Only hot and warm are queryable. Cold is purely archival. This distinction matters for SLA and query latency requirements in exam scenarios.
Common Mistake
You can enable encryption at rest or switch from public to VPC endpoint on an existing OpenSearch domain
Correct
Encryption at rest, node-to-node encryption, and network type (VPC vs. public) are immutable settings configured at domain creation. To change them, you must create a new domain with the desired settings and reindex your data. There is no in-place upgrade path for these security settings.
Exam scenarios will describe a company that needs to add encryption to an existing production domain. The correct answer always involves creating a new domain — not modifying the existing one. This trips up candidates who assume these are configurable post-creation like most AWS service settings.
Common Mistake
OpenSearch Serverless is always cheaper than provisioned OpenSearch because you only pay for what you use
Correct
OpenSearch Serverless has a minimum cost floor of 2 OCUs for indexing + 2 OCUs for search (4 OCUs total), which runs continuously regardless of traffic. For low-traffic or steady-state workloads, a small provisioned domain (t3.small or t3.medium) can be significantly cheaper. Serverless is cost-optimal for unpredictable, spiky, or very high-scale workloads.
'Serverless = cheaper' is a common mental model that doesn't always hold. The 4-OCU minimum floor means you pay a baseline even at zero requests. Always compare provisioned vs. serverless costs based on actual workload patterns.
Common Mistake
VPC Flow Logs or CloudTrail can be used to diagnose API throttling (HTTP 429) on OpenSearch
Correct
API throttling in OpenSearch is an application-layer issue visible in CloudWatch metrics (specifically HTTP 4xx error rates and request rates). VPC Flow Logs show network-level traffic (IP, port, bytes) but cannot reveal HTTP status codes or application-level throttling. CloudTrail logs management API calls, not data-plane search/index operations.
This misconception appears directly in exam questions about monitoring strategy. The correct tool for OpenSearch performance and throttling monitoring is Amazon CloudWatch metrics and OpenSearch Dashboards — not network monitoring tools.
SEARCH = Store Embeddings And Retrieve Content from Hubs (OpenSearch's role in RAG: store vectors, retrieve relevant docs)
HOT-WARM-COLD: Think of it like coffee — Hot is fresh and expensive, Warm is sitting on the warmer (cheaper, still drinkable), Cold is in the fridge (cheapest, needs reheating before use)
ODD MASTERS: Master nodes must always be ODD (1, 3, 5) — 'Even masters are bad masters' (no quorum = no cluster)
IMMUTABLE at BIRTH: Encryption, node-to-node, VPC vs. public — like a birth certificate, you can't change these after the domain is born
Comprehend = Classify (analyzes meaning), Bedrock = Embed (creates vectors), OpenSearch = Execute (searches vectors) — the CEE chain for AI search
CertAI Tutor · AIF-C01, SAA-C03, SAP-C02, DEA-C01, DOP-C02, CLF-C02, DVA-C02 · 2026-02-22
In the Same Category
Comparisons
Guides & Patterns