Amazon OpenSearch Pricing: 5 Costs the Pricing Page Hides

Here's a scenario I see regularly on AWS re:Post: someone builds a Bedrock Knowledge Base, tests a RAG chatbot, decides it's not the right approach, deletes the Knowledge Base - and then spends the next two months confused about why OpenSearch charges keep appearing on their bill.

The answer: deleting a Bedrock Knowledge Base does not delete the OpenSearch Serverless collection it created. That collection keeps billing at roughly $350/month indefinitely, with no warning, until you manually delete it from a completely different AWS console.

That's one of five situations where Amazon OpenSearch pricing surprises teams. The others are the EBS storage multiplier effect on provisioned clusters, extended support surcharges on end-of-life engine versions, serverless minimum billing floors that behave like always-on infrastructure (not like Lambda), and data transfer costs hiding in plain sight.

This guide covers all of it - managed clusters, serverless, OR2/OM2 instances, storage tiers, vector search pricing, and the Bedrock Knowledge Base trap - with real dollar amounts throughout.

All pricing reflects US East (N. Virginia) rates from the official OpenSearch pricing page as of March 2026. Regional rates vary.

OpenSearch Pricing at a Glance

Before going deep on each component, here's the full billing picture. Amazon OpenSearch has two deployment models with fundamentally different cost structures.

The Two Deployment Models and What They Cost

Managed Clusters (provisioned infrastructure) charge for:

• Instance hours - per-hour rate for each data node and master node
• EBS storage - per GB-month for attached volumes on each node
• Data transfer - standard AWS EC2 rates for internet-bound and cross-region traffic
• Managed Storage - $0.024/GB-month for S3-backed replicas on OR1/OR2/OM2/OI2 instances

OpenSearch Serverless charges for:

• Indexing OCU-hours - compute consumed by data ingestion
• Search OCU-hours - compute consumed by queries
• Managed Storage - per GB-month stored in S3

Both models are now covered by Database Savings Plans, which launched on March 5, 2026. Managed Clusters also support traditional Reserved Instances. More on the savings options later.

A quick reference for the main pricing dimensions:

What Is Not Free (and What Is)

There is no free tier for Amazon OpenSearch. Unlike Lambda or DynamoDB, you cannot run a meaningful test workload within any free tier allocation.

A few components that are included at no extra charge:

• Automated snapshots - free storage per domain, retained 14 days
• OpenSearch Dashboards - included with the service
• Multi-AZ with Standby - no additional charge versus equivalent 3-AZ configurations
• Intra-domain node-to-node data transfer - free

One gotcha: when you open the OpenSearch Service console and create a new domain, the default instance type shown is r7g.medium. That's not free-tier eligible - it's a $0.163/hr instance. There's no console warning to that effect. Teams running quick tests often end up with a running domain they forgot about.

Manual snapshots (as opposed to automated ones) are stored in Amazon S3 at standard S3 storage rates. The 14-day automated snapshot window is enough for most recovery scenarios, but if you need longer retention you're paying S3 storage costs for those additional snapshots.

Now let's break down each model starting with managed clusters.

Managed Cluster Pricing

The provisioned model gives you predictable costs in exchange for managing capacity yourself. Here's what actually shows up on your bill.

The pricing page lists per-hour rates, which is a clean abstraction. What it doesn't show you is how instance topology multiplies storage costs in ways that catch teams by surprise.

Instance Hours - The Main Cost Driver

Managed Clusters charge per instance-hour for each node in your domain. Billing starts when the instance is available and continues until the domain is deleted. Partial hours are billed as full hours.

Current-generation Graviton instance rates (US East N. Virginia):

For a complete instance pricing table, use the official OpenSearch pricing page - OR2, OM2, and OI2 have many sizes and I'll only reference the specific rates from the research data above.

Dedicated master nodes (cluster manager nodes) add to your instance count. A 3-AZ production domain typically needs 3 dedicated master nodes to maintain quorum during AZ failures. These are often overlooked when estimating costs.

EBS Storage - Where Costs Multiply Across Nodes

This is where teams consistently underestimate storage costs by 3-10x. Here's why:

