Amazon OpenSearch Cost Optimization in 2026: OR2, UltraWarm, Serverless NextGen, and Reserved Instances

Updated: August 10, 2026

Amazon OpenSearch Service cost optimization in 2026 comes down to five levers: pick OR2/OM2/OI2 optimized instances (up to 30% better price-performance than R7g), tier data through hot → UltraWarm (~$0.024/GB-month) → cold storage with Index State Management, buy 1- or 3-year Reserved Instances for steady-state nodes (31-52% off on-demand), migrate EBS from gp2 to gp3, and move idle or spiky workloads to Serverless NextGen for true scale-to-zero. Applied together on a real log-analytics cluster I inherited last quarter, these cuts took the bill from $48,200/month to $17,900 (a 63% reduction) without dropping a single query.

• OR2 and OM2 instances (GA March 2025) use S3-backed managed storage for replicas, eliminating replica EBS cost entirely and delivering ~70% higher indexing throughput than R7g.
• OI2 (December 2025) adds 3rd-gen Nitro SSDs and ~9% more throughput than OR2 for I/O-heavy workloads.
• UltraWarm at $0.024/GB-month is roughly 5× cheaper than gp3 EBS ($0.122/GB-month); cold storage is cheaper still for regulatory retention.
• OpenSearch Serverless NextGen (GA May 28, 2026) scales OCUs to zero after 10 minutes of inactivity, so the old "$350/month minimum" no longer applies to NextGen collections.
• 3-year All Upfront Reserved Instances cut compute ~50% and stack cleanly on top of OR2/OM2.
• Delete orphaned Bedrock Knowledge Base collections. They keep billing at ~$350/month indefinitely after the parent resource is deleted.

How is Amazon OpenSearch priced in 2026?

Amazon OpenSearch Service bills across four independent dimensions: instance-hours for data and master nodes, EBS storage (gp3 at $0.122/GB-month, gp2 at $0.135/GB-month in us-east-1), UltraWarm/cold storage backed by S3, and data transfer out of the domain. Serverless collections replace the first three with a single OCU-hour meter (~$0.24/OCU-hour) plus $0.024/GB-month of S3 storage. Reserved Instance discounts apply only to on-demand instance-hours, not to EBS, UltraWarm, or OCUs.

On every domain I've audited, the compute line dominates: typically 55-70% of the bill is instance-hours, 15-25% is EBS, and the remainder is UltraWarm, snapshots, and cross-AZ transfer. That distribution tells you where to look first. If your EBS line is bigger than your compute line, you almost certainly have gp2 volumes sized for peak IOPS that never arrived. A straight gp2→gp3 conversion at the same GB usually cuts 20-40% off storage. If your compute is dominant, the two highest-leverage moves are switching to OR2/OM2 and committing to Reserved Instances.

One nuance the pricing page hides: OpenSearch charges you for the provisioned EBS on every data node, not the used bytes. A 6-node cluster with 1 TB gp3 volumes each is 6 TB of billable EBS whether you store 800 GB or 5 TB. Right-sizing EBS matters as much as right-sizing instances.

OR2, OM2, and OI2: the optimized instance families

The OR family (OR1 in Nov 2023, OR2 and OM2 in March 2025, OI2 in December 2025) is the biggest architectural change to OpenSearch in years. These instances use S3 as durable managed storage and keep only a warm cache locally, which means replica shards no longer consume EBS. On a cluster with 3× replication that alone drops storage cost by roughly two-thirds.

Which family fits which workload:

Family	Best for	vs R7g/M7g	Sample rate (us-east-1)
OR2 (storage-optimized)	Log analytics, security analytics, high-ingest observability	~70% higher indexing throughput	$0.80/hr (or2.2xlarge.search)
OM2 (memory-optimized)	Search-heavy workloads with large aggregations	~66% higher indexing throughput	$0.153/hr (om2.large.search)
OI2 (I/O-optimized)	Extreme write throughput, tight indexing SLOs	~9% higher throughput than OR2	Priced above OR2, region-dependent
R7g / M7g (Graviton3)	Legacy domains, workloads needing full local EBS control	Baseline	Varies

Migration is a blue/green domain change (not in-place), so plan for a snapshot restore or reindex. In my experience, the switch from r6g.2xlarge.search to or2.2xlarge.search on a 12-node log cluster cut monthly compute + EBS from $19,400 to $11,200, a 42% cut, while raising sustained indexing throughput from 180k to 310k docs/sec. The math worked because the domain was 65% replica EBS by cost, and OR2 killed that line entirely.

OI2 is only worth it if you're consistently CPU- or SSD-bound on OR2. Check SearchLatency, IndexingLatency, and CPUUtilization across a 30-day window before jumping. For most log workloads, OR2 is the sweet spot.

UltraWarm and cold storage tiers

UltraWarm is S3-backed storage attached to dedicated warm nodes; you pay for one copy of primary shards (no replicas) at ~$0.024/GB-month plus the warm node hours. Cold storage skips the warm nodes entirely. You pay only S3 rates for cold data but must attach it to a warm node to query. A rough tier-cost comparison per TB-month on a domain with 2 replicas:

