Amazon OpenSearch Service costs can spiral quickly. Between instance hours, storage tiers, data transfer, snapshots, and commitment management, OpenSearch can become a six-figure AWS expense for organizations running search, log analytics, and observability workloads at scale.

The challenge isn't just the cost—it's understanding where that cost comes from. OpenSearch supports multiple deployment models, storage tiers, and pricing options, each with different optimization opportunities.

This guide explains how OpenSearch pricing works and the most effective ways to reduce costs, including right-sizing instances, implementing storage tiering, optimizing shard counts, purchasing Reserved Instances, and evaluating OpenSearch Serverless.

What Is OpenSearch Cost Optimization?

OpenSearch cost optimization means minimizing the cost of running Amazon OpenSearch Service without impacting search performance, query latency, and data availability. Optimization targets vary by organization, but many teams aim to reduce OpenSearch spend by 30-50% within 90 days while maintaining sub-second query latency (P95) and 99.9% availability for production workloads. This typically involves a combination of right-sizing overprovisioned nodes, purchasing Reserved capacity for stable baseline usage, migrating aged data to UltraWarm or Cold storage, reducing shard count, and eliminating waste in non-production environments.

Successful OpenSearch cost optimization requires understanding the difference between necessary costs (instance capacity to handle peak query load, storage for active indexes, three data nodes for availability) and unnecessary costs (idle cluster manager nodes in small clusters, hot storage for 6-month-old logs, 50 shards when 10 would suffice).

OpenSearch Pricing: Quick Overview

Before diving into optimization strategies, let's take a quick look at how pricing is calculated. Pricing differs significantly between Managed Clusters and Serverless deployments.

Managed Clusters charge for three components: instance hours, storage, and data transfer. Instance pricing depends on type (memory-optimized r7g, compute-optimized m7g, storage-optimized i4g), size (medium through 16xlarge), and region. A r7g.xlarge.search instance costs $0.388/hour ($3,399/year) in US East on-demand; the same instance as a 3-year All Upfront Reserved Instance costs $0.174/hour ($1,524/year) — a 55% discount.

Storage pricing varies by tier. Hot storage uses EBS volumes: gp3 costs $0.08/GB-month (recommended over gp2 for better performance at lower cost), while UltraWarm (S3-backed warm storage) costs $0.024/GB-month — 70% cheaper than gp3. Cold storage costs $0.015/GB-month — 80% cheaper than hot EBS.

Serverless charges separately for compute and storage. Compute capacity is measured in OpenSearch Compute Units (OCUs), which correspond to the vCPU, memory, and I/O resources required to index data or run queries. Each OCU costs approximately $0.24/hour. Storage costs $0.024/GB-month, identical to UltraWarm pricing. Serverless automatically scales both compute and storage based on workload demand, eliminating the need for capacity planning.

Data transfer charges apply to outbound traffic. Inbound data transfer and transfers between OpenSearch nodes within the same Availability Zone are free. Data transfer to clients in different AZs costs $0.01/GB; data transfer out to the internet costs $0.09/GB (first GB/month free). Cross-region replication incurs both data transfer and snapshot storage costs.

Reserved Instances (Managed Clusters only) provide 32-55% discounts compared to on-demand pricing in exchange for 1-year or 3-year commitments. The highest discount (55%) comes from 3-year All Upfront reservations; the lowest (32%) comes from 1-year No Upfront. Database Savings Plans offer 35% discounts with broader flexibility across instance families, regions, and deployment models (Managed + Serverless).

For a detailed pricing breakdown including instance type comparisons, storage tier economics, and Reserved Instance vs. Database Savings Plan trade-offs, see the nOps OpenSearch Pricing Guide.

OpenSearch Cost Optimization Strategies

Now let's talk about the strategies that can help you realize significant cost savings on OpenSearch.

Strategy 1: Right-Size Instances to Match Actual Workload Requirements

Overprovisioned OpenSearch instances are the most common source of waste. Teams select an instance size during initial deployment, scale up during a performance incident or traffic spike, and never revisit the decision. The result? Nodes running at 40% CPU, 50% JVM heap, and 60% storage utilization while billing at 100% of capacity.

The optimal utilization range for OpenSearch data nodes sits between 60-80% CPU, 65-85% JVM heap, and 70-85% storage during sustained workloads. This provides headroom for traffic spikes and ensures you're not triggering circuit breakers or causing GC pressure, while avoiding the waste of sub-50% utilization.

Start by pulling CloudWatch metrics for your OpenSearch domains over the past 30-60 days. Key metrics to analyze:

  • CPUUtilization: Monitor over time. Sustained CPU below 40% signals overprovisioning; sustained above 80% signals undercapacity.
  • JVMMemoryPressure: Measures percentage of Java heap used. Target 65-85%. Below 50% = overprovisioned; above 90% = risk of circuit breakers and query failures.
  • DiskQueueDepth: Measures pending read/write operations. High queue depth indicates I/O bottleneck.
  • ClusterStatus.yellow or .red: Yellow means missing replicas; red means missing primary shards. Indicates capacity or configuration issues.