With a standard 3-replica sharding setup across 3 data nodes, a 100 GB dataset occupies 300 GB of EBS storage (3 replicas, one per node). Add sharding overhead and you're often at 3.5-4x your actual data size. Each node holds its own volume - there's no shared storage across nodes in a provisioned cluster.

EBS volume rates:

There is no reason to use gp2 for new domains. gp3 is cheaper ($0.122 vs. $0.135/GB-month) and delivers better performance. If you have existing domains on gp2, this is a low-effort migration worth doing.

Data Transfer and Other Charges

Node-to-node traffic within a domain is free. External traffic is billed at standard EC2 rates:

• Data transfer to the internet: standard EC2 egress rates (~$0.09/GB first 10 TB in US East)
• Cross-region data transfer: varies by source and destination region
• Cross-AZ traffic for OpenSearch domain operations: free within the service

Cross-AZ data transfer between your application and the OpenSearch endpoints can still accrue charges if your compute is in a different AZ than the domain nodes you're hitting. This is typically small but worth knowing about.

Real Example: What a 3-AZ Production Domain Costs

Here's a complete cost breakdown for a realistic production domain using the research data: 3x r6g.xlarge.search data nodes, 3x c6g.large.search cluster manager nodes, 2x ultrawarm1.medium.search warm nodes, 500 GB EBS per data node.

That's before any data transfer charges, manual snapshots, or UltraWarm warm data storage beyond the 3 TB shown. Before committing to Reserved Instances for a domain like this, right-size it first - the AWS Well-Architected OpenSearch Lens recommends checking that sustained CPU stays below 40% and JVM heap below 50% before sizing up.

Managed clusters give you cost predictability. Serverless is a different story.

OpenSearch Serverless Pricing

Serverless removes the infrastructure management burden, but it introduces a minimum billing floor that trips up almost everyone who encounters it for the first time.

OpenSearch Serverless doesn't bill like Lambda (pure pay-per-invocation). It maintains a minimum provisioned capacity floor that runs even when your collection is idle, which is why the Bedrock scenario described in the intro keeps surprising people.

OCU-Hours Explained

The billing unit for OpenSearch Serverless is the OpenSearch Compute Unit (OCU). Each OCU contains 6 GB of RAM, a corresponding vCPU, GP3 storage for frequently accessed data, and data transfer to S3.

OpenSearch Ingestion (the managed pipeline service) uses a different OCU spec: 1 Ingestion OCU = 15 GB RAM + 2 vCPUs. The composition varies by service component, so it's worth noting when you see OCU pricing quoted without context.

Serverless bills separately for indexing OCUs (compute used for data ingestion) and search OCUs (compute used for queries). Both are charged at $0.24/OCU-hour in US East (N. Virginia). Regional rates vary - check the live pricing page for your target region.

The Minimum Floor: 2 OCUs for Production, 1 for Dev/Test

This is the number most documentation glosses over. Here's how the minimums work:

Production (redundancy enabled): The first collection in your account requires a minimum of 2 OCUs: 1 OCU (0.5 x 2) for indexing (primary + standby) and 1 OCU (0.5 x 2) for search (primary + HA replica).

At $0.24/OCU-hour × 730 hours/month × 2 OCUs: roughly $350/month minimum, even idle.

Dev/test (redundancy disabled): The minimum drops to 1 OCU total: 0.5 OCU for indexing + 0.5 OCU for search. That's roughly $175/month minimum for a dev/test collection.

Subsequent collections that share the same encryption key don't add to the minimum - they share the existing OCU pool. But there's an important exception: vector search collections cannot share OCUs with search or time series collections even if they use the same KMS key. A vector search collection always provisions its own minimum OCU set.

The default account-level cap is 10 OCUs each for indexing and search. If you hit those limits during high traffic, scaling stops. The maximum is 1,700 OCUs per account.

Here's a quick cost reference for three capacity configurations:

That minimum floor is exactly what catches Bedrock users off guard.

The Bedrock Knowledge Base Cost Trap

This section exists because no other pricing guide covers it - but it's the most common reason people end up on AWS re:Post asking why they have a mysterious OpenSearch charge on their bill.

When Amazon Bedrock added Knowledge Bases, AWS made OpenSearch Serverless the default vector store because it requires zero infrastructure setup. The problem is how seamlessly this happens, and what doesn't happen when you clean up.

