Cost

Purchase EC2 Reserved Instances

For pure discount, a Savings Plan has quietly superseded the EC2 Reserved Instance — so the honest reason to still buy an RI is the one thing a Savings Plan can't give you: a guaranteed capacity reservation in a specific AZ.

15 min·10 sections·AWS

Last reviewed 27 May 2026

EC2 Reserved Instances: the basics

Why the right answer is usually a Savings Plan — and when it isn't

An EC2 Reserved Instance (RI) is a billing commitment, not a server you launch. You promise AWS you'll run a particular instance shape for one or three years, paid No Upfront, Partial Upfront, or All Upfront, and in exchange you get up to roughly 72% off the On-Demand rate. RIs come in two flavours: Standard RIs (deepest discount, locked to a family) and Convertible RIs (a shallower discount, but exchangeable for a different family, OS, or tenancy later). For years this was the primary way to cut a steady EC2 bill.

Here's the uncomfortable truth you should hear up front: for most pure-discount use cases, the Compute Savings Plan has superseded the Reserved Instance. A Savings Plan gives you the same discount depth as a Standard RI but with none of the rigidity — it automatically flexes across instance family, size, region, OS, tenancy, and even between EC2, Fargate, and Lambda, just by committing a dollars-per-hour figure. There is almost no pure-savings scenario where a Standard RI beats a Savings Plan, and Convertible RIs are strictly worse than a Savings Plan on every axis. If your goal is only to lower the rate, buy a Savings Plan and stop reading.

So why does the RI still exist, and why is this lesson worth your time? Because of one thing a Savings Plan does not provide: a capacity reservation. A Zonal RI reserves actual capacity in a specific Availability Zone — AWS guarantees the hardware will be there when you call RunInstances, which matters for failover, scaling events, and scarce instance types. A Regional RI (the default) gives the billing discount and size flexibility across AZs in a region but reserves no capacity at all. The honest engineering guidance is therefore: prefer a Savings Plan for the discount, and reach for a Zonal RI (or a standalone On-Demand Capacity Reservation) only when you specifically need guaranteed capacity in an AZ.

In this lesson you'll learn why the Savings Plan has superseded the EC2 Reserved Instance for pure discount, and the narrow case where the RI is still the right tool: guaranteed capacity. You'll learn the Standard-versus-Convertible distinction, the all-important Regional-versus-Zonal split (size flexibility and no capacity vs. AZ-locked capacity assurance), the three payment options, and how RIs and Savings Plans interact on the same bill. You'll see the AWS CLI calls that produce a purchase recommendation and that list what you already own, and the edge cases that strand a reservation — right-sizing, Graviton migrations, and the classic mistake of buying an RI for a discount a Savings Plan would have delivered more flexibly.

Fun fact

Regional looks free until the AZ runs dry

When AWS introduced Regional RIs and then Savings Plans, the Zonal RI quietly became the only commitment that still reserves physical capacity. Most teams default to Regional without noticing the difference — until a scaling event during peak. One ad-tech company ran a Regional RI fleet of c5.4xlarge instances and assumed they had capacity guaranteed. During a Black Friday traffic spike they tried to scale out in us-east-1a and got InsufficientInstanceCapacity — the Regional RI gave them the discount but reserved nothing, and the AZ was simply out of c5.4xlarge. The fix was two lines of config: convert the critical baseline to Zonal RIs in the AZ that mattered. Same discount, same instances — but now the capacity was theirs.

Choosing between an RI and a Savings Plan in action

Dana runs the platform team at a streaming startup. The FinOps dashboard shows $52k of monthly EC2 spend, almost all On-Demand, across a steady fleet of m6i and c6i instances that's barely changed in a year. The instinct on the team is to "buy some Reserved Instances" — that's what the last company did.

Dana pushes back with the modern playbook. For the bulk of the steady baseline, a Compute Savings Plan delivers the same discount with full flexibility, so a future right-size or Graviton move never strands anything. She right-sizes two oversized m6i.8xlarge boxes down first, confirms the rest is genuinely steady-state, then commits a dollars-per-hour Savings Plan covering ~75% of the stable baseline — projecting roughly 40% off that slice with zero lock-in to a specific shape.