Instance family selection matters as much as node size. AWS offers several OpenSearch-optimized instance categories:

Memory-Optimized (R family): Best for search-heavy workloads with large indexes. R7g (Graviton3) offers up to 25% better performance than R6g (Graviton2) at the same price. R6g instances deliver 40% cost reduction compared to previous-generation R5 instances by using AWS Graviton2 processors.

Compute-Optimized (M family): Best for indexing-heavy workloads. M7g provides better CPU performance than R family with less memory capacity. Ideal for log ingestion pipelines with high write throughput.

Storage-Optimized (I4g, OR1, OR2, OM2): OpenSearch-optimized instances use local NVMe or S3-backed storage for replicas. OR2 instances deliver 26% higher indexing throughput than OR1, 70% higher than R7g, and eliminate replica storage costs by storing replicas in S3 instead of EBS.

Cluster manager nodes: Only required for clusters with 3+ data nodes. Many teams overprovision cluster manager node size — a t3.small.search ($0.047/hour) is sufficient for most clusters with fewer than 50 data nodes.

Strategy 2: Implement Storage Tiering with UltraWarm and Cold Storage

Not all OpenSearch data needs to live in hot EBS storage. Older logs, historical metrics, and less frequently accessed data can move to lower-cost storage tiers while remaining searchable within OpenSearch Dashboards.

Hot storage (gp3 EBS) costs $0.08/GB-month. Use hot storage for active indexes queried frequently (multiple times per hour). gp3 volumes deliver baseline 3,000 IOPS and 125 MB/s throughput at no additional cost — better performance than gp2 with lower cost.

UltraWarm storage costs $0.024/GB-month — 70% cheaper than gp3. UltraWarm uses S3-backed storage with a local cache for frequently accessed data. Query latency increases from milliseconds (hot) to seconds (UltraWarm), making it ideal for indexes queried daily or weekly rather than continuously. Typical use cases include logs older than 7-30 days, historical metrics, and compliance data that must remain searchable but is rarely accessed.

Cold storage costs $0.015/GB-month — 80% cheaper than hot EBS. Cold storage is S3-only with no local cache. Query latency measures in tens of seconds to minutes. Use Cold storage for archives, compliance retention, and infrequently accessed data queried monthly or quarterly.

Index State Management (ISM) policies automate data lifecycle transitions. Configure ISM to automatically migrate indexes from hot to UltraWarm after 7 days, UltraWarm to Cold after 90 days, and delete from Cold after 365 days (or your compliance retention requirement).

For a 10 TB OpenSearch domain storing 6 months of logs, migrating everything older than 7 days to UltraWarm and everything older than 90 days to Cold can reduce storage costs from $800/month (all hot) to $280/month (tiered) — a 65% reduction.

Strategy 3: Purchase Reserved Instances for Stable Baseline Usage

OpenSearch Reserved Instances deliver 32-55% discounts compared to on-demand pricing in exchange for 1-year or 3-year capacity commitments. The discount structure works like this:

  • 1-Year No Upfront Reserved Instance: ~32% savings, monthly billing
  • 1-Year All Upfront Reserved Instance: ~40% savings, pay full term upfront
  • 3-Year Partial Upfront Reserved Instance: ~50% savings, ~50% upfront + monthly billing
  • 3-Year All Upfront Reserved Instance: ~55% savings, pay full term upfront

For a r7g.xlarge.search instance in US East ($0.388/hour on-demand), a 3-year All Upfront reservation costs $4,572 upfront ($0.174/hour effective rate) — saving $1,875 per node per year compared to on-demand.

The challenge with Reserved Instances is commitment risk. If you purchase too much reserved capacity and your workload shrinks (consolidate indexes, reduce retention, migrate to Serverless), you're stuck paying for unused reservations. If you purchase too little, you leave savings on the table by running too much on-demand capacity.

Most teams achieve 60-75% reserved coverage because manually managing commitments across dozens of OpenSearch domains becomes unsustainable. The operational overhead of tracking expiration dates, forecasting stable baseline usage 12-36 months in advance, and purchasing new reservations at optimal intervals prevents higher coverage rates.

Alternative: Database Savings Plans offer 35% discounts with broader flexibility across OpenSearch deployment models (Managed Clusters + Serverless), instance families, and regions. Savings Plans automatically apply to eligible usage regardless of instance type or deployment model, making them ideal for environments running both Managed and Serverless or experimenting with different instance families. The trade-off? Lower maximum discount (35% vs. 55%).