What Bedrock Auto-Provisions and When Billing Starts

When you create a Bedrock Knowledge Base using the quick-create flow (the default path most people follow), AWS automatically creates an OpenSearch Serverless collection in your account to store the vector embeddings. This happens in the background without a cost confirmation step.

Billing on that OpenSearch Serverless collection starts immediately upon collection creation - not when you first index a document, not when you run your first query. The collection exists, so the 2 OCU minimum applies from minute one.

What Does Not Auto-Delete

Deleting a Bedrock Knowledge Base removes the Bedrock configuration - data source connections, chunking settings, embedding model configuration. It does not remove the OpenSearch Serverless collection that was created to back it.

You must go to the Amazon OpenSearch Service console (separate from the Bedrock console), navigate to Serverless > Collections, find the collection (usually named something like bedrock-knowledge-base-<id>), and delete it explicitly.

Until you do that, you're paying the production minimum of ~$350/month for an idle collection. If you've used Bedrock Knowledge Bases before and haven't done this cleanup, check your OpenSearch Serverless collections now.

A note on research coverage: the exact console flow for Bedrock Knowledge Base creation changes as AWS updates the product. The billing behavior described here (auto-provisioning, independent deletion requirement) is based on community reports from AWS re:Post and developer forums as of early 2026. Verify the current cleanup steps against the AWS Bedrock documentation before actioning.

Your Three Options: Serverless, Managed Cluster, or S3 Vectors

Bedrock Knowledge Bases now support multiple vector store backends - you don't have to accept the OpenSearch Serverless default.

Option 1: OpenSearch Serverless (default) - best for large-scale production RAG with high query volume and unpredictable load. $350/month floor even idle. Poor choice for small test projects.

Option 2: OpenSearch Managed Cluster - you provision and manage the cluster. Can be cheaper for predictable, smaller workloads. More operational overhead.

Option 3: S3 Vectors - launched as a lower-cost alternative specifically for vector storage. Storage runs $0.06/GB-month, query API runs $2.50/million queries. For a small prototype with a few million embeddings and moderate query volume, S3 Vectors is dramatically cheaper than the $350/month serverless floor.

Here's the math for a 100M-vector scenario (1024 dimensions, 2KB metadata, 1M queries/month):

Compare that to a dedicated OpenSearch Serverless vector collection at the same scale - you'd need significantly more than 2 OCUs for 100M vectors at any real query load, and you're starting from a higher base. For smaller workloads (a few million vectors, low query volume), S3 Vectors often comes in well under $100/month versus $350+ for serverless.

For a full breakdown of Amazon Bedrock costs including Knowledge Base alternatives, see the Bedrock pricing guide.

Now that you know the trap, let's talk about how storage tiering affects your ongoing OpenSearch costs.

Storage Tiers: Hot, UltraWarm, Cold, and Managed Storage

Log analytics workloads are the primary driver of large OpenSearch storage costs, and they're also where the tiering economics are most dramatic. Understanding the four tiers and when each applies directly translates to lower bills.

Most teams know UltraWarm and cold storage exist. Fewer do the actual dollar math to understand when moving data between tiers is worth the operational overhead. Let me show you the math.

Hot Storage (EBS gp3 vs. gp2)

Hot storage is your default: EBS volumes attached to data nodes supporting full read-write operations. Everything in your domain lives in hot storage unless you explicitly move it.

Rate comparison:

• gp2: $0.135/GB-month
• gp3: $0.122/GB-month

gp3 is 9.6% cheaper than gp2 and delivers equal or better performance (configurable IOPS and throughput without the burst credit mechanics of gp2). If you have existing domains on gp2, migrating to gp3 is straightforward through the console or via your IaC tool and requires no downtime. There's no defensible reason to stay on gp2.

For io1 (provisioned IOPS), you pay both storage and per-IOPS charges. I/O operations themselves aren't billed separately - it's a provisioned capacity model.

UltraWarm and Cold Storage: When the 80% Savings Is Real

UltraWarm stores data in S3 with a local caching layer on dedicated warm nodes. Data is read-only once moved to warm - you can't index new documents into UltraWarm directly.

• UltraWarm rate: $0.024/GB-month (same managed storage rate, billed as managed storage)
• That's an 80% reduction versus gp3 hot storage

