Purchase OpenSearch Reserved Instances

Most cloud commitment programs are built around one big mechanism: the Savings Plan. You commit to a dollar-per-hour of spend and AWS discounts your compute. The catch finance partners often miss is that Savings Plans stop at the edge of EC2, Fargate, and Lambda. Your managed search and log-analytics cluster — Amazon OpenSearch Service, often a surprisingly large line on the bill once log retention grows — is not covered by them at all. For OpenSearch the only discount instrument is the Reserved Instance, and if no one is buying them, the whole tier is quietly running at full sticker price.

An OpenSearch Reserved Instance is a one- or three-year commitment to a specific data-node instance type in a specific region, in exchange for a rate cut of up to about 50%. There are three ways to pay — nothing upfront, part upfront, or all upfront — and more upfront means a deeper discount but a larger cash outlay today. Unlike the EC2 world, these commitments can't be reshaped after purchase: there's no "convertible" option for OpenSearch and no size flexibility at all. That makes the buying decision a genuine capital-commitment question, not a reversible toggle, and it belongs on the finance agenda rather than buried in an engineering ticket.

The number to watch is OpenSearch commitment coverage: of all the data-node hours you ran this month, what percentage were covered by a Reserved Instance versus paid at On-Demand rates. Healthy steady-state domains — the ones that run 24x7 ingesting logs and serving search and aren't going anywhere — should be sitting at 80–95% covered. Anything well below that on a stable cluster is unrealised savings. Anything near 100% with low utilisation of those reservations is the opposite problem: you've over-committed and are paying for reservations no node is consuming. One caveat worth holding: the RI covers data-node hours only — it does nothing for the EBS and UltraWarm storage attached to the domain, which is billed separately and keeps growing with retention.

Priya is the finance partner embedded with the platform team. At the monthly cost review she notices something the Savings Plan dashboard had been hiding: the company's $22k of monthly OpenSearch spend is almost entirely uncommitted, because the Savings Plan they're proud of doesn't touch search clusters. Her question is simple: "This domain has run the same shape for a year — why are we paying On-Demand for all of it?"

The conversation that follows is about cash and confidence, not configuration. Priya asks three things: how stable is this cluster really, how much cash can we put upfront, and what's the payback period. The team confirms the hot tier is steady-state after the recent right-sizing and tiering work. Finance decides a three-year Partial Upfront commitment fits the cash position — deeper discount than No Upfront, without tying up the whole budget. The projected saving is ~48%, about $1,900 a month on the data nodes, with the upfront portion paying back in well under six months.

Crucially, Priya doesn't push to cover 100%, and she's careful to separate two numbers. She agrees with the team to commit to the stable hot-node baseline only, leaving headroom On-Demand precisely because these commitments can't be unwound — if engineering right-sizes again or moves families next year, an over-bought reservation becomes stranded waste. She also notes that the reservation covers data-node hours only: the EBS and UltraWarm storage, which is growing as retention climbs, will keep billing separately and needs its own line. She adds two standing numbers to the cost pack — OpenSearch coverage (target 80–95%) and reservation utilisation (must stay near 100%) — and the renewal date goes straight onto the finance calendar.

The headline impact is a missed discount on a stable, growing line item. A busy OpenSearch domain ingesting logs runs 24x7 and rarely changes shape week to week — among the most committable spend you have. Leaving a stable cluster at On-Demand forgoes a discount of up to ~50% on the data-node portion. On a six-figure-a-year OpenSearch bill, that's a meaningful annual saving sitting uncollected, and unlike most cost-optimisation work it requires no engineering change at all — just a purchase decision against a shape you've already settled.

