OpenSearch cost optimization: shrink the always-on cluster

Quick answer

OpenSearch bills data-node instance hours + EBS storage + optional master nodes, all running 24/7 — so a 3-node r6g.large.search cluster with 500 GB EBS is $700+/month before heavy use. Cut it with Graviton nodes (~20% off), UltraWarm and cold storage for old indices, gp3 instead of gp2, index lifecycle management, and Reserved Instances on the steady data nodes.

OpenSearch (formerly Elasticsearch Service) is one of the easiest AWS services to overspend on, because the cost is almost entirely fixed capacity that runs whether you query it or not. Optimizing it is about shrinking the always-on footprint, not tuning per-query costs.

What you're paying for

Data nodes: instance-hours per node, continuous. The bulk of the bill. Sized by your indexing throughput and hot-data retention.
EBS storage: per-GB-month attached to each data node.
Dedicated master nodes: optional but recommended for production — three small nodes running 24/7 for cluster stability.
UltraWarm / cold: cheaper tiers for older indices, if enabled.

1. Tier old data to UltraWarm and cold

The biggest lever for log and observability clusters: hot EBS storage is expensive, and most queries only touch recent data. Use index state management to move indices to UltraWarm (S3-backed, far cheaper per GB) after a few days and to cold storage after a few weeks. A cluster retaining 90 days hot can often keep 3-7 days hot and tier the rest, cutting storage cost by more than half.

2. Switch data nodes to Graviton

The r6g/m6g/c6g (Graviton) search instances are ~20% cheaper than the x86 equivalents for the same capacity — a near-free win on the largest line item. See Graviton migration savings for the details; on OpenSearch it's just an instance-type change.

3. Use gp3 EBS, not gp2

gp3 is cheaper per GB than gp2 and lets you provision IOPS and throughput independently, so you stop paying for capacity to get performance. The same migration that helps EBS volumes generally applies here — see the gp2 to gp3 migration guide.

4. Right-size, then reserve the baseline

Many clusters are provisioned for an indexing peak that rarely arrives. Match node count and type to sustained load with headroom, not worst case. Once the steady footprint is known, Reserved Instances on the data nodes are 30-50% off — the same commitment logic as RIs vs Savings Plans.

5. Delete indices you don't query

Retention creep is real: clusters accumulate indices nobody searches but everybody pays to keep hot. Index state management can delete indices past a retention age automatically. If you need them for compliance, tier to cold rather than keeping them hot.

FAQ

Why is Amazon OpenSearch so expensive?

Because data nodes run 24/7 and most clusters are sized for peak indexing and retention. The bill is data-node instance hours + EBS storage + optional dedicated master nodes, all continuous. A modest 3-node cluster on r6g.large.search with 500 GB of EBS is well over $700/month before you index anything heavier.

How is OpenSearch Service priced?

Per instance-hour for each data node and each dedicated master node, plus per-GB-month for attached EBS storage, plus UltraWarm and cold storage if enabled. OpenSearch Serverless prices differently, in OpenSearch Compute Units (OCUs) for indexing and search.

What is UltraWarm and does it save money?

UltraWarm is a lower-cost storage tier for older, infrequently-searched indices, backed by S3 with local caching. It's dramatically cheaper per GB than hot EBS storage, so moving logs older than a few days to UltraWarm (and older still to cold storage) can cut a log-analytics cluster's bill substantially.

How do I reduce OpenSearch costs?

Right-size data nodes to actual load, use Graviton (r6g/m6g) nodes for ~20% off, move old indices to UltraWarm and cold storage with index state management, use gp3 EBS instead of gp2, buy Reserved Instances for the steady data nodes, and delete indices you no longer query instead of retaining everything hot.

Should I use OpenSearch Serverless instead?

Serverless removes node management and bills per OCU, which can be cheaper for spiky or low-volume workloads and more expensive for steady high-throughput ones. It's worth comparing for new clusters, but established high-utilization clusters are often cheaper on provisioned data nodes with Reserved Instances.

How does C3X estimate OpenSearch cost?

C3X prices an aws_opensearch_domain from its data-node instance type and count, dedicated master nodes, and EBS volume, so the always-on cluster cost is visible before deployment — the part of the bill that's fixed regardless of query volume.

What to do next

The fixed cluster cost is the part to attack first because it bills regardless of usage. C3X prices an aws_opensearch_domain from its data-node type and count, master nodes, and EBS volume, so the always-on footprint is visible before you deploy — and so a node-type or gp3 change shows its saving immediately. The quickstart gets you the number in minutes.