But UltraWarm has prerequisites: OpenSearch 6.8+, dedicated master nodes, and no T2/T3 data nodes. If you're on a single-node development domain, you can't use it.

Cold storage goes further: data is detached from warm nodes entirely and sits in S3 at S3 storage rates. No warm node instance cost while cold. Data must be migrated back to warm before it can be queried, which takes time (minutes to hours depending on index size).

Here's the concrete dollar math at three data volumes:

At 10 TB, moving from hot to UltraWarm saves ~$1,003/month. For log data you're keeping for compliance but rarely querying - older-than-30-days application logs, for example - that's real money sitting on the table.

The catch is operational: you need Index State Management (ISM) policies to automate the hot-to-warm-to-cold-to-delete lifecycle. Without automation, stale hot data accumulates. Writing ISM policies takes a few hours; the savings can be hundreds of dollars per month within weeks.

Managed Storage (OR1/OR2/OM2/OI2): S3 Replicas That Eliminate EBS Costs

The OpenSearch Optimized instance families (OR1, OR2, OM2, OI2) use a different storage architecture: local NVMe SSDs for caching and remote S3 for durable storage. Replicas are stored in S3 instead of on additional EBS volumes.

• Managed Storage rate: $0.024/GB-month
• Same rate as UltraWarm, but for a different reason - this is your primary data storage, not a warm tier

On traditional instances (r6g, m6g, etc.), a 3-node cluster with 2 replicas stores 3x your data volume on EBS. On OR2/OM2 instances, replica data goes to S3 at the lower managed storage rate. The EBS cost doesn't disappear entirely (you still need local SSD for active data and caching), but the replica overhead shifts to a much cheaper pricing tier.

Choosing the right storage tier is important, but choosing the right instance type determines how efficiently you use that storage.

Instance Selection in 2026

The instance selection question has a clearer answer than it did two years ago. Three new instance families launched in 2025 and they're better in almost every dimension that matters for production OpenSearch workloads.

Most teams running OR1, R7g, or earlier generations should evaluate migrating. Here's what changed and why it matters.

Current-Generation: OR2, OM2, OI2 (and Why OR1 Was Just the Start)

AWS released three OpenSearch Optimized instance families in 2025:

OR2 (compute/memory-optimized, released March 2025): Up to 26% higher indexing throughput than OR1, up to 70% more than R7g. Uses S3-backed managed storage for replicas - eliminates replica EBS costs. Available from medium through 16xlarge; now in GovCloud as of March 2026.

Sample rate: or2.2xlarge.search at $0.80/hr.

OM2 (memory-optimized, released March 2025): Up to 15% higher throughput than OR1, up to 66% more than M7g. Same S3-replica architecture as OR2. Available from large through 16xlarge.

Sample rate: om2.large.search at $0.153/hr.

OI2 (I/O-optimized, released December 2025): The most interesting addition. Up to 9% higher throughput than OR2, uses 3rd-generation AWS Nitro SSDs. The key feature: OI2 supports a writable warm tier - unlike traditional UltraWarm which is read-only, OI2-based warm nodes support write operations. Requires OpenSearch 3.3 or later. Available in 12 regions.

Sample rate: oi2.2xlarge.search at $1.16688/hr.

An instance family comparison at a glance:

For full pricing tables across all OR2, OM2, and OI2 sizes, check the official pricing page - I'm only referencing the specific rates from the AWS research data.

When to Use General Purpose vs. Memory vs. Compute Optimized

My recommendation for most new production deployments in 2026: start with OR2. The combination of higher indexing throughput and S3-backed replicas (eliminating EBS replica costs) makes it the right default for log analytics and full-text search workloads.

If your workload is more read-heavy with large indexes that need to fit in RAM - think security analytics or compliance search over years of data - OM2's additional memory density is worth considering.

OI2 is specifically worth evaluating if you want to run a writable warm tier. Traditional UltraWarm is read-only, which means you can't direct new writes to warm nodes. OI2 changes that architectural constraint, which matters for workloads where you want to write to warm storage directly instead of migrating data from hot through ISM policies.

Previous-generation r6g and m6g instances should be on the migration list unless there's a specific version or configuration constraint keeping them in place.

