Skip to main content

Amazon OpenSearch Service - Overview

Amazon OpenSearch Service (formerly Amazon ElasticSearch Service) is a total classic when an architectural question demands full-text search, fuzzy/partial string matching, or log analytics dashboard. ๐Ÿ”

Because standard databases like DynamoDB are optimized for direct primary key / index lookups, offloading search and analytical queries to OpenSearch is an essential design pattern.

Key Takeawaysโ€‹

Let's run through the core features, deployment modes, ingestion pipeline architectures, and DVA-C02 exam tips.

๐Ÿ”Ž What is Amazon OpenSearch Service?โ€‹

OpenSearch is a fully managed search and analytics engine derived from open-source ElasticSearch.

  • Key Advantage Over Databases: Unlike DynamoDB (which requires strict Partition/Sort key matching), OpenSearch can search across any field, supporting partial matches, fuzzy search, and auto-complete.
  • Query Interface: Uses OpenSearch Query DSL (Domain Specific Language) out of the box, with SQL support enabled via an optional plugin.
  • Visualization: Includes OpenSearch Dashboards (formerly Kibana) for interactive log analytics and data visualization.

๐Ÿ—๏ธ Provisioning Modesโ€‹

  1. Managed Clusters: You provision dedicated compute instances (data nodes, master nodes) across Availability Zones.
  2. OpenSearch Serverless: Automatically handles capacity management, scaling, and provisioning without managing underlying instances.

โš™๏ธ Real-World Architecture & Ingestion Patternsโ€‹

The DVA-C02 exam frequently tests how to get data into OpenSearch using common serverless pipelines:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ OPENSEARCH INGESTION ARCHITECTURES โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
โ”‚
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ–ผ โ–ผ โ–ผ
โšก Pattern A: DynamoDB + Streams ๐Ÿ“‘ Pattern B: CloudWatch Logs ๐ŸŒŠ Pattern C: Kinesis Data Streams
โ€ข User updates DynamoDB Table โ€ข CloudWatch Log Subscription Filter โ€ข Option 1: Firehose (Near Real-time)
โ€ข DynamoDB Stream triggers Lambda โ€ข Routes to Lambda or Kinesis Firehose โ€ข Option 2: Lambda Reader (Real-time)
โ€ข Lambda writes record to OpenSearch โ€ข Writes log payload into OpenSearch โ€ข Direct API write to OpenSearch

  1. App writes item to DynamoDB Table.
  2. DynamoDB Streams captures the insert/update/delete mutation.
  3. AWS Lambda polls the stream and syncs the payload into OpenSearch in real time.
  4. App searches OpenSearch for partial text (e.g., "straw hat") to fetch item IDs, then performs a high-speed GetItem call on DynamoDB!

๐Ÿ”น Pattern B: CloudWatch Logs Analyticsโ€‹

  • Subscription Filter โ”€โ”€โ–บ Lambda โ”€โ”€โ–บ OpenSearch: Real-time log streaming via managed Lambda execution.
  • Subscription Filter โ”€โ”€โ–บ Kinesis Data Firehose โ”€โ”€โ–บ OpenSearch: Near real-time, high-volume buffered log ingestion without writing custom Lambda code!

๐Ÿ”น Pattern C: Kinesis Data Streamsโ€‹

  • Kinesis Data Streams โ”€โ”€โ–บ Kinesis Data Firehose โ”€โ”€โ–บ OpenSearch: Near real-time ingestion with built-in buffering and automatic scaling.
  • Option 2: Kinesis Data Streams โ”€โ”€โ–บ Lambda โ”€โ”€โ–บ OpenSearch: Real-time ingestion with custom transformation logic in Lambda.

Exam Tipsโ€‹

  • The DynamoDB Partial Search Trap ๐Ÿšจ: If a scenario describes a DynamoDB table storing product catalogs or user profiles where users now need to perform fuzzy searching or partial name matching across unindexed fieldsโ€”select streaming DynamoDB updates via DynamoDB Streams + Lambda into Amazon OpenSearch Service.
  • Near Real-time vs. Real-time Ingestion:
    • If the pipeline requires zero code / built-in buffering for high throughput: Kinesis Data Firehose โ”€โ”€โ–บ OpenSearch.
    • If the pipeline requires sub-second custom transformations: Kinesis Data Streams / DynamoDB Streams โ”€โ”€โ–บ Lambda โ”€โ”€โ–บ OpenSearch.