Amazon OpenSearch Service (the managed Elasticsearch/OpenSearch offering) has a specific cost profile that's easy to over-provision into and hard to right-size without a genuine understanding of shard allocation and query patterns. Unlike a typical compute workload where CPU utilization gives you a fairly direct sizing signal, OpenSearch cost drivers are shaped by index design decisions made months earlier — and those decisions compound as data grows.
The Most Common Overspend Pattern: Too Many Small Shards
OpenSearch performance guidance generally recommends keeping shard sizes in a moderate range rather than fragmenting indices into many small shards, because each shard carries fixed overhead (cluster state, memory for segment metadata) regardless of how much data it holds. Domains provisioned with default or legacy index templates frequently end up with far more shards than their data volume justifies, which means data nodes are sized to handle shard-count overhead rather than actual data volume — the fix is typically a reindex into fewer, larger shards, not adding more nodes.
// Index template forcing sensible shard count for typical time-series log volume
PUT _index_template/logs-optimized
{
"index_patterns": ["logs-*"],
"template": {
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
}
Data Node Instance Type and Storage Tier Selection
OpenSearch supports UltraWarm and cold storage tiers for less frequently accessed data, at a meaningfully lower cost than hot-tier data nodes. Teams running everything on hot storage indefinitely — including logs or historical data queried rarely — are paying hot-tier storage and compute costs for data that could live in UltraWarm (queryable, cheaper) or cold storage (retrievable but not directly queryable) with minimal impact on actual usage patterns.
Right-Sizing Based on Actual Query Load, Not Peak Provisioning
A common anti-pattern is provisioning data node instance sizes based on a worst-case ingestion or query spike that occurs rarely, then running that sizing continuously. OpenSearch supports Auto-Tune and, depending on your version, more granular scaling options — the audit question worth asking is whether your current instance sizing reflects sustained average load or a peak that happens a few times a month.
Dedicated Master Nodes: Right-Sized, Not Oversized
Dedicated master nodes handle cluster state management, not data or query load, so they don't need to scale with data volume the way data nodes do. Domains sometimes carry oversized master node instance types left over from an earlier, larger cluster configuration — a straightforward audit check is confirming master node sizing matches current cluster size guidance rather than a legacy sizing decision.
Reserved Instances for Stable Baseline Load
For OpenSearch domains with a stable, predictable baseline (as opposed to highly variable workloads), Reserved Instances for data nodes can meaningfully reduce cost relative to on-demand pricing, similar to the RI/Savings Plans calculus for EC2 — this is often overlooked specifically for OpenSearch domains compared to how routinely it's applied to general EC2 fleets.
The Audit Checklist
- Shard count and size relative to actual index data volume — reindex oversharded indices.
- Storage tier allocation — move infrequently queried data to UltraWarm or cold storage.
- Data node instance sizing against sustained (not peak) load.
- Dedicated master node sizing against current cluster size, not historical peak.
- Reserved Instance coverage for stable baseline data node capacity.
This audit approach is part of our AWS cloud infrastructure capability, alongside the broader cost work covered in reducing your AWS bill through cost optimization.
Ask us for a scorecard on your OpenSearch domain: 907-841-8407 or contact@rutagon.com.
Talk to us about your AWS cost audit →
Frequently Asked Questions
How many shards should a typical OpenSearch index have?
It depends on data volume and query patterns, but a common guideline targets shard sizes in a moderate range (tens of GB) rather than many small shards — the actual right number depends on your specific ingestion rate and retention policy.
What's the cost difference between hot, UltraWarm, and cold storage tiers?
UltraWarm and cold storage are significantly cheaper per GB than hot-tier storage, trading some query latency (UltraWarm) or direct queryability (cold) for cost — the right split depends on how often older data actually gets queried.
Can we resize an OpenSearch domain without downtime?
Yes, in most cases — OpenSearch Service supports rolling instance type and count changes with minimal disruption, though large reindexing operations for shard restructuring require their own migration plan.
Does UltraWarm require any application-level changes to use?
Minimal — UltraWarm-tier indices remain queryable through the same API, though with different latency characteristics; the main work is configuring index lifecycle policies to transition data automatically.
How do Reserved Instances work for OpenSearch data nodes specifically?
Similar to EC2 RIs — you commit to a specific instance type and term in exchange for a lower effective hourly rate, which pays off for stable, predictable baseline capacity but not for highly elastic workloads.