The Writable Warm Tier: What OI2 Changes About Storage Economics

Traditional UltraWarm (ultrawarm1 instances) requires hot-tier data nodes to be separate from warm-tier nodes. Data is written to hot storage first, then migrated to warm through ISM policies. This creates a window where your most recent data is always on expensive EBS storage.

With OI2 and OpenSearch 3.3+, you can configure warm nodes that accept writes directly. The implication: for workloads where you're OK with warm-tier query performance characteristics, you can skip the hot tier for incoming data entirely. Your newest logs go straight to warm-tier storage at $0.024/GB-month instead of $0.122/GB-month on EBS.

OI2's addressable warm storage is up to 5x its local cache size. A domain with 1,875 GiB of OI2 instance storage can address up to 7,500 GiB of warm data. Standard Managed Storage charges apply at $0.024/GB-month for all warm data.

Here's what a full OI2 writable warm domain costs (3x or2.2xlarge data nodes + 3x r8g.large cluster managers + 3x oi2.2xlarge warm nodes, from the research data):

This is a substantial cluster with real warm-tier capacity. The $540/month in warm managed storage covers 22.5 TB of addressable warm data - compare that to $2,745 for the same 22.5 TB on EBS gp3.

If you're running AI or vector search workloads specifically, there are additional pricing dimensions to know about.

Vector Search and AI Workloads

OpenSearch has expanded significantly for AI workloads in 2025 and 2026. The pricing model has multiple new components that most guides haven't caught up to.

Standard vector ingestion uses the same OpenSearch Ingestion OCU pricing as any other ingestion workload - no separate charge for indexing vectors. But beyond that, there are three additional dimensions worth understanding.

GPU-Accelerated Vector Indexing OCUs

For large-scale vector indexing, OpenSearch can use GPU-accelerated OCUs to speed up HNSW index construction. One Vector Acceleration OCU contains 6 GB GPU memory, 8 GiB RAM, and 2 vCPUs.

These activate automatically when your indexing throughput exceeds a configurable threshold. The math works out neatly: doubling the OCU count halves processing time, so total cost stays roughly constant regardless of scale-out. You pay for speed, not for final throughput.

AWS handles auto-scaling and warm pooling for GPU OCUs - you're not billed for that management overhead.

S3 Vectors: The Lower-Cost Alternative for Large Vector Stores

S3 Vectors is AWS's purpose-built vector storage tier that delivers up to 90% lower storage costs compared to in-memory or EBS approaches.

S3 Vectors pricing (US East N. Virginia):

Vector size is calculated as (dimensions × 4 bytes) + metadata bytes + key bytes. For 1024-dimension vectors with 2KB metadata, that's roughly 4 KB per vector. 100 million vectors = approximately 397 GB of storage.

For workloads with large vector stores and moderate query volume, S3 Vectors can be significantly cheaper than maintaining an equivalent OpenSearch Serverless collection. The $2.50/million query cost only matters if you're actually querying at scale.

Disk-optimized vector search is another cost lever: it keeps only compressed vectors in RAM and stores full-precision vectors on disk. For large vector workloads, this reduces OCU requirements without sacrificing query quality - worth evaluating before scaling up OCU count.

Semantic Enrichment Pricing

Semantic Enrichment handles automatic embedding generation during ingestion. Instead of calling an external embedding model yourself, you configure OpenSearch to run the embedding at ingest time.

• 1 Semantic Search OCU = CPU + GPU + memory for semantic encoding
• Rate: $0.24/Semantic Search OCU-hour
• Processing capacity: ~45 MB (11.1 million tokens) of English content per OCU; ~30 MB (7.3 million tokens) for multilingual content

For a concrete example: ingesting 10 GB of English product descriptions:

• ~2.4 billion tokens
• 2.4B ÷ 11.1M tokens/OCU = ~216 Semantic Search OCU-hours
• 216 × $0.24 = ~$51 one-time ingestion cost

This is a one-time cost per ingestion run, not an ongoing charge. Search operations and data storage don't add to it.

One note: Vector Auto-Optimize jobs charge a fixed fee per job (each job runs hyperparameter optimization to find the best index configuration). The specific dollar amount isn't published in AWS documentation - check the live pricing page if you're planning to use this feature.