Then she handles the one workload that's different: a latency-critical matchmaking service pinned to c6i.4xlarge in us-east-1b that must be able to scale during launch nights, even when the AZ is busy. A Savings Plan won't guarantee that capacity. So for just that baseline, Dana buys Zonal Standard RIs in us-east-1b — same discount tier, but now AWS reserves the hardware. The Savings Plan covers the price for everything; the Zonal RI buys capacity insurance only where it's actually needed.

First, ask Cost Explorer what it would recommend buying as EC2 reservations. Useful as a baseline view — but remember a Savings Plan recommendation is the better comparison for pure discount.

$ aws ce get-reservation-purchase-recommendation --service "Amazon Elastic Compute Cloud - Compute" --term-in-years THREE_YEARS --payment-option PARTIAL_UPFRONT --lookback-period-in-days SIXTY_DAYS --query 'Recommendations[0].RecommendationDetails[0]'

{

"InstanceDetails": {

"EC2InstanceDetails": {

"Family": "c6i",

"InstanceType": "c6i.4xlarge",

"Region": "us-east-1",

"AvailabilityZone": "us-east-1b",

"Platform": "Linux/UNIX",

"Tenancy": "default"

}

"RecommendedNumberOfInstancesToPurchase": "8",

"EstimatedMonthlySavingsAmount": "6120.00",

"EstimatedSavingsPercentage": "41.2",

"EstimatedMonthlyOnDemandCost": "14850.00"

}

# A Zonal (AZ-scoped) RI here reserves capacity; a Savings Plan would match the discount, not the capacity.

The recommendation names a specific family, size, region, and AZ — that AZ scope is the only thing a Savings Plan can't replicate.

Now list the EC2 reservations you already own, so you can spot stranded ones and confirm which are Zonal (capacity) versus Regional (discount only).

$ aws ec2 describe-reserved-instances --filters Name=state,Values=active --query 'ReservedInstances[].{Id:ReservedInstancesId,Type:InstanceType,Scope:Scope,AZ:AvailabilityZone,Offer:OfferingClass,Count:InstanceCount,End:End}' --output table

-----------------------------------------------------------------------------------------------------

| DescribeReservedInstances |

+------------+---------------+----------+-------------+-------------+-------+------------------------+

| Id | Type | Scope | AZ | Offer | Count | End |

+------------+---------------+----------+-------------+-------------+-------+------------------------+

| ri-m5-old | m5.2xlarge | Region | - | standard | 4 | 2026-09-01T00:00:00Z |

+------------+---------------+----------+-------------+-------------+-------+------------------------+

# ri-c6i-01 is Zonal = capacity reservation (good reason to be an RI).

# ri-m5-old is Regional + a family you migrated off — discount-only, should have been a Savings Plan.

Scope tells the story: a Zonal RI is buying capacity; a Regional RI is buying a discount a Savings Plan would deliver more flexibly.

EC2 reservations under the hooddeep dive

An EC2 RI is matched against running instances by attributes: AWS region, instance type, platform/OS, and tenancy. A Standard RI locks those attributes for the term and gives the deepest discount; a Convertible RI gives a shallower discount but can be exchanged for a different family, OS, or tenancy later. The crucial split is scope. A Regional RI applies across all AZs in a region and brings instance size flexibility via normalization factors — within one family, a c6i.large is 4 units, c6i.xlarge 8, c6i.2xlarge 16 — so a 2xlarge reservation can cover two xlarge or four large, or partially cover a 4xlarge. But a Regional RI reserves no capacity.

A Zonal RI is the opposite trade. It is locked to a single Availability Zone and a single size — no size flexibility — but it reserves actual physical capacity in that AZ. AWS guarantees the hardware is available when you launch, which is the entire point of buying one. This is the only RI behaviour a Savings Plan cannot reproduce: Savings Plans are a pure billing discount with zero capacity guarantee. If you need assured capacity but not necessarily for a multi-year term, the standalone alternative is an On-Demand Capacity Reservation, which reserves AZ capacity with no commitment and can itself be discounted by a Savings Plan or Regional RI.

This is why right-sizing and architecture decisions must come before any Standard RI purchase. Standard RIs are non-exchangeable, so if you commit to c6i x86 and then migrate to Graviton c7g for its better price-performance, the c7g instances run On-Demand while the c6i reservation bills against nothing — you pay twice until expiry. Convertible RIs soften this (you can exchange families), but a Compute Savings Plan softens it completely and deeper, which is exactly why the modern default for pure discount is the Savings Plan and the RI is reserved for the capacity case.

# Compare what a Savings Plan would save against what an EC2 RI would save,
# for the same lookback window. For pure discount, the SP usually wins on flexibility.
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years THREE_YEARS \
  --payment-option PARTIAL_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationSummary'

# If you genuinely need capacity, buy a Zonal RI (note the AZ, not just the region)
# via the chosen offering ID. Confirm Scope=Availability Zone before purchasing.
aws ec2 describe-reserved-instances-offerings \
  --instance-type c6i.4xlarge \
  --availability-zone us-east-1b \
  --offering-class standard \
  --product-description "Linux/UNIX" \
  --query 'ReservedInstancesOfferings[?Scope==`Availability Zone`].[ReservedInstancesOfferingId,FixedPrice,Duration]'

What is the impact of getting the RI-vs-Savings-Plan choice wrong?

The first impact is leaving the discount uncaptured. A stable compute baseline left fully On-Demand forgoes up to ~72% off that slice. A c6i.4xlarge runs roughly $500/month On-Demand; a three-year commitment can drop the effective rate by 40–60%. Across an eight-instance baseline that's thousands a month, well into six figures a year of discount that AWS offers and no one is claiming — and for the pure-discount portion, a Savings Plan captures it with no shape lock-in at all.

The second impact is buying the wrong instrument and stranding it. Because Standard RIs are non-exchangeable and locked to a family, committing before a right-size or a Graviton (c7g) migration locks in the old shape — the reservation bills against capacity no one runs while the new instances pay On-Demand. You pay twice for the remaining term. This is the single most common RI mistake, and it's almost entirely avoidable: a Compute Savings Plan would have flexed across the migration automatically, capturing the same discount without the trap.

The third impact runs the other way: confusing discount with capacity. A team that buys Regional RIs believing they've guaranteed capacity gets a nasty surprise during a scaling event or AZ failover, because Regional RIs reserve nothing. The actual capacity tool is a Zonal RI or an On-Demand Capacity Reservation, scoped to a specific AZ. Misunderstanding this doesn't just waste money — it creates a false sense of resilience that fails exactly when it's needed most, during a spike or an outage.

Finally, this category is a maturity signal. An organisation still reflexively buying Standard RIs for discount — rather than Savings Plans — is running a dated commitment playbook, and probably carrying stranded reservations from past architecture changes. The mature pattern is unambiguous: Savings Plans for the rate, Zonal RIs or Capacity Reservations only where assured capacity is a real requirement, and every RI on the books traceable to a named capacity reason rather than habit.

How do you commit to EC2 capacity and discounts safely?

The modern EC2 commitment playbook is a four-step sequence, and the order is the whole point: right-size first, default to a Savings Plan for the discount, reach for a Zonal RI only when capacity is a real requirement, and review coverage and utilisation every month.

1. Right-size and resolve migrations BEFORE you commit

Commitments lock in a baseline, so fix the fleet first. Right-size over-provisioned instances down, terminate the abandoned ones, and resolve any planned moves — especially x86-to-Graviton (c6i → c7g). A Standard RI bought against a shape you're about to abandon is stranded waste for the full term with no exchange path. This single sequencing rule prevents the most common and most expensive RI mistake.

2. Default to a Savings Plan for the discount

For the steady baseline, a Compute Savings Plan delivers the same up-to-72% discount as a Standard RI but flexes automatically across family, size, region, OS, tenancy, and even Fargate and Lambda. Commit a dollars-per-hour figure to ~70–90% of the stable baseline. Because it isn't locked to a shape, a future right-size or Graviton move never strands it — which is exactly why it has superseded the RI for pure discount.

3. Buy a Zonal RI only when you need guaranteed capacity

Reach for a Reserved Instance only when a workload genuinely needs assured capacity in a specific AZ — critical services that must scale or fail over even when an instance type is scarce. Buy it Zonal (scoped to the AZ), not Regional, since only Zonal reserves capacity. If you need capacity without a multi-year term, use an On-Demand Capacity Reservation instead, which a Savings Plan can still discount. Record the capacity reason explicitly so the RI never gets mistaken for a stale discount buy.

4. Review coverage and utilisation on every FinOps cadence

Track two numbers monthly: coverage (share of compute hours on a commitment; target 70–90% on stable fleets) and utilisation (share of reserved capacity actually consumed; must stay near 100%). Watch for Savings-Plan-and-RI collisions on the same hours, and flag any Regional RI that's really a discount-only buy a Savings Plan would do better. Put RI and Savings Plan expirations on the calendar 60–90 days out so renewals are deliberate, never silent lapses to full price.

# Compare the EC2 RI recommendation against the Savings Plan recommendation
# for the same window. For pure discount, expect the SP to be at least as good.
aws ce get-reservation-purchase-recommendation \
  --service "Amazon Elastic Compute Cloud - Compute" \
  --term-in-years THREE_YEARS \
  --payment-option PARTIAL_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --query 'Recommendations[0].RecommendationSummary.{Savings:TotalEstimatedMonthlySavingsAmount,Pct:TotalEstimatedMonthlySavingsPercentage}'

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP --term-in-years THREE_YEARS \
  --payment-option PARTIAL_UPFRONT --lookback-period-in-days SIXTY_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationSummary'

# Check existing commitment coverage so you don't double-buy across SP and RI.
aws ce get-reservation-coverage \
  --time-period Start=$(date -u -d '30 days ago' +%F),End=$(date -u +%F) \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --query 'Total.CoverageHours.CoverageHoursPercentage'

Quick quiz

Question 1 of 5

You have a stable fleet of c6i.4xlarge instances running fully On-Demand. Most of it just needs the discount, but one latency-critical service must be guaranteed capacity in us-east-1b during launch-night scale-outs. The team also plans a Graviton (c7g) migration next quarter for the bulk of the fleet. What's the right move?

Keep learning

Dig deeper into EC2 reservation mechanics, the Savings Plan comparison, and where capacity reservations fit.

You've completed Purchase EC2 Reserved Instances. You now know the most important thing about the RI: for pure discount, the Savings Plan has superseded it — same savings, far more flexibility — so the honest reason to still buy an RI is capacity. You know the Standard-vs-Convertible and Regional-vs-Zonal distinctions, that only a Zonal RI reserves AZ capacity, and the sequence that protects you: right-size first, Savings Plan for the rate, Zonal RI (or a Capacity Reservation) only where guaranteed capacity is a real requirement. The next time someone says "let's buy RIs," you'll know the right question to ask first.

Back to the library

EC2 Reserved Instances: what it means for the bill

Mostly a story about not double-buying your discount

For the EC2 line on your bill, the discount tool of choice is now the Savings Plan, not the Reserved Instance. A Savings Plan commits you to a dollars-per-hour of compute spend and applies the same up-to-72% discount as a Reserved Instance would, but it flexes automatically across instance types, regions, and even Fargate and Lambda. For pure rate reduction, it has effectively replaced the EC2 RI — so the headline finance question is usually "is our steady EC2 baseline covered by a Savings Plan," not "should we buy RIs."

The Reserved Instance survives for one specific reason that does cost money when ignored: capacity. A Zonal Reserved Instance is the only commitment that guarantees AWS will have the hardware available in a given Availability Zone — useful for critical workloads that must be able to scale or fail over even when a popular instance type is scarce. That guarantee is an insurance purchase, not a discount play, and it's worth understanding the difference so the conversation doesn't get muddled.

The numbers to watch are coverage and utilisation, the same as any commitment. EC2 commitment coverage is the share of steady-state compute hours sitting on a Savings Plan or RI rather than On-Demand; a stable fleet should be 70–90% covered. The trap specific to RIs is double-buying: a Savings Plan and an RI can collide on the same instance-hour, and if utilisation of a reservation slips below ~100% you're paying for a commitment nothing is consuming. The right framing at the cost review is simple — most coverage should come from Savings Plans, and any RI on the books should have a named reason that's about capacity, not price.

This lesson is for the finance partner who hears "we should buy Reserved Instances to save on EC2" and wants to know whether that's still the right move. It walks through why Savings Plans have largely replaced RIs for discount purposes, the one capacity-assurance case where an RI still earns its place, how coverage and utilisation behave as monthly metrics when you have both instruments, and the double-buy and stranding risks to guard against. By the end you'll know which numbers to ask for at the cost review and how to tell a sound RI purchase from a dated one.

Fun fact

Regional looks free until the AZ runs dry

How a finance partner frames the decision

Raj is the finance partner embedded with the platform team. At the monthly cost review the engineering lead floats "buying Reserved Instances" to cut the $52k EC2 line. Raj's first question is the one that saves money: "Why an RI and not a Savings Plan — do we need capacity guarantees, or just the discount?" The honest answer for the bulk of the fleet is: just the discount.

That reframes the whole purchase. For pure discount, the Savings Plan is the better instrument — same savings, no lock-in to a specific instance shape, so a future right-size doesn't strand the commitment. Raj asks the team to right-size first, then commit a Savings Plan to ~75% of the stable baseline, with an explicit payback calculation on the term. He deliberately avoids 100% coverage so headroom remains for change.

The only place Raj signs off on an actual Reserved Instance is the latency-critical service that needs guaranteed capacity in one AZ — and he records capacity assurance, not discount, as the documented reason in the cost pack. Then he adds two standing numbers: EC2 commitment coverage (target 70–90%) and reservation utilisation (must stay near 100%), plus a note that any RI on the books needs a capacity justification or it should have been a Savings Plan.

Why this matters to the budget, not just the bill

The headline is a missed discount on the largest, most predictable line on the bill. Compute is typically 40–60% of cloud spend and much of it runs 24x7 — the most committable spend you have. Leaving a stable baseline On-Demand forgoes up to ~72%, and for the pure-discount portion the right tool is the Savings Plan: same saving, no lock-in to a specific instance shape, so it requires no engineering change and survives right-sizing untouched.

The reason RIs still show up is capacity, and that's a different budget conversation — an insurance cost, not a discount. A Zonal RI (or an On-Demand Capacity Reservation) is the only way to guarantee hardware in a specific AZ, which a critical, scale-sensitive workload may genuinely require. Treat any RI line on the bill as needing a capacity justification; if the only reason is "to save money," it should almost certainly have been a Savings Plan, and you're carrying avoidable rigidity.

Coverage and utilisation are the monthly metrics, just as with any commitment. EC2 commitment coverage — share of steady compute hours on a Savings Plan or RI — should sit 70–90% on a stable fleet. The risk unique to running both instruments is collision and over-commitment: a Savings Plan and an RI can chase the same hour, and if reservation utilisation drops below ~100% you're paying for capacity nothing consumes. Watch both numbers, and watch RI expirations 60–90 days out so renewals are deliberate.

The cash-versus-discount tradeoff in the three payment options (No/Partial/All Upfront) is finance's call, with an explicit payback calculation. But the more consequential decision is instrument choice: a wrong Standard RI is locked-in waste for years because it can't be exchanged, whereas a Savings Plan flexes and a Capacity Reservation can be released. The protective rule is simple to hold the line on — Savings Plan first for price, RI only for a documented capacity need, and never an RI bought ahead of a known architecture change.

What finance can actually do about this

Finance owns the commitment and instrument decision even though it can't run the CLI. Four levers, used together on the monthly cadence.

1. Make Savings Plan the default question, not Reserved Instance

When a team proposes "buying RIs" to cut EC2, the first finance question is "why not a Savings Plan?" For pure discount the SP wins on flexibility at the same saving. Reframe the conversation so the RI has to justify itself with a capacity reason — that one habit prevents most stranded-reservation waste before it happens.

2. Require a capacity justification for every Reserved Instance

Any RI on the books should carry a documented reason that's about guaranteed capacity in a specific AZ, not price. If the only rationale is "to save money," it should have been a Savings Plan. Treat Regional RIs with particular suspicion — they reserve no capacity, so a Regional RI is almost always a discount buy that a Savings Plan would do more flexibly.

3. Own the payment-option and term decision, after right-sizing

No/Partial/All Upfront and 1- vs 3-year are cash-versus-discount tradeoffs — a finance call requiring an explicit payback calculation. But hold the precondition: no commitment until the fleet is right-sized and any Graviton or family migration is resolved. A premature Standard RI is non-exchangeable locked-in waste; clean up first, commit second.

4. Watch utilisation and collisions, not just coverage

High coverage with sagging utilisation means over-commitment — reservations billing against instances no one runs. Keep utilisation near 100% and watch for Savings-Plan-and-RI overlap on the same hours. Put every commitment's expiration on the finance calendar 60–90 days ahead so renewals are deliberate and never a silent lapse back to On-Demand.

Quick quiz

Question 1 of 5

EC2 is $52k/month, almost entirely On-Demand, on a fleet that's been stable for a year. The engineering lead proposes buying 3-year Standard Reserved Instances to cut the rate. As the finance partner, what's the right next move?

Keep learning

Dig deeper into EC2 reservation mechanics, the Savings Plan comparison, and where capacity reservations fit.

You've finished the finance partner's view of EC2 Reserved Instances. You know the Savings Plan has replaced the RI for pure discount, that any RI on the books needs a capacity justification rather than a price one, which two metrics to track — coverage and utilisation — and the rule that prevents stranded waste: right-size first, Savings Plan for the rate, Zonal RI only for genuine capacity needs. Next time a team proposes buying RIs, you'll have a sharper question than "how big a discount do we get?"

Back to the library

EC2 Reserved Instances: the headline

The discount tool changed; the discipline didn't

Compute is usually the largest cloud cost, and a steady compute baseline can be discounted up to ~72% with a commitment. The important update for leadership: the modern instrument for that discount is the Savings Plan, which has largely superseded the older Reserved Instance because it delivers the same savings with far more flexibility. If anyone is still buying Reserved Instances purely to cut the rate, that's usually a sign the commitment strategy is dated.

The one legitimate reason to still buy a Reserved Instance is capacity assurance — guaranteeing the hardware will be there in a specific location for a critical workload, which a Savings Plan cannot do. The question worth asking is: "Is our steady compute baseline covered by Savings Plans, and is any Reserved Instance we hold there for a capacity reason rather than a price one?" The discipline this signals is whether the team is using the current best tool, not the one they learned five years ago.

A short read for the exec who wants the headline and the single question to ask. You'll get why the discount tool for compute has changed from the Reserved Instance to the Savings Plan, the one reason an RI still exists, and what "good" coverage looks like — no commands, no internals.

Fun fact

Regional looks free until the AZ runs dry

What it looks like when the org gets this right

At one company, the cloud-cost review used to feature a recurring proposal to "buy more Reserved Instances" every time EC2 spend ticked up. It sounded responsible, but it was the old playbook — and several of those RIs had already been stranded by right-sizing and a Graviton migration, billing against instances no one ran.

The exec sponsor reframed it with one question: "Are we using the current best tool for the discount, and is any Reserved Instance we hold there for a capacity reason?" That surfaced the answer fast — most of the discount should come from flexible Savings Plans, and RIs should be reserved for the handful of workloads that genuinely need guaranteed capacity in a specific location.

The lasting outcome wasn't a one-time saving; it was the principle. Savings Plans for price, Zonal Reserved Instances for capacity, and never the two confused. The review now tracks compute coverage as one number and flags any RI without a capacity justification, and the reflexive "buy more RIs" proposal stopped appearing.

Why this is on the report at all

Compute is usually the biggest, most predictable cloud cost, so it's the prime candidate for a multi-year discount of up to ~72%. The reason this lands on the report is that the right discount tool has changed: the Savings Plan has superseded the Reserved Instance for pure savings, delivering the same discount with far more flexibility. An organisation still buying Reserved Instances for price — and stranding them when architecture changes — is using a dated playbook, and the size of that habit is a direct measure of avoidable lock-in.

The discipline behind it matters more than any single purchase. The mature pattern is Savings Plans for the discount and Reserved Instances only where guaranteed capacity in a specific location is a real requirement — an insurance need, not a price one. Whether the team can articulate that distinction, and whether every RI on the books has a capacity reason, is the tell for whether the commitment strategy is current or running on muscle memory.

The leadership move on this category

The executive handle isn't to approve a purchase — it's to set the principle that makes the purchases sound.

1. Set Savings Plans as the default discount instrument

Make it a stated principle that the compute discount comes from Savings Plans, which have superseded Reserved Instances for pure savings. Anyone proposing an RI for price reasons is using a dated playbook; the flexible instrument captures the same discount without locking the fleet to a shape that will change.

2. Reserve RIs for genuine capacity needs only

A Reserved Instance — specifically a Zonal one — earns its place only when a critical workload needs guaranteed capacity in a specific location, which a Savings Plan cannot provide. Treat that as an insurance decision with a named owner and a named workload, not a default. Every RI should be traceable to a capacity reason.

3. Treat compute coverage as a one-minute confidence signal

"Is our steady compute baseline covered by Savings Plans, is utilisation near 100%, and is any RI we hold there for a capacity reason?" is a one-line review item that reveals whether the commitment strategy is current. Healthy, flexible coverage with full utilisation means the discipline is working and attention belongs elsewhere.

Quick quiz

Question 1 of 5

Your team proposes buying Reserved Instances every time EC2 spend rises, and you learn some past RIs were stranded by a right-size and a Graviton migration. You ask one question and find most of the need is just discount. What's the right read?

Keep learning

Dig deeper into EC2 reservation mechanics, the Savings Plan comparison, and where capacity reservations fit.

That's the lesson. Two takeaways worth holding onto: the Savings Plan has superseded the Reserved Instance as the tool for discounting compute, and the only reason to still buy an RI is guaranteed capacity in a specific location — an insurance decision, not a price one. The leadership question is whether the team is using the current best instrument and whether every Reserved Instance has a capacity reason behind it.

Back to the library

Part of the learning path Lock in your commitments

Purchase EC2 Reserved Instances

EC2 Reserved Instances: the basics

Regional looks free until the AZ runs dry

Choosing between an RI and a Savings Plan in action

EC2 reservations under the hooddeep dive

What is the impact of getting the RI-vs-Savings-Plan choice wrong?

How do you commit to EC2 capacity and discounts safely?

1. Right-size and resolve migrations BEFORE you commit

2. Default to a Savings Plan for the discount

3. Buy a Zonal RI only when you need guaranteed capacity

4. Review coverage and utilisation on every FinOps cadence

Quick quiz

Keep learning

EC2 Reserved Instances: what it means for the bill

Regional looks free until the AZ runs dry

How a finance partner frames the decision

Why this matters to the budget, not just the bill

What finance can actually do about this

1. Make Savings Plan the default question, not Reserved Instance

2. Require a capacity justification for every Reserved Instance

3. Own the payment-option and term decision, after right-sizing

4. Watch utilisation and collisions, not just coverage

Quick quiz

Keep learning

EC2 Reserved Instances: the headline

Regional looks free until the AZ runs dry

What it looks like when the org gets this right

Why this is on the report at all

The leadership move on this category

1. Set Savings Plans as the default discount instrument

2. Reserve RIs for genuine capacity needs only

3. Treat compute coverage as a one-minute confidence signal

Quick quiz

Keep learning

Related cost lessons