Explanation
Why the waste happens and who it affects.
OpenSearch domains running on older Intel-based families consume more spend without providing additional capability. Graviton-based instance types support the same OpenSearch features, provided the domain runs Elasticsearch 7.9 or later or any OpenSearch version, so for eligible domains continuing to run on older Intel-based clusters represents unnecessary inefficiency.
Billing model
The pricing dimensions that drive this cost.
OpenSearch is billed based on the underlying EC2 instance hours consumed by the cluster, plus storage and data transfer. Choosing less efficient previous-generation Intel-based instance types (e.g., m5, r5, i3) results in higher cost per unit of performance compared to current-generation Graviton-based instances (for example m7g/m8g, c7g/c8g, r7g/r8g, i8g). Current-generation Intel types such as i4i are still worth comparing against their Graviton equivalents on price.
How to detect
4 checks to find it in your estate.
- Review all active OpenSearch domains and identify clusters running on Intel-based instance types that have equivalent Graviton alternatives
- Assess whether workload performance requirements (CPU, memory, IOPS) could be met by moving to Graviton families
- Confirm OpenSearch version compatibility to ensure upgrade paths to supported Graviton instance types
- Evaluate whether production and non-production domains are consistently aligned with optimal instance families
How to fix
3 ways to remove the waste.
- Migrate OpenSearch domains from previous-generation Intel-based instances (e.g., m5, r5, i3) to equivalent current-generation Graviton families (for example m7g/m8g, c7g/c8g, r7g/r8g, i8g), moving dedicated master nodes as well, since several Graviton families cannot be combined with non-Graviton instances in the same cluster; note that the EBS-backed Graviton3 and Graviton4 types (c7g/m7g/r7g, c8g/m8g/r8g) support only gp3 volumes
- Change the instance type through the domain configuration, which runs a blue/green deployment; use a dry run to preview it, schedule it during low traffic, and expect both clusters to be billed for the first hour
- Benchmark performance after migration to validate expected cost-performance improvements
Documentation
Vendor references for pricing and configuration.