Purchase Redshift Reserved Nodes

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 data warehouse — Amazon Redshift, often a top-five line on an analytics-heavy cloud bill — is not covered by them at all. For a provisioned Redshift cluster the only discount instrument is the Reserved Node, and if no one is buying them, the warehouse is quietly running at full sticker price.

A Redshift Reserved Node is a one- or three-year commitment to a specific node type in a specific region in exchange for a rate cut of up to about 75% — one of the deepest commitment discounts AWS offers. 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. These commitments can't be reshaped after purchase and they have no size flexibility, so the buying decision is a genuine capital-commitment question that belongs on the finance agenda, not buried in an engineering ticket.

The number to watch is Redshift commitment coverage: of all the node-hours you ran this month, what percentage were covered by a Reserved Node versus paid at On-Demand. A steady-state 24x7 cluster that isn't going anywhere should sit 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 reserved nodes no running cluster is consuming. One important caveat — reserved nodes discount compute only, not the managed storage (RMS) that RA3 nodes bill separately, so coverage will never reach the whole Redshift line.

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

The conversation that follows is about run-model and cash, not configuration. Priya asks three things: is a provisioned cluster even the right way to run this, how stable is it really, and how much cash can we put upfront. The team confirms the workload is genuinely 24x7 — not the spiky, intermittent pattern that would point to Serverless — and that they've already moved onto RA3. 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 ~70%, about $18k a month, with the upfront portion paying back in well under a year.

Crucially, Priya doesn't push to cover 100%. She agrees to commit to ~85% of the stable cluster and leave the rest On-Demand, precisely because these commitments can't be unwound and have no size flexibility — if engineering resizes the cluster or shifts to Serverless next year, an over-bought reservation becomes stranded waste. She adds two standing numbers to the cost pack: Redshift coverage (target 80–95%) and Redshift reservation utilisation (must stay near 100%), notes that managed storage stays uncommitted, and puts the renewal date straight onto the finance calendar.

The headline impact is a missed discount on a large, predictable line item. A 24x7 Redshift cluster is among the most committable spend you have — and reserved nodes carry one of the deepest discounts AWS offers, up to ~75%. Leaving a stable cluster at On-Demand forgoes that discount entirely. On a six-figure-a-month warehouse bill, that's a seven-figure annual saving sitting uncollected, and unlike most cost-optimisation work it requires no engineering change at all — just a purchase decision against the node type you already run.

The reason it gets missed is structural: Savings Plans don't cover Redshift, so the warehouse never appears in the commitment-coverage number most finance teams watch. You need a separate coverage metric for Redshift — node-hours-covered divided by node-hours-run — and a separate utilisation metric — the percentage of reserved nodes 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 remember coverage applies to compute only — managed storage will always sit outside it.

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. A reservation bought before a node-type migration, a cluster resize, or a move to Serverless becomes stranded — billing against capacity no one runs. The protective rule is simple and finance can hold the line on it: confirm the cluster is the right run-model and is on its final node type, then commit to roughly 80–90% of the stable baseline only, never the peak, and never ahead of a known 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.

The data warehouse is usually one of the larger, steadier cloud costs in an analytics-driven business — it runs continuously and rarely changes shape week to week. That makes it an ideal candidate for a commitment discount of up to ~75%, among the deepest AWS offers. The catch is that the company-wide Savings Plan most teams rely on doesn't cover Redshift at all; it needs a separate, deliberate Reserved Node decision.

The one question worth asking: "What share of our Redshift spend is on a commitment, and is the cluster the right way to run this workload at all?" A stable, long-lived cluster running at On-Demand is money left on the table — but a spiky, intermittent analytics workload might belong on Redshift Serverless instead, where you pay per usage and don't commit anything. The discipline this category signals is whether the organisation decides cluster-versus-serverless and right-sizes before it locks in a multi-year commitment it can't undo.

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 data warehouse, a meaningful slice of the bill, sat outside that number entirely 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 Redshift spend immediately. The team did the right preparation first — confirmed a provisioned cluster was the right model rather than Serverless, finished the move onto RA3 — then committed to a multi-year reservation covering the stable cluster, banking roughly 70% on that slice of the bill.

The lasting outcome wasn't the one-time saving; it was the principle. Commitments follow stability, they follow the right run-model decision, and they follow right-sizing — never precede them. The review now tracks coverage across all commitment-eligible categories, and the data warehouse stopped being the quiet exception that everyone assumed was handled.

The data warehouse is usually among the larger and most predictable cloud costs in an analytics business, which makes it a prime candidate for a multi-year discount of up to ~75% — among the deepest AWS offers. The reason this lands on the report is that the company-wide commitment instrument everyone relies on — the Savings Plan — explicitly doesn't cover Redshift. So an organisation can look fully committed on its main dashboard while a large, steady slice of the bill quietly runs at full price. The size of the uncovered Redshift 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 confirm the run-model and right-size first, then commit to the stable cluster. An organisation that commits carefully after that cleanup is banking durable savings; one that over-commits ahead of a node-type migration or a shift to Serverless is locking in waste it can't escape for years. Either way, whether Redshift is covered at all is the tell for whether the commitment strategy actually reaches past the easy wins.