Whether you're running managed clusters or serverless, there are concrete steps to reduce your monthly bill.

How to Save Money on OpenSearch

The most effective cost reduction levers depend on your deployment model and where you are in your optimization journey. Here's what works in practice.

If you're on managed clusters and haven't committed to Reserved Instances or Savings Plans yet, the first question is whether your cluster is actually sized correctly. Buying RIs on an over-provisioned domain locks in waste for one to three years.

Reserved Instances vs. Database Savings Plans: Which to Use in 2026

Both options exist for managed clusters. Here's how to choose.

Reserved Instances (RIs): Up to 52% savings with 3-year All Upfront (AURI). Payment tiers:

T3.medium instances get lower discounts (18-32%) compared to standard instances.

RIs are instance-specific - a reservation for r6g.xlarge.search doesn't apply to or2.large.search. They can't be cancelled or transferred. If you buy RIs and then migrate to OR2/OM2 instances, the old RIs keep billing until they expire.

Database Savings Plans (new, March 5, 2026): Up to 35% savings with a 1-year commitment. Flexible across instance families, instance sizes, regions, and both deployment models (provisioned and serverless). No upfront payment required.

The trade-off: 35% maximum versus 52% maximum for RIs. But if you expect to change instance types within the year - which you probably should, given that OR2/OM2 are newer and better - Savings Plans let you capture discounts while staying flexible.

My take: if you have a stable, mature production cluster you're confident you'll keep running on the same instance family for 3 years, the 3-year AURI RI discount (52%) wins on pure math. For most teams evaluating their options in 2026, the flexibility of Database Savings Plans outweighs the extra 17% discount ceiling. You don't need to choose an instance family upfront.

Also worth knowing: Savings Plans can be combined with RIs for different workloads in the same account. You can RI-commit your stable primary cluster and use a Savings Plan for your secondary clusters.

Right-Sizing: The Three CloudWatch Metrics That Reveal Waste

Before buying any discounts, confirm you're not over-provisioned. Three metrics to check in CloudWatch:

1. CPUUtilization - sustained average above 40% means the domain is appropriately sized (or undersized). Below 20% consistently is a signal to scale down.
2. JVMMemoryPressure - should stay below 50% consistently. Above 75% risks garbage collection pauses; below 30% consistently suggests over-provisioned heap (which means over-provisioned instance size).
3. FreeStorageSpace - sustained above 50% free suggests EBS volumes can be reduced.

The AWS Well-Architected OpenSearch Lens (AOSCOST05-BP01) explicitly recommends right-sizing before purchasing reservations. An r6g.xlarge running at 15% CPU and 25% JVM pressure is probably doing the work of an r6g.large - and buying 3-year RIs on the xlarge locks in that overspend.

Extended Support Fees: The Quiet Per-NIH Charge You May Already Be Paying

Any domain running an engine version in Extended Support (beyond Standard Support lifecycle) pays a flat fee per Normalized Instance Hour (NIH) on top of standard instance costs.

NIH = instance size factor × number of instance hours. The size factor varies by instance family.

Extended Support fee by region (selected):

For a full regional table, see the official pricing page.

For a 3-node r6g.xlarge domain (size factor = 4, so 1 xlarge = 4 NIH per hour) running 730 hours: 3 nodes × 4 NIH × 730 hours = 8,760 NIH/month. At $0.0065/NIH in US East: roughly $57/month in extended support fees on top of instance costs. Not catastrophic - but it's an avoidable charge that grows with cluster size.

The fix: upgrade the engine version. AWS provides at least 12 months of critical security fixes under Extended Support, but you're paying extra for that window. Treat engine version upgrades as scheduled quarterly maintenance, not a reaction to end-of-support notices.

Shard Optimization and Index Lifecycle Management

Two final strategies with meaningful storage impact:

Derived Source (OpenSearch 3.1+): Eliminates storage of the _source field by reconstructing it dynamically from indexed fields. The _source field typically consumes 30-50% of total index storage. Enabling Derived Source at index creation time removes that overhead. For large indexes, this can cut storage bills nearly in half. It's an opt-in setting at index creation - you can't apply it to existing indexes without reindexing.

