Cut OpenSearch costs 32%: 8 AWS levers with Serverless, OR2, gp3

Right-size compute and buy reservations for steady nodes, tier and roll up historical data, and tune ingestion and shard sizing. Those three moves typically drive the largest share of OpenSearch cost optimization gains on AWS. Layer in Serverless NextGen for spiky workloads and gp3 storage everywhere, and most fleets can cut their bill meaningfully within a quarter. Cost Beacon audits routinely find the same gaps.

TL;DR:

• Reserving instances for steady nodes and migrating to newer instance families can save up to 52% over three years, especially if workload stability is confirmed through benchmarking.
• Tiering data with UltraWarm and cold storage, combined with rollups, can reduce storage costs by up to 90 percent and lower query latency for infrequently accessed data.
• Proper shard sizing, bulk ingestion tuning, and switching codecs like zstd can significantly cut CPU and storage expenses without impacting performance.
• Implementing governance measures such as tagging, alarms, and lifecycle automation prevents cost drift and ensures sustained savings over time.
• Conducting an AI-backed audit with a service like Cost Beacon typically yields around 32% in cloud bill reductions by identifying orphaned indices, oversized instances, and wasted resources.

Table of Contents

• Quick actionable checklist: the 8 cost levers
• Compute and pricing levers: reservations, instance families, and serverless trade-offs
• Storage tiering and data lifecycle: UltraWarm, cold storage, rollups and gp3
• Indexing and performance tuning that reduces resource consumption
• Operational controls and governance to stop cost drift
• Real-world impact and a sample savings playbook
• Author perspective: when to tune vs when to hire an audit
• Cost Beacon: a pay-on-savings review for your OpenSearch bill
• Sources

Quick actionable checklist: the 8 cost levers

Before diving into the mechanics, here’s the shortlist worth running through your own domains this week. Each item maps to a deeper section below, so treat this as a working checklist rather than the full explanation.

• Evaluate Reserved Instances or Database Savings Plans for any node that has run steady for 30+ days.
• Pick OR2, OM2, or OI2 instance families (or Graviton) and right-size based on real CloudWatch metrics, not guesswork.
• Tier aging data to UltraWarm and cold storage, using ISM and rollups to shrink it first.
• Migrate gp2 volumes to gp3 and decouple provisioned IOPS from raw volume size.
• Tune indexing settings including bulk request size, refresh interval, and translog behavior.
• Cap OCUs on serverless collections and shift bursty or intermittent workloads to Serverless NextGen.
• Apply sampling and compression (zstd codecs) at ingestion to cut both storage and CPU load.
• Enforce cost allocation tags, budgets, and alerts so drift gets caught before it compounds.

Compute and pricing levers: reservations, instance families, and serverless trade-offs

Reserved Instances remain the single biggest lever for predictable workloads. A one-year No Upfront RI saves roughly 31% versus on-demand pricing, a one-year All Upfront commitment pushes that to about 42%, and a three-year All Upfront term lands around 50% to 52%. For a domain running steady state for months already, that discount usually pays for itself well before the term ends. Database Savings Plans work differently: instead of locking a specific instance family, they apply a discount across usage that matches your commitment, giving you more flexibility if you expect to shift instance types during the term.

That flexibility matters because RIs are family-specific. Committing to a family without load testing first risks locking you into hardware that becomes the wrong fit six months later. Run a proper benchmark against your actual query and ingest patterns before signing a three-year term.

The newer OR2, OM2, and OI2 instance families deserve a look regardless of your commitment strategy. They use S3-backed replica storage, which cuts EBS costs on the replica side while improving throughput and general price-performance over the older R6g/M6g/I3 generations. If you’re still running previous-generation instances, migrating is often a quiet, low-drama win.

Right-sizing itself comes down to watching the metrics that actually matter: CPUUtilization, JVMMemoryPressure, and FreeStorageSpace. Changing instance types triggers a blue/green deployment, so plan the swap during a low-traffic window and confirm shard allocation completes cleanly afterward.

Serverless NextGen changes the math for workloads that aren’t steady. Collections can scale compute to zero after about 10 minutes of inactivity, which makes it a strong fit for dev/test environments, intermittent internal search, and RAG knowledge bases that get hit in bursts. Steady, 24/7 production traffic almost always stays cheaper on provisioned nodes with RIs attached. Mixing both models by workload type, rather than picking one architecture for everything, is where the real savings show up.

Storage tiering and data lifecycle: UltraWarm, cold storage, rollups and gp3

Storage is where most OpenSearch bills quietly balloon, and it’s also where the cheapest wins live. UltraWarm, backed by S3, can cut storage cost by up to roughly 90% compared with keeping everything on hot EBS-backed nodes. Cold storage goes even lower, but it requires attaching indexes back to a warm node before they’re queryable, so it only makes sense for data you access rarely, if at all.

The decision rule is straightforward: move data to UltraWarm once it stops needing sub-second query latency, typically somewhere between 7 and 30 days old depending on your retention needs, and push it to cold storage once it’s mostly there for compliance or occasional lookup.

Index State Management automates that transition. A typical ISM policy might look like this:

• Rollover at 50 GiB or 24 hours, whichever comes first.
• Transition to UltraWarm at 14 days old.
• Transition to cold storage at 90 days old.
• Delete at 365 days, or per your retention policy.

Rollups add a second layer of savings on top of tiering. Instead of moving raw, granular time-series data into UltraWarm, a rollup job summarizes it first, which reduces the volume before it ever gets tiered. Combining rollups with ISM consistently outperforms tiering alone, since you’re shrinking the data rather than just relocating it.

