OpenSearch Security

Amazon OpenSearch – Search, Analytics & Vector DB

~ Last updated on : ~ jayendrapatil

Amazon OpenSearch

  • Amazon OpenSearch Service is a fully managed retrieval engine for search, analytics, observability, and AI-powered applications in the AWS Cloud.
  • is the successor to Elasticsearch Service and supports OpenSearch (versions 1.x, 2.x, and 3.x) and legacy Elasticsearch OSS (up to 7.10).
  • is a fully open-source search and analytics engine for use cases such as log analytics, real-time application monitoring, clickstream analysis, vector search, and Retrieval Augmented Generation (RAG) for generative AI.
  • OpenSearch provides
    • instance types with numerous configurations of CPU, memory, and storage capacity, including cost-effective Graviton instances
    • OpenSearch Optimized Instances (OR1) with up to 30% price-performance improvement and 11 nines of data durability using S3
    • Up to 3 PB of attached storage
    • Cost-effective UltraWarm and cold storage for read-only data
    • Multi-tier storage with writeable warm tier (OR1 instances) for cost-effective data management
    • Integration with AWS IAM, VPC, VPC Security Groups
    • Encryption at Rest and in Transit
    • Authentication with Cognito, HTTP basic, or SAML authentication for OpenSearch Dashboards
    • Index-level, document-level, and field-level security
    • Multi-AZ setup with node allocation across two or three AZs in the same AWS Region
    • Multi-AZ with Standby for 99.99% availability SLA
    • Dedicated master nodes to offload cluster management tasks
    • Automated snapshots to back up and restore OpenSearch Service domains
    • Integration with CloudWatch for monitoring, CloudTrail for auditing, S3, Kinesis, and DynamoDB for loading streaming data into OpenSearch Service.
    • Vector database capabilities with k-NN search for similarity-based retrieval, supporting RAG with Amazon Bedrock Knowledge Bases
    • Zero-ETL integrations with Amazon S3, DynamoDB, and Amazon Security Lake

OpenSearch Service Domain

  • An OpenSearch Service domain is synonymous with an OpenSearch cluster.
  • Domains are clusters with specified settings, instance types, instance counts, and storage resources.
  • Amazon OpenSearch Service supports OpenSearch versions 1.x through 3.x (latest supported: 3.5) and legacy Elasticsearch versions 1.5 to 7.10.
  • automates common administrative tasks, such as performing backups, monitoring instances and patching software once the domain is running.
  • uses a blue/green deployment process when updating domains. Blue/green typically refers to the practice of running two production environments, one live and one idle, and switching the two as software changes are made.
  • All domains configured for multiple AZs have zone awareness enabled to ensure shards are distributed across AZs.
  • supports up to 1,000-node clusters capable of handling 500,000 shards (OpenSearch 2.17+).

OpenSearch Optimized Instances (OR1)

  • OR1 is the OpenSearch-optimized instance family introduced in Nov 2023, delivering up to 30% price-performance improvement over existing memory-optimized instances.
  • uses local EBS storage for primary storage with data copied synchronously to Amazon S3 as it arrives, providing 11 nines (99.999999999%) of data durability.
  • provides zero-time Recovery Point Objective (RPO) due to synchronous S3 replication.
  • is ideally suited for heavy indexing use cases like log analytics and observability workloads.
  • supports a new multi-tier storage architecture with hot and writeable warm tiers (announced Dec 2025):
    • Hot tier handles frequently accessed data with high-performance local storage
    • Warm tier leverages S3 for cost-effective storage of less frequently accessed data while supporting write operations
    • Data rotation from hot to warm can be automated using Index State Management
  • requires OpenSearch version 2.15 or higher on existing domains.

