Explanation
Why the waste happens and who it affects.
These choices are usually made from a peak ingest estimate or a worst-case retention assumption, and they are rarely revisited once the domain is stable. When actual load is lower, the domain runs with low CPU, low JVM heap use and mostly empty volumes, while every node-hour and every provisioned GB is still billed.
AWS cost optimization guidance for OpenSearch Service treats sustained CPU below 40%, JVM memory pressure below 50% and storage use below 50% as signs of waste, and names over-sized dedicated master nodes and over-sharding as further drivers. Over-sharding matters because many small shards consume heap and CPU, which pushes teams to add nodes that the data volume alone would not require.
Billing model
The pricing dimensions that drive this cost.
Managed domains are billed for provisioned capacity, independent of query or indexing volume.
- Instance-hours
- Billed for each hour a data, dedicated master, coordinator or UltraWarm node is running in an available state, with partial hours billed as full hours
- EBS storage
- Billed per GB-month of volume provisioned on each data node, plus provisioned IOPS and throughput for gp3 where configured
- Blue/green changes
- When the instance type changes, both clusters are billed for the first hour of the migration and only the new cluster after that
How to detect
5 checks to find it in your estate.
- Review the domain's CloudWatch metrics over several weeks: CPUUtilization (Average and Maximum), JVMMemoryPressure, and FreeStorageSpace or ClusterUsedSpace against provisioned storage; AWS names sustained CPU below 40%, JVM below 50% and storage below 50% as signs of over-provisioning, with 60-80% CPU, 65-85% JVM and 70-85% storage as optimal ranges for sustained workloads
- Check dedicated master nodes: AWS states they are only needed for domains with 3 or more data nodes, and MasterCPUUtilization and MasterJVMMemoryPressure far below the recommended scaling points (60% and 85%) indicate an oversized master instance type
- Compare Shards.active with data node count and heap; AWS recommends 10-50 GiB per shard, no more than 25 shards per GiB of Java heap and no more than 1,000 shards per data node, and domains with many small shards are often carrying extra nodes
- Review SearchRate and IndexingRate trends to confirm the low utilization reflects steady demand rather than a quiet period
- Use cost allocation tags and Cost Explorer to rank domains by spend so right-sizing starts with the largest ones
How to fix
6 ways to remove the waste.
- Reduce the data node count, which usually does not require a blue/green deployment, or move to a smaller instance type, which does; run a dry run first to see the deployment type and validation results, and schedule the change for low traffic
- Remove dedicated master nodes on domains with fewer than 3 data nodes, or move them to a smaller instance type where master metrics show large headroom
- Consolidate shards toward 10-50 GiB each using ISM rollover and reindexing, and reduce replica count where durability requirements allow, so fewer nodes are needed for the same data
- Decrease the EBS volume size where storage use is persistently low; this triggers a blue/green deployment and fails validation if the new size cannot hold the domain's data
- Move gp2 volumes to gp3 and use the latest instance generation (for example Graviton or OpenSearch-optimized OR2/OM2 for indexing-heavy workloads) as part of the same change window
- Set CloudWatch alarms on low as well as high utilization so domains that drift into over-provisioning are flagged for review
Documentation
Vendor references for pricing and configuration.