On the block storage side, migrating from gp2 to gp3 decouples IOPS and throughput from raw volume size. With gp2, you had to over-provision volume just to get enough IOPS. gp3 lets you provision IOPS and throughput independently, so you stop paying for capacity you don’t need. It’s usually a same-day change with no query-side impact, which makes it one of the fastest wins on this list.

One guardrail: before moving data off hot storage, confirm which dashboards and saved queries depend on it. Queries on cold-tier data can unexpectedly cause support issues, so plan accordingly.

Indexing and performance tuning that reduces resource consumption

Shard sizing is the most underrated lever in this entire list. AWS recommends targeting 10 to 50 GiB per primary shard, and it’s not a soft suggestion. Too many small shards force nodes to spend CPU cycles on coordination overhead instead of actual query work, and that overhead scales badly once you’re running hundreds of shards per node. If your log indexes are creating a new shard every day regardless of volume, you’re probably paying for coordination you don’t need.

Bulk ingestion settings compound that effect. Start bulk requests around 5 to 15 MiB, then measure actual throughput and adjust from there rather than assuming bigger is always better. Oversized bulk requests can spike JVM memory pressure and trigger rejected requests, which forces retries and wastes compute on work that has to run twice.

For heavy ingest periods, three settings matter most:

• translog.flush_threshold_size: raising this reduces flush frequency during bursts, trading a bit of recovery time for lower I/O.
• refresh_interval: extending this from the default 1 second to something like 30 seconds during bulk loads cuts segment merge overhead significantly.
• Index buffer size: increasing this for heavy write workloads reduces the frequency of small segment flushes.

Compression codec choice adds a meaningful, low-effort layer on top. OpenSearch 2.9 and later support zstd and zstd_no_dict, and testing shows zstd delivers roughly 7% better write throughput with about 30% storage improvement, while zstd_no_dict pushes throughput gains closer to 14% with similar storage savings. Switching codecs is a mapping-level change, not an architecture overhaul, and it pays off on both the storage line and the CPU line of your bill.

During heavy ingest windows, consider dropping replica count to zero temporarily, then restoring it once ingestion settles. Fewer replicas during a bulk load means less duplicate indexing work, though you’re trading some read availability during that window, so this only makes sense for non-critical ingestion periods.

Operational controls and governance to stop cost drift

Tuning fixes today’s bill. Governance keeps it from creeping back up next quarter, and most teams skip this step entirely.

• Tag every domain with team, environment, and cost center, then map spend to owners in Cost Explorer so nobody’s surprised at review time.
• Set CloudWatch alarms on JVMMemoryPressure above 80%, CPUUtilization sitting persistently low, and FreeStorageSpace approaching thresholds, catching both waste and risk in the same pass.
• Cap OCUs on serverless collections explicitly, since unbounded autoscaling on a spiky workload can quietly outspend a provisioned domain.
• Use Cost Explorer budgets to flag which workloads have stayed steady long enough to justify an RI purchase, rather than committing on a hunch.
• Automate lifecycle transitions through ISM policies and snapshot schedules so retention doesn’t depend on someone remembering to run a manual cleanup.

None of these controls require a big engineering lift. They require discipline, and a monthly fifteen-minute review against the tags and alarms above usually catches drift before it becomes a line item worth escalating.

Real-world impact and a sample savings playbook

Cost Beacon audits find the fastest wins come in a consistent order. Quick wins like gp3 migration and tag clean-up typically take hours and can be validated the same day. Mid-term moves, tiering to UltraWarm and applying rollups, run days to a couple of weeks once ISM policies are tested against real query patterns. Higher-effort work, RI purchases across a fleet or moving to OR2/OM2 families, deserves a proper pilot before full rollout.

Across various fintech, telecom, and SaaS environments, average cloud bill reductions land around a third, a figure that holds up across cloud platforms, not just OpenSearch specifically. The pattern that shows up again and again: orphaned indices nobody remembers creating, oversized replica counts left over from a load test, and instance families chosen two years ago that no longer match current traffic.

Author perspective: when to tune vs when to hire an audit

Internal tuning handles the obvious waste: gp3 migration, refresh interval tweaks, shard cleanup. What internal teams consistently miss are orphaned indices from decommissioned services, forgotten serverless collections still billing OCU-hours, and replica strategies copied from a load test six months ago and never revisited. Once your fleet spans more than a handful of domains, that blind spot compounds faster than any single engineer can track alone. That threshold, more than any dollar figure, is when a structured audit earns its cost.

— Aaditya Parashar

Cost Beacon: a pay-on-savings review for your OpenSearch bill

Cost Beacon is the direct path from “we should probably fix this” to an actual prioritized action plan for your OpenSearch domains. The audit combines AI-driven analytics with hands-on engineering review to flag oversized instances, orphaned indices, forgotten serverless collections, and every other leak this playbook covers, then hands you a ranked list showing expected savings per item.

You pay nothing upfront. Cost Beacon’s model bills only against savings you actually realize, so there’s no retainer and no risk if the findings turn out smaller than expected. Across the fintech, telecom, and SaaS clients it has reviewed, Cost Beacon has delivered average bill reductions of 32%, with the added benefit of tightening security posture along the way. If your OpenSearch fleet has grown past the point where a spreadsheet review catches everything, book a review and see what a prioritized plan looks like for your own domains.

Sources

• Cost optimization techniques for Amazon OpenSearch Service - Amazon OpenSearch Service Developer Guide
• Tuning your cluster for performance — OpenSearch documentation