OpenSearch Security

  • OpenSearch Service domains support encryption at rest through AWS Key Management Service (KMS), node-to-node encryption over TLS, and the ability to require clients to communicate with HTTPS.
  • supports only symmetric encryption KMS keys, not asymmetric ones.
  • encrypts all indices, log files, swap files, and automated snapshots.
  • does not encrypt Manual snapshots and slow & error logs.
  • can be configured to be accessible with an endpoint within the VPC or a public endpoint accessible to the internet.
  • Network access for VPC endpoints is controlled by security groups and for public endpoints, access can be granted or restricted by IP address.
  • supports integration with Cognito, to allow the end-users to log-in to OpenSearch dashboards through enterprise identity providers such as Microsoft Active Directory using SAML 2.0, Cognito User Pools, and more.
  • supports Fine-Grained Access Control (FGAC) providing role-based access control, index-level, document-level, and field-level security.
  • supports routing domain egress traffic through the customer’s VPC for enhanced network security (2026).

OpenSearch Storage Tiers

  • OpenSearch Service supports three integrated storage tiers: Hot, UltraWarm, and Cold.
  • Hot tier is powered by data nodes which are used for indexing, updating, and providing the fastest access to data.
  • UltraWarm nodes complement the hot tier by providing a fully managed, low-cost, read-only, warm storage tier for older and less-frequently accessed data.
  • UltraWarm uses S3 for storage and removes the need to configure a replica for the warm data.
  • UltraWarm now supports vector search capabilities for k-NN indexes (announced Mar 2025), enabling cost-effective vector similarity searches on warm-tier data.
  • Cold storage is a fully-managed lowest cost storage tier that makes it easy to securely store and analyze the historical logs on-demand.
  • Cold storage helps fully detach storage from compute when they are not actively performing analysis of their data and keep the data readily available at low cost.
  • OR1 instances offer an additional multi-tier architecture with a writeable warm tier (Dec 2025), allowing writes to warm storage unlike the traditional read-only UltraWarm.

OpenSearch Multi-AZ with Standby

  • Multi-AZ with Standby is a deployment option that offers 99.99% availability SLA, consistent performance for production workloads, and simplified domain configuration.
  • maintains standby nodes in a separate Availability Zone that are automatically promoted during infrastructure failures.
  • provides self-healing capabilities with 24/7 monitoring and automatic failover.
  • is available for OpenSearch version 1.3 and above, and requires regions with at least three Availability Zones.
  • is the recommended deployment for production workloads requiring high availability.

OpenSearch Vector Search & AI/ML

  • OpenSearch Service provides native vector database capabilities using the k-nearest neighbor (k-NN) plugin for similarity-based search.
  • supports multiple vector search algorithms: HNSW (Hierarchical Navigable Small World), IVF (Inverted File Index), and FAISS (Facebook AI Similarity Search).
  • supports hybrid search combining vector (semantic) and lexical (keyword) search for improved relevance.
  • provides AI/ML connectors (version 2.9+) that integrate with neural search to simplify vector embedding generation from models like Amazon Bedrock, SageMaker, and external APIs.
  • serves as a recommended vector store for Amazon Bedrock Knowledge Bases, enabling Retrieval Augmented Generation (RAG) for generative AI applications.
  • supports both managed clusters and serverless collections as vector stores for Bedrock Knowledge Bases (managed cluster support added Mar 2025).
  • supports binary vector embeddings for cost-effective RAG applications with reduced memory usage.
  • GPU-Accelerated Vector Indexing (Dec 2025, re:Invent): enables building billion-scale vector databases in under an hour, with up to 10x faster indexing at a quarter of the cost.
  • Auto-Optimized Vector Indexes (Dec 2025): automatically determines optimal configuration settings balancing search quality, speed, and cost.
  • Intel AVX-512 Acceleration (OpenSearch 2.18+): hardware-accelerated binary vector operations providing up to 48% throughput improvement on latest-generation Intel Xeon instances.
  • AI-Powered Forecasting (Aug 2025): available on OpenSearch 3.1+ domains for predictive analytics.

