Amazon OpenSearch and Elasticsearch Cost Control

Search and log clusters have a way of becoming the most expensive part of an AWS bill that nobody decided to spend money on. A logging pipeline that started as a convenience ends up retaining months of data on hot nodes, a search domain provisioned for a launch keeps running at peak shape forever, and the cluster grows because adding capacity is easier than tuning it. Amazon OpenSearch and Elasticsearch cost control is the discipline of matching what you pay to what you actually query, and it routinely takes 30 to 50 percent off a neglected search bill.

This guide covers where OpenSearch Service cost comes from, the data tiers that change the economics, the OR1 storage-optimized instances, reserved instances, and the index lifecycle automation that keeps the cluster from bloating again. It is part of our complete guide to AWS cost optimization and complements our piece on Amazon Redshift cost optimization for data teams.

Where the cost comes from

Amazon OpenSearch Service bills on three things: instance hours for the data and dedicated master nodes, storage attached to those nodes, and data transfer. For most clusters the instance hours dominate, because hot data nodes must run continuously to serve queries and indexing. The trap is that teams size the cluster for the total volume of data they retain, when only a fraction of that data is ever queried. You end up paying for fast, expensive compute and storage to hold logs that nobody has searched in weeks.

The other quiet driver is over-provisioning for resilience: dedicated master nodes larger than they need to be, three Availability Zones where two would do for a non-critical workload, and replica counts set higher than the durability requirement. Each is defensible in isolation and expensive in aggregate. As always, confirm current per-region rates on the AWS OpenSearch Service pricing page before modeling savings, since rates vary by region and instance family.

Data tiers: hot, UltraWarm, and cold

The most powerful cost lever in OpenSearch is moving data off the hot tier as it ages. OpenSearch Service offers three storage tiers, and the price difference between them is large.

Tier	Use for	Relative cost
Hot	Active indexing and frequent, low-latency queries	Highest (instance + storage)
UltraWarm	Read-only data queried occasionally, backed by Amazon S3	Much lower per GB
Cold	Rarely accessed data kept for compliance, detached until needed	Lowest, S3-priced storage

The pattern that works for most log and observability workloads is hot for recent data that is actively written and searched, UltraWarm for older read-only indices that are occasionally queried, and cold for anything kept only to satisfy a retention policy. Because UltraWarm and cold use Amazon S3 for storage, the per-gigabyte cost drops sharply, and you stop paying for hot compute to babysit data nobody touches. Moving the bulk of retained data into these tiers is usually the largest single saving available.

OR1 storage-optimized instances

OR1 is a newer instance family for OpenSearch Service that uses Amazon S3 as primary storage with local instance storage acting as a cache. For indexing-heavy workloads that retain a lot of data, OR1 can deliver materially better price-performance than the traditional setup of data nodes with attached EBS, because you are no longer paying to keep every gigabyte on expensive block storage. If your domain runs heavy ingestion with large retention, evaluate OR1 against your current instance family; the storage economics often favor it. Validate query latency for your workload first, since the caching model behaves differently from EBS-backed nodes.

Rightsizing nodes and shards

Beyond tiering, the cluster itself is usually larger than it needs to be. Right-size the data nodes to actual CPU and memory utilization rather than peak headroom, and check whether dedicated master nodes are oversized for the cluster they coordinate. Shard strategy matters too: too many small shards waste heap and overhead, while too few oversized shards limit parallelism and force larger nodes. Aim for shard sizes in the tens of gigabytes and a shard count matched to your node count, and the same query load often runs on a smaller, cheaper cluster.

Reserved instances for steady-state

Once the cluster is right-sized and tiered, the remaining hot data nodes are a stable, always-on baseline, which is exactly what reserved instances are for. OpenSearch Service reserved instances offer a substantial discount over on-demand, commonly up to around 50 percent for a longer term and upfront payment, in exchange for a one-year or three-year commitment. The discipline is the same as with any commitment: rightsize first so you reserve the cluster you actually need, not the oversized one, then commit. Buying reservations on a bloated cluster locks in the waste, which is why this step comes after tiering and rightsizing, not before. Our guide to AWS Savings Plans versus Reserved Instances covers the commitment logic in depth.

Index lifecycle management

None of this holds without automation. Index State Management lets you define policies that automatically roll indices from hot to UltraWarm to cold and finally delete them at the end of their retention period, with no manual intervention. Set the policy once, aligned to your real retention requirement rather than an open-ended default, and the cluster stops accumulating data it will never query. This is the Lock step of our method applied to search: a guardrail that keeps the savings from drifting back as new indices are created.

The cost control checklist

1. Map retention against query patterns: how much data is actually searched, and how old.
2. Move read-only aging data to UltraWarm, and compliance-only data to cold.
3. Evaluate OR1 instances for indexing-heavy, high-retention domains.
4. Right-size data and master nodes to real utilization, and fix shard sizing.
5. Reduce replica counts and AZ spread where durability requirements allow.
6. Buy reserved instances on the steady-state hot cluster after rightsizing.
7. Automate tier transitions and deletion with Index State Management.
8. Re-check the bill the next cycle and confirm hot-tier spend dropped.

OpenSearch rewards the same approach as the rest of AWS: see what you are paying for, cut what you do not use, lock the savings with automation, and run it continuously. For the full picture, read the complete guide to AWS cost optimization and download the AWS Cost Optimization Field Guide.