The reason it gets missed is structural: Savings Plans don't cover OpenSearch, so the search tier never appears in the commitment-coverage number most finance teams watch. You need a separate coverage metric for OpenSearch — node-hours-covered divided by node-hours-run — and a separate utilisation metric — the percentage of reserved capacity actually consumed. Coverage tells you how much discount you're capturing; utilisation tells you whether you've over-bought. Both belong on the monthly pack as their own lines, not folded into the compute number. And a third line matters here that doesn't for RDS: storage. The RI covers node hours only, so EBS and UltraWarm storage is a separate, retention-driven cost you can't reserve away — track it independently so a rising total bill isn't misread as a coverage failure.

The three payment options are a genuine cash-versus-discount tradeoff, and that decision is finance's to make. No Upfront ties up no capital but gives the shallowest discount; All Upfront gives the deepest discount but is a real cash outlay today; Partial Upfront sits between. The right choice depends on the cost of capital and cash position, not on engineering preference — which is exactly why this should be a finance-led conversation with an explicit payback calculation, not a default buried in a console wizard.

The risk to guard against is over-commitment, because these reservations cannot be undone and have no size flexibility to absorb a change. A reservation bought before a right-size, a Graviton move, a tiering exercise that shrinks the hot fleet, or a shift to Serverless becomes stranded — billing against capacity no one runs. The protective rule is simple and finance can hold the line on it: commit to the stable hot-tier baseline only, never the peak, and never ahead of a known architecture change. Coverage in the high-80s with utilisation near 100% is the target; 100% coverage with sagging utilisation means money is being wasted on reservations, which is worse than the original problem.

Search and log-analytics clusters are usually a steadily growing cloud cost — they run continuously and rarely change shape week to week as log volume climbs. That makes them a strong candidate for a commitment discount of up to ~50%. The catch is that the company-wide Savings Plan most teams rely on doesn't cover OpenSearch at all; they need a separate, deliberate Reserved Instance decision.

The one question worth asking: "What share of our OpenSearch spend is on a commitment, and is that the right share given how stable the cluster is?" A stable, long-lived domain running at On-Demand rates is money left on the table. The discipline this category signals is whether the organisation is right-sizing the domain and tiering its data — hot, warm, and cold — before it commits, because these commitments can't be undone, and an undisciplined buy locks in waste for years.

At one company, the cloud-cost review opened for months with a proud slide about Savings Plan coverage — 92% of compute committed. What the slide didn't say was that the search and logging cluster, a growing slice of the bill, sat outside that number at full On-Demand price. No one had asked the question because "we have a Savings Plan" sounded like the job was done.

The exec sponsor changed the framing with one question: "What share of every major cost category is on a commitment, not just compute?" That surfaced the uncovered OpenSearch spend immediately. The team did the right preparation — right-sized the hot tier, moved old indices to UltraWarm and cold storage, and confirmed the workload wasn't spiky enough for Serverless — then committed to a multi-year reservation covering the stable baseline, banking roughly 48% on the data nodes.

The lasting outcome wasn't the one-time saving; it was the principle. Commitments follow stability, and they follow after right-sizing and data tiering, never before. The review now tracks coverage across all commitment-eligible categories, and the search cluster stopped being the quiet exception that everyone assumed was handled.

Search and log-analytics clusters are usually a steadily growing and predictable cloud cost, which makes them a strong candidate for a multi-year discount of up to ~50%. The reason this lands on the report is that the company-wide commitment instrument everyone relies on — the Savings Plan — explicitly doesn't cover OpenSearch. So an organisation can look fully committed on its main dashboard while a meaningful slice of the bill quietly runs at full price. The size of the uncovered OpenSearch spend is a direct measure of money being left on the table.

The trend and the discipline behind it matter more than any single purchase. Because these commitments are multi-year, irreversible, and have no size flexibility, the right pattern is to right-size, tier the data, and confirm the workload shape first, then commit to the stable baseline. An organisation that commits carefully after cleanup is banking durable savings; one that over-commits ahead of architecture changes is locking in waste it can't escape for years. Either way, whether OpenSearch is covered at all is the tell for whether the commitment strategy actually reaches past the easy wins.