Automated commitment management systems address manual tracking burden by purchasing micro-commitments every 8-14 days in a "laddering" pattern, building staggered coverage that matures in waves instead of one massive block. This approach typically achieves 93-96% coverage while maintaining flexibility to adjust capacity within 2-4 weeks.

Strategy 4: Optimize Shard Count and Size to Reduce Overhead

Over-sharding is a hidden cost driver in OpenSearch — too many small shards waste CPU, memory, and JVM heap managing shard metadata and routing queries across hundreds or thousands of shards unnecessarily.

Recommended shard sizes: 10-50 GiB per shard depending on workload type. Log analytics and time-series data typically target 20-30 GiB per shard; full-text search workloads with complex queries target 10-20 GiB per shard.

Maximum shard limits: No more than 25 shards per GiB of Java heap, no more than 1,000 shards per data node. Exceeding these limits causes OpenSearch cluster instability, slow query response, and excessive JVM heap pressure.

Common over-sharding scenarios:

  • Default 5 primary shards per index: Many teams accept the OpenSearch default of 5 primary shards without considering index size. A 2 GiB index doesn't need 5 shards; 1 shard is sufficient.
  • Daily indexes with 5 shards each: Ingesting 100 GB/day with daily indexes (my-logs-2026-06-16) creates 5 shards per day = 1,825 shards per year. Consolidating to weekly indexes (my-logs-2026-W25) with 3 shards each reduces annual shard count to 156 — a 92% reduction.
  • Unbounded replica count: Replicas provide availability but double (1 replica) or triple (2 replicas) shard count. For non-critical environments, consider 0 replicas. For production, 1 replica provides 99.9% availability without the overhead of 2 replicas.

Use ISM rollover policies to control index growth and avoid unbounded shard proliferation.

For read-only indexes (no longer ingesting data), run force merge to reduce segment count and reclaim storage from deleted documents. Force merge consolidates multiple segments into fewer, larger segments, improving query performance and reducing storage overhead.

Strategy 5: Use OpenSearch Serverless for Variable or Unpredictable Workloads

OpenSearch Serverless eliminates capacity planning by automatically scaling compute (OCUs) and storage independently based on workload demand. This makes Serverless ideal for workloads with highly variable traffic patterns, development/staging environments, and new projects where usage patterns are unknown.

When Serverless makes sense:

  • Variable traffic: Search traffic fluctuates 10x between peak and off-peak hours. Serverless scales OCUs down during quiet periods, Managed Clusters bill for full capacity 24/7.
  • Development/staging: Non-production environments sit idle nights and weekends. Serverless scales to near-zero OCUs when idle; Managed Clusters bill for minimum 3-node cluster continuously.
  • Proof-of-concept projects: Unknown usage patterns make capacity planning impossible. Serverless auto-scales; Managed Clusters require educated guesses about instance type and count.

When Managed Clusters are more cost-effective:

  • Steady-state production workloads: Predictable traffic patterns with 80%+ utilization make Reserved Instances cheaper than Serverless pay-per-OCU pricing.
  • Large sustained workloads: Serverless OCU costs scale linearly; Managed Clusters with Reserved Instances offer better economics at scale.
  • Fine-grained control requirements: Managed Clusters expose instance type, shard count, replica count, and JVM configuration; Serverless abstracts these details.

Serverless cost optimization techniques:

  • Set maximum OCU limits: Prevent runaway costs by capping maximum indexing and search OCUs. Default limits are generous; most workloads need lower caps.
  • Use disk-optimized vector search: For vector workloads (RAG pipelines, semantic search), disk-optimized mode keeps compressed vectors in RAM and full-precision vectors on disk, reducing memory requirements by 97% versus in-memory mode. This translates to 67-83% cost reduction for vector search workloads.
  • Enable GPU-accelerated vector indexing: For large-scale vector ingestion, GPU acceleration reduces index build time by 6-14x and OCU costs by up to 75%.

OpenSearch Cost Optimization Best Practices

Beyond specific strategies, these best practices prevent waste before it starts:

1. Tag all resources for cost allocation.

Use AWS cost allocation tags to track OpenSearch spend by team, project, environment, or customer. Tags enable showback reports that make teams accountable for their OpenSearch usage.

2. Set data retention policies aligned to compliance requirements.

Never store data indefinitely. Define maximum retention windows (30 days for debug logs, 90 days for application logs, 7 years for financial audit logs) and use ISM policies to automatically delete aged indexes. Retention policies are the single most effective way to control data storage growth.

3. Optimize index mappings to reduce storage footprint.

Avoid indexing or storing fields that are never queried. Remove complex analyzers where simple keyword matching suffices. Disable the `_source` field for indexes where you only need search aggregations and never need to retrieve original documents — this eliminates 30-50% of storage overhead.

4. Use index rollups to aggregate historical time-series data.