OpenSearch Serverless

  • Amazon OpenSearch Serverless is a serverless deployment option that eliminates the need to provision, configure, and tune OpenSearch clusters.
  • automatically scales compute capacity based on workload demands.
  • supports three collection types: Time-series, Search, and Vector.
  • Next-Generation OpenSearch Serverless (GA May 2026) — a complete architectural rebuild designed for agentic AI workloads:
    • Introduces complete decoupling of compute and storage through a new shared storage layer
    • Scales from zero to thousands of requests per second and back to zero when idle (scale-to-zero)
    • Auto-scales 20x faster than the previous generation, provisioning resources in seconds
    • Offers up to 60% cost savings compared to provisioned clusters at peak capacity
    • Provides pay-per-usage pricing model
    • Offers resource-based endpoints (collection level and regional) for simplified multi-VPC and on-premise connectivity
    • Native integrations with AI development platforms
    • Available collection types at GA: Search and Vector
  • Automatic Semantic Enrichment (Aug 2025): simplifies semantic search implementation by automatically boosting search relevance without complex manual configurations.
  • OpenSearch Serverless supports features like flat object data type, enhanced geospatial features (Oct 2024), and binary vector embeddings.

OpenSearch Ingestion

  • Amazon OpenSearch Ingestion is a fully managed, serverless data pipeline service that streams real-time logs, metrics, and trace data to OpenSearch Service domains and Serverless collections.
  • is powered by Data Prepper as the data engine and provisions pipelines consisting of a source, a buffer, zero or more processors, and one or more sinks.
  • scales automatically to meet demanding workloads without infrastructure management.
  • supports data from multiple sources including Amazon S3, Kinesis Data Streams, Amazon MSK, HTTP endpoints, and OTel collectors.
  • enables zero-ETL integration with DynamoDB (GA Nov 2023) for real-time search on DynamoDB data including vector search capabilities.
  • integrates with Amazon RDS and Amazon Aurora for real-time data synchronization with OpenSearch.
  • provides a visual interface for accelerated pipeline creation without code.
  • supports performance monitoring in CloudWatch and error logging in CloudWatch Logs.

OpenSearch Zero-ETL Integrations

  • OpenSearch Service supports zero-ETL integrations to reduce operational complexity by eliminating data duplication and enabling direct queries.
  • Zero-ETL with Amazon S3 (GA May 2024): enables direct querying of operational logs in S3 and S3-based data lakes using OpenSearch SQL and PPL without data movement. Requires OpenSearch 2.13+.
  • Zero-ETL with DynamoDB (GA Nov 2023): provides seamless, no-code data ingestion from DynamoDB into OpenSearch via OpenSearch Ingestion pipelines, supporting both text search and vector search on DynamoDB data.
  • Zero-ETL with Amazon Security Lake (Dec 2024): integrates with Security Lake for simplified security analytics, automatically creating serverless collections for query results.
  • Direct Query: enables querying data in Amazon CloudWatch Logs, S3, Security Lake, and Amazon Managed Service for Prometheus without building ingestion pipelines, using PromQL, PPL, or SQL.

OpenSearch Cross-Cluster Replication

  • Cross-cluster replication helps automate copying and synchronizing indices from one cluster to another at low latency in the same or different AWS Regions.
  • Domains participating in cross-cluster replication need to meet the following criteria:
    • Participating domains should be on OpenSearch 1.1 or later
    • Participating domains need to have encryption in transit enabled
    • Participating domains need to have Fine-Grained Access Control (FGAC) enabled
    • Participating domains versions should adhere to the same rules as rolling version upgrade
  • Current implementation of cross-cluster replication does not support Ultrawarm or Cold Storage.