Shard sizing: AWS recommends keeping shards in the 10-50 GiB range with no more than 25 shards per GiB of JVM heap and no more than 1,000 shards per data node. Over-sharding wastes CPU, memory, and JVM heap - clusters with hundreds of tiny shards often hit performance problems before storage limits.

Index rollups: For time-series data, rolling up historical records to coarser time intervals (seconds to hours, hours to days) dramatically reduces storage volume for older data that still needs to be queryable.

Once you've decided on a cost strategy, the final question is which deployment model to use.

Provisioned vs. Serverless: Cost Comparison at Real Workload Sizes

The general guidance you'll find everywhere is "serverless for variable workloads, provisioned for predictable ones." That's true but not useful without numbers. Let me show you the actual dollar comparison.

The core insight: serverless is not cheaper by default. At low and medium data volumes, a provisioned cluster almost always beats serverless on price. Serverless only wins when workload variability is extreme - and even then, the operational simplicity premium is real.

Side-by-Side Cost at 50 GB, 500 GB, and 2 TB

The breakeven point where serverless becomes cost-competitive is approximately when:

• Your workload varies by 5x or more between peak and off-peak usage, AND
• Your peak requires 3+ OCUs to sustain, AND
• Your off-peak legitimately drops to the 2 OCU floor (not pseudo-idle)

If your "variable" workload actually means "always on with occasional spikes," serverless will cost more than a right-sized provisioned cluster because you're paying for both the minimum floor and the spike headroom.

Decision Framework: When Serverless Actually Wins

Use managed clusters when:

• Workload is predictable and steady (buy RIs or Savings Plans for maximum discount)
• Data volume is large and query patterns are consistent
• You need specific index configurations or plugin access not available in serverless
• Your total OCU requirement during off-peak hours would be below the 2 OCU minimum

Use serverless when:

• Workload is genuinely intermittent with wide peak-to-trough variation
• You're building multi-tenant architecture with unpredictable per-tenant loads (collection groups allow multiple collections to share OCUs)
• The operational overhead of cluster management isn't worth it for your team size
• You're running automated testing environments where the operational simplicity pays for the cost premium

Consider S3 Vectors or Direct Query when:

• Workload is primarily AI/vector search with infrequent query patterns
• You need to query archival S3 data without ingesting it (Direct Query, $0.24/OCU-hour at per-minute granularity)
• Small prototype or proof-of-concept where the $350/month serverless floor is prohibitive

For a detailed feature comparison beyond cost - version upgrade management, VPC configuration, encryption requirements, and multi-AZ support - see the AWS comparison guide.

Key Takeaways

Amazon OpenSearch pricing has more moving parts than the official pricing page suggests. Here's what to take away from this guide:

1. Serverless is not pay-per-query. The 2 OCU production minimum means you're paying roughly $350/month even when idle. The dev/test minimum is ~$175/month. For small or occasional workloads, a provisioned t3.small.search domain is 10-20x cheaper.

2. Check your OpenSearch Serverless collections if you've used Bedrock Knowledge Bases. Deleting a Knowledge Base does not delete the underlying OpenSearch collection. If you've run a Bedrock KB experiment and haven't explicitly cleaned up the collection, it's billing you right now.

3. OR2/OM2 are the right default for new provisioned deployments. S3-backed replicas eliminate EBS replica costs, and they deliver 26-70% better throughput versus previous-generation instances. OI2 is the choice if you want a writable warm tier with OpenSearch 3.3+.

4. Database Savings Plans (March 2026) offer 35% savings with no upfront commitment. Better than Reserved Instances if you expect to change instance types within the year. Use RIs only if you're confident staying on the same instance family for 3 years.

5. UltraWarm can cut log storage costs by 80%. At 10 TB, the difference between hot EBS gp3 and UltraWarm is ~$1,003/month. If you're running log analytics without ISM lifecycle policies automating the tiering, you're almost certainly overpaying on storage.

For related database infrastructure cost guides, see Amazon RDS pricing and Amazon Aurora pricing. For a deep dive on Database Savings Plans across all 9 eligible services, see the Database Savings Plans guide.

To estimate your own OpenSearch costs, use the OpenSearch pricing calculator.

What are you running on OpenSearch - managed clusters, serverless, or a mix? Drop a comment below if you're trying to get a handle on a specific billing scenario.