For metrics and IoT data, keep per-second granularity for recent periods and roll up to hourly or daily summaries for older data. Rollups reduce storage volume by 90%+ while preserving trend analysis capability.

5. Monitor deleted documents ratio and force merge read-only indexes.

Deleted documents consume storage until segments are merged. For indexes with 15%+ deleted documents, run force merge to reclaim storage and improve query performance.

6. Avoid extended support costs — upgrade to current OpenSearch versions.

AWS charges a flat fee per Normalized Instance Hour for engine versions in Extended Support. Staying on older unsupported versions incurs additional charges on top of instance costs. Upgrade to current supported versions to avoid Extended Support fees.

7. Use gp3 EBS volumes instead of gp2 for hot storage.

gp3 delivers better baseline performance (3,000 IOPS, 125 MB/s throughput) at lower cost than gp2 with no burst credits required. gp3 is more stable because it doesn't rely on burst credits that deplete under sustained I/O.

8. Evaluate OR1/OR2/OM2 OpenSearch-optimized instances.

These instances store replicas in S3 instead of EBS, eliminating replica storage costs. OR2 delivers 26% higher indexing throughput than OR1 and 70% higher than R7g while providing up to 30% price-performance improvement.

Automating OpenSearch Cost Optimization at Scale

While these practices are effective, executing them consistently across hundreds of clusters and multiple AWS accounts is difficult without automation.

OpenSearch cost optimization isn't a one-time project — it's continuous operational work. Commitment management demands constant tracking of expirations, utilization rates, and new purchase timing. Cost allocation needs consistent tagging enforcement and showback reporting. At scale, this becomes a full-time job.

This is precisely the problem nOps is built to solve. It ingests your OpenSearch usage from AWS and continuously optimizes costs on your behalf.

  • Continuous, laddered rebalancing. nOps automatically manages commitments across OpenSearch to maximize your savings and flexibility. Savings are often 20% higher than competitors.
  • Full visibility. Get cost allocation, reporting, forecasting, anomaly detection, and the other visibility you need on your AWS, Azure, GCP, AI, SaaS and Kubernetes cost in a single pane of glass.
  • Savings-first, fully aligned. nOps charges a percentage of the savings it generates. If we don’t save you money, you don’t pay.

Curious how optimized you are on OpenSearch? A 30-minute free savings analysis shows you your current Effective Savings Rate and where the opportunities are. Setup is 5 minutes with no agents or infra changes needed.

nOps manages $4 billion in cloud spend for its customers and is rated 5 stars on G2.

FAQ

Let's dive into a few FAQ about OpenSearch data stored, resource consumption, vector data, and other related topics.

What's the difference between OpenSearch Reserved Instances and Database Savings Plans?

Reserved Instances deliver higher discounts (up to 55%) but lock you to specific instance families and regions. Database Savings Plans offer lower discounts (35%) but apply flexibly across OpenSearch deployment models (Managed + Serverless), instance families, and regions. Use Reserved Instances for stable production Managed Clusters; use Savings Plans for environments running both Managed and Serverless or experimenting with different instance types.

Should I use UltraWarm or Cold storage for aged logs?

Use UltraWarm for logs queried daily or weekly (latency in seconds). Use Cold storage for logs queried monthly or quarterly (latency in tens of seconds to minutes). If you need to query aged logs frequently, UltraWarm provides better query performance; if logs are purely for compliance retention and rarely accessed, Cold storage delivers maximum cost savings (80% cheaper than hot EBS).

How do I know if my OpenSearch domain is overprovisioned?

Monitor CloudWatch metrics over 30 days. Sustained CPU below 40%, JVM heap below 50%, and storage below 50% all signal overprovisioning. OpenSearch performs best with CPU 60-80%, JVM 65-85%, storage 70-85%. If all three metrics consistently fall below optimal ranges, downsize instance type or reduce instance count.

When should I use OpenSearch Serverless vs. Managed Clusters?

Use Serverless for variable traffic patterns, development/staging environments, and proof-of-concept projects where usage is unpredictable. Use Managed Clusters with Reserved Instances for steady-state production workloads with predictable traffic and high sustained utilization. Serverless excels at eliminating idle costs; Managed Clusters with reservations offer better economics for sustained workloads.

What is OpenSearch Serverless managed storage?

OpenSearch Serverless managed storage is the storage component of OpenSearch Serverless pricing. Unlike managed clusters, where storage is tied to EBS volumes or storage tiers such as UltraWarm and Cold, Serverless storage scales automatically and is billed separately from OpenSearch Compute Units (OCUs).

How do I implement cross-account access for OpenSearch?

OpenSearch supports cross-account access through IAM roles and resource-based policies, allowing teams to securely access domains across multiple AWS accounts. This is commonly used in multi-account AWS environments to centralize search, logging, and observability workloads while maintaining account-level isolation.