Your OpenSearch Bill Is Bigger Than You Think: A Technical Cost Breakdown

OpenSearch can look cheap at first glance, then surprise you in the monthly bill.

Most teams look at one line item and assume that is “the OpenSearch cost.” In reality, OpenSearch spend is a composite of compute, storage, backups, and data movement, and each part scales differently under real workloads.

If you are trying to reduce spend without breaking search performance, you need to model the full stack, not just one rate card.

1) Start with the right mental model

There are two major OpenSearch consumption models:

• OpenSearch Service domains (provisioned clusters)
• OpenSearch Serverless collections

This post focuses on domain-based OpenSearch, where cost generally includes:

1. Data node instance-hours (often the biggest component)
2. Dedicated master node instance-hours (if enabled)
3. Warm/cold tier node-hours (if used)
4. EBS storage attached to nodes
5. EBS performance dimensions (for gp3: provisioned IOPS/throughput beyond baseline)
6. Snapshot storage
7. Data transfer and network-related charges

If your team uses OpenSearch Serverless, the billing dimensions are different (OCUs and storage), so avoid applying domain formulas to serverless workloads.

2) Why “simple price per GB” is misleading

A common mistake is saying:

• “OpenSearch data is $X/GB-month”
• “EBS is $Y/GB-month”
• “Snapshots are $Z/GB-month”

Those values can be valid in a specific region and setup, but not as universal truths.

For example:

• EBS pricing differs by volume type (gp2, gp3, io1, io2, st1, etc.)
• gp3 can add separate performance costs for extra IOPS/throughput
• snapshot charges depend on snapshot type/storage class and service context
• OpenSearch itself charges continuously for active domain infrastructure

The result: two domains with similar data size can have very different monthly costs depending on node family, node count, AZ architecture, and EBS configuration.

3) A practical monthly estimation formula

For domain-based OpenSearch, a useful engineering estimate is:

Monthly OpenSearch Cost ≈
(Σ node_hour_rate × node_count × 730)
+ (EBS_GB × EBS_GB_rate)
+ (gp3_extra_iops × iops_rate, if applicable)
+ (gp3_extra_throughput × throughput_rate, if applicable)
+ warm/cold tier costs
+ snapshot storage
+ data transfer

This will still be an estimate, but it is far closer to reality than a single “per-GB” assumption.

4) What to inspect first (high ROI checks)

When I audit OpenSearch cost, I check these first:

1. Idle domains
2. Domains with zero or near-zero search/index traffic for days or weeks.

3. Easy wins: delete, downscale, or consolidate.

4. Overprovisioned data nodes

5. Low CPU + low indexing/search rates + high instance count.

6. Rightsize node families and counts cautiously.

7. EBS mismatch

8. gp2 when gp3 would be cheaper for same durability target.

9. Oversized volumes with consistently low utilization.

10. Snapshot sprawl

11. Old manual snapshots with no retention policy.

12. Define lifecycle and retention rules.

13. Non-production environments running 24/7

14. Dev/test domains that do not need full-time uptime.

15. Schedule down periods where possible.

5) Fast validation commands

Use CLI/API checks before changing anything:

• Inventory domains:
  aws opensearch list-domain-names

• Domain config and capacity:
  aws opensearch describe-domain --domain-name <domain_name>

• Storage and utilization metrics (CloudWatch):
  check request/indexing activity, CPU utilization, memory pressure, free storage, and write/read throughput over at least 14 days.

Then correlate with CUR or billing exports before taking action.

6) A safer way to communicate pricing

Instead of writing:
“OpenSearch costs $0.25/GB, EBS costs $0.10/GB, snapshots cost $0.095/GB”

Say this:
“OpenSearch spend is a combination of node-hours, EBS storage/performance, and snapshot/storage retention. Exact rates vary by region, node family, storage class, and deployment choices.”

That phrasing is both technically correct and operationally useful.

Final takeaway

OpenSearch cost optimization is not about finding one wrong number. It is about identifying the dominant cost driver for your current architecture, then changing one lever at a time:

• eliminate idle
• rightsize nodes
• tune EBS
• enforce snapshot retention

If you do those four consistently, you will usually reduce spend without hurting query latency or reliability.

---

CloudWise automates AWS cost analysis across 42+ services. Try it at cloudcostwise.io