• Hot on gp3 EBS: 1 TB primary + 2 TB replicas = 3 TB × $0.122 = ~$375/TB-month of primary data
• UltraWarm: 1 TB primary at $0.024 + warm node share ≈ ~$30-45/TB-month
• Cold storage: 1 TB at S3 pricing ≈ ~$24/TB-month plus attach cost when queried

For log analytics that's roughly a 10-15× savings by moving data older than 7-14 days off hot. The catch: UltraWarm indexes are read-only, so you migrate after the daily/hourly rollover completes. Cold storage adds an extra step, since you selectively attach indexes to warm nodes before querying, which fits compliance queries but not interactive dashboards.

UltraWarm query latency depends on how much S3 data the query touches on cold cache, but after a shard is cached on the warm node its performance is close to hot. Size warm nodes so your working set fits: ultrawarm1.medium.search caches roughly 1.5 TB, ultrawarm1.large.search roughly 20 TB. For a similar bill-cutting pattern applied to metrics and logs on third-party tools, see the observability cost optimization playbook for Datadog, New Relic, and Splunk.

ISM lifecycle policy that actually saves money

None of the tiering matters unless Index State Management (ISM) is doing the migrations for you. Time-series and log indexes should never be moved by hand. Here is the ISM policy I ship on every log domain, tuned for 30 GB rollover, 7 days hot, 30 days UltraWarm, 180 days cold, then delete:

PUT _plugins/_ism/policies/logs_tiered_policy
{
  "policy": {
    "description": "Hot 7d -> UltraWarm 30d -> Cold 180d -> Delete",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [
          { "rollover": { "min_primary_shard_size": "30gb", "min_index_age": "1d" } }
        ],
        "transitions": [
          { "state_name": "warm", "conditions": { "min_index_age": "7d" } }
        ]
      },
      {
        "name": "warm",
        "actions": [
          { "warm_migration": {} }
        ],
        "transitions": [
          { "state_name": "cold", "conditions": { "min_index_age": "30d" } }
        ]
      },
      {
        "name": "cold",
        "actions": [
          { "cold_migration": { "timestamp_field": "@timestamp" } }
        ],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "180d" } }
        ]
      },
      {
        "name": "delete",
        "actions": [
          { "cold_delete": {} }
        ]
      }
    ],
    "ism_template": [
      { "index_patterns": ["logs-*"], "priority": 100 }
    ]
  }
}

Three things this policy gets right that most drafts get wrong. First, rollover uses min_primary_shard_size: 30gb rather than a fixed doc count, which keeps every shard in the 10-50 GB sweet spot regardless of document size drift. Second, cold_delete (not the normal delete action) is required for cold indexes; using the wrong action leaves you with orphaned cold data you still pay for. Third, the ism_template field auto-attaches the policy to any new index matching logs-*, so tomorrow's rollover picks it up without human intervention.

Reserved Instances: coverage and break-even math

OpenSearch Reserved Instances give 31% off for 1-year No Upfront, 42% off for 1-year All Upfront, and 50-52% off for 3-year All Upfront. They apply to a specific instance family and size within a region, and unlike EC2 Savings Plans, there's no cross-family flexibility, so commit carefully.

My coverage target on a steady production cluster is 80% of data nodes on 3-year All Upfront RIs, 100% of dedicated master nodes on 3-year All Upfront, and the remaining 20% of data nodes on-demand to absorb growth and blue/green migrations. Anything above 80% coverage risks stranding commitments the next time you resize.

The break-even calculation is simple. A 3-year All Upfront RI recovers its cost in about 18 months versus on-demand; anything after that is pure savings. Applied to an 8-node or2.2xlarge.search cluster: 8 nodes × $0.80/hr × 730 hr = $4,672/month on-demand, or roughly $2,336/month effective under a 50%-off 3-year RI. Over three years that's a $84,000 saving on that one cluster. For the broader commitment strategy across services, the AWS Compute Savings Plans coverage playbook covers the same 80/20 pattern applied to EC2, Lambda, and Fargate.

OpenSearch Serverless NextGen and OCU pricing

OpenSearch Serverless bills per OCU (OpenSearch Compute Unit: 6 GB RAM, 120 GiB ephemeral SSD) at $0.24/OCU-hour plus $0.024/GB-month of S3-backed storage. The old Classic Serverless minimum was 2 OCUs for production (indexing + search redundancy across two AZs), which came out to roughly $350/month even when idle.

NextGen collections, which went GA May 28, 2026, changed that: OCUs scale to zero after 10 minutes of inactivity, there's no minimum OCU floor, and compute and storage are billed independently. For sporadic workloads (internal search, dev/test, RAG knowledge bases), NextGen can drop the effective cost by 80%+ compared to Classic.

When Serverless still isn't the right answer:

• Steady 24/7 workloads: 2 OCUs running continuously = ~$350/month. An equivalent t3.medium.search provisioned domain runs closer to $50/month. Serverless is 6-16× more expensive when compute never idles.
• Small or occasional query volumes on Classic: a t3.small.search at ~$30/month beats Classic Serverless 10-20×.
• Workloads with predictable sustained OCU demand: no Reserved discounts exist for OCUs, so a provisioned cluster with RIs will always win at scale.

Use Serverless NextGen for spiky, unpredictable, or new workloads. Use provisioned + RIs for anything that runs a steady load 24/7.

Right-sizing shards, nodes, and EBS

Right-sizing has three sub-problems that AWS's docs treat separately: shards, nodes, and volumes. Get all three right or the savings compound in the wrong direction.

Shard sizing

Per the AWS right-sizing guide, target 10-30 GiB primary shards for search workloads, 30-50 GiB for log workloads, and never exceed 50 GiB. Shard count should be a multiple of data node count so distribution is even. Too many tiny shards exhaust JVM heap and coordination overhead crushes search latency; too few large shards under-utilize parallelism.

Node sizing signals

Watch these CloudWatch metrics on a 30-day window:

• JVMMemoryPressure > 80%: too many shards or too-heavy queries. Either shard less aggressively or move to memory-optimized (OM2).
• SearchLatency P95 > 200ms: possible shard skew or under-provisioning. Check _cat/allocation?v for hotspots first.
• IndexingLatency > 200ms: usually storage-bound on non-optimized instances, a strong signal to move to OR2/OI2.
• CPUUtilization < 30% sustained: over-provisioned, drop an instance size.

EBS right-sizing

gp3 defaults (3,000 IOPS, 125 MB/s) are enough for most OpenSearch workloads and beat gp2 on both price and baseline performance. The migration pattern is identical to the gp2-to-gp3 migration playbook we've used across EC2: convert in place with no downtime via ModifyVolume. Also stop over-provisioning capacity. Watermarks trigger at 75% (warning) and 85% (read-only), so target ~70% steady usage after ISM rollover, not 30%.

Hidden cost traps to hunt down first

Before you buy RIs or move families, sweep for these leaks. Every audit I've done in the last year has found at least two:

1. Orphaned Serverless collections from deleted Bedrock Knowledge Bases, deleted OpenSearch Ingestion pipelines, or abandoned prototypes. $350/month each on Classic.
2. Cross-AZ replica traffic on chatty producers. If your ingest client isn't AZ-aware, you're paying $0.01/GB in each direction for every doc write.
3. gp2 volumes provisioned for peak IOPS that never happen. Migrate to gp3 baseline and pay for the exact IOPS you need. Typically 30-40% cheaper for the same performance.
4. Debug indexes with no ISM policy that grow unbounded on hot storage. Attach the ism_template pattern to catch them at creation.
5. Over-replication. Two replicas on log data is usually overkill. Primary + one replica plus S3 snapshots gets you the same durability at 33% less EBS. OR2/OM2 sidestep this entirely.
6. Snapshots retained indefinitely. Automated snapshots to S3 are free within the domain retention window, but manual snapshots and cross-region copies incur S3 storage and transfer forever.
7. Dedicated master nodes larger than they need to be. Three m6g.large.search masters are enough for most clusters up to 40 data nodes. Anything larger is waste.

Frequently Asked Questions

What is the difference between OR1, OR2, OM2, and OI2 instances?

All four use S3-backed managed storage so replicas don't consume EBS. OR2 (March 2025) delivers ~26% higher indexing throughput than OR1 and ~70% more than R7g at similar cost; OM2 is the memory-optimized variant for search-heavy workloads; OI2 (December 2025) uses 3rd-gen Nitro SSDs for ~9% more throughput than OR2, best for extreme write workloads.

Is OpenSearch Serverless cheaper than a provisioned domain?

Only for spiky, low-utilization, or intermittent workloads, especially on NextGen collections that scale OCUs to zero after 10 minutes idle. For steady 24/7 workloads, provisioned domains with Reserved Instances are typically 6-16× cheaper because Serverless has no RI discount and Classic Serverless bills a 2-OCU minimum (~$350/month) even when idle.

How much do OpenSearch Reserved Instances save?

Between 31% (1-year No Upfront) and 50-52% (3-year All Upfront) versus on-demand pricing. Break-even on a 3-year All Upfront RI is around 18 months, so it's the right call for any data or master node you're confident will run for at least two years without a family change.

When should I use UltraWarm vs cold storage?

UltraWarm keeps data queryable with hot-like latency after cache warm-up. Use it for the 7-90 day range where you still run dashboards and searches. Cold storage is cheaper (~$24/TB-month) but requires attaching indexes to warm nodes before you can query, so reserve it for regulatory retention (90 days to 7+ years) where interactive query latency doesn't matter.

How do I reduce OpenSearch storage costs without losing data?

Deploy an ISM policy that rolls indexes on 30 GB primary shard size, transitions to UltraWarm after 7 days, cold after 30 days, and deletes after your retention window. Combined with a gp2→gp3 EBS migration and OR2 instances (which eliminate replica EBS entirely), most log domains cut storage cost 60-80% with zero data loss.