OpenSearch Cross-Cluster Search

  • Cross-cluster search enables querying and visualizing data stored in multiple OpenSearch clusters from a single endpoint.
  • supports searching across domains in the same or different AWS Regions.
  • does not require data replication, enabling searches across distributed datasets without data movement.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company needs to implement a full-text search solution for their e-commerce application. The search must support auto-complete, fuzzy matching, and faceted search. The data is stored in DynamoDB. Which approach provides the MOST operationally efficient solution?
    1. Use Amazon OpenSearch Service with DynamoDB Streams and Lambda to sync data
    2. Use Amazon OpenSearch Service with DynamoDB zero-ETL integration via OpenSearch Ingestion
    3. Use Amazon CloudSearch with a DynamoDB export pipeline
    4. Use Amazon Kendra with DynamoDB as a data source

    Answer: b. DynamoDB zero-ETL integration with OpenSearch Ingestion provides a fully managed, no-code solution for real-time data synchronization.

  2. A machine learning team needs a vector database to support their RAG (Retrieval Augmented Generation) application using Amazon Bedrock. They need to handle unpredictable traffic patterns with minimal cost during idle periods. Which solution is MOST cost-effective?
    1. Amazon OpenSearch Service managed cluster with OR1 instances
    2. Amazon OpenSearch Serverless with vector collection type (next-generation)
    3. Amazon OpenSearch Service with UltraWarm storage for vector indexes
    4. Self-managed OpenSearch on EC2 with GPU instances

    Answer: b. Next-generation OpenSearch Serverless scales to zero when idle and offers pay-per-usage pricing, making it most cost-effective for unpredictable workloads.

  3. A company requires a search solution with 99.99% availability for their mission-critical application. Which Amazon OpenSearch Service configuration meets this requirement?
    1. Single-AZ deployment with automated snapshots
    2. Multi-AZ deployment without standby across two AZs
    3. Multi-AZ with Standby deployment across three AZs
    4. Cross-cluster replication between two regions

    Answer: c. Multi-AZ with Standby is the only deployment option that provides a 99.99% availability SLA.

  4. A security team needs to analyze logs stored in Amazon Security Lake along with application logs in their OpenSearch cluster. They want a unified view without duplicating data. Which feature should they use?
    1. OpenSearch Ingestion pipeline from Security Lake to OpenSearch
    2. OpenSearch Service zero-ETL integration with Security Lake
    3. Amazon Athena federated queries to OpenSearch
    4. AWS Glue ETL job to load Security Lake data into OpenSearch

    Answer: b. Zero-ETL integration with Security Lake enables direct querying without data duplication or pipeline management.

  5. A company needs to build a billion-scale vector database for image similarity search. They want to minimize indexing time and cost. Which Amazon OpenSearch Service feature should they use?
    1. Standard k-NN indexing on R6g instances
    2. GPU-accelerated vector indexing
    3. UltraWarm vector search
    4. OpenSearch Serverless vector collection

    Answer: b. GPU-accelerated vector indexing can build billion-scale vector databases in under an hour with up to 10x faster indexing at a quarter of the cost.

  6. An organization wants to use OR1 instances for their log analytics workload. Which statements are true about OR1 instances? (Select TWO)
    1. OR1 instances store data only on local NVMe storage
    2. OR1 instances synchronously replicate data to S3 for 11 nines of durability
    3. OR1 instances provide zero-time Recovery Point Objective (RPO)
    4. OR1 instances require OpenSearch version 1.3 or higher
    5. OR1 instances are optimized for read-heavy workloads only

    Answer: b, c. OR1 instances use EBS with synchronous S3 replication for 11 nines of durability and zero-time RPO. They require OpenSearch 2.15+, not 1.3.

  7. A company wants to query operational logs stored in Amazon S3 using their existing OpenSearch dashboards without moving data. Which solution should they implement?
    1. Create an OpenSearch Ingestion pipeline from S3
    2. Use OpenSearch Service zero-ETL integration with Amazon S3
    3. Configure S3 Select with OpenSearch
    4. Use AWS Lake Formation with OpenSearch connector

    Answer: b. OpenSearch Service zero-ETL integration with S3 enables direct querying of S3 data using SQL and PPL without data movement.

References