Savings Plans and Reserved Instances

Once you have cut waste and right-sized (the previous lessons), the workloads that remain — your steady baseline — are running on on-demand pricing, which is the most expensive way to pay. Savings Plans and Reserved Instances give you a substantial discount (up to ~72%) on that baseline in exchange for a commitment. Used correctly, they cut the cost of the compute you are running anyway; used carelessly, you over-commit and waste the commitment. This lesson is how to use them well.

Commit to your baseline, get a discount

The core idea: AWS on-demand pricing has no commitment — you pay full price for flexibility. But most systems have a steady baseline of usage that is always running (your production services do not disappear at night). For that predictable baseline, you can commit to a certain amount of usage for 1 or 3 years, and AWS gives you a large discount in return — because you are giving AWS predictable revenue, it gives you a predictable, lower price.

The discount is significant — commonly ~30% for a 1-year commitment up to ~60-72% for a 3-year commitment, depending on the plan and term.
It applies to usage you are running anyway — so it is close to free savings for the baseline, with no change to what you run.
The commitment is the catch — you pay for the committed amount whether or not you use it, so you commit only to the baseline you are confident will keep running.

The sequence matters: cut waste and right-size first, then commit. If you buy Savings Plans before right-sizing, you commit to over-provisioned usage and lock in the waste. Optimise the baseline down, then commit to the smaller, right-sized baseline. Order is important — discounts come last, after the workload is already lean.

Savings Plans vs Reserved Instances

Two mechanisms exist, and Savings Plans are usually the better choice now:

Savings Plans — you commit to a certain dollars-per-hour of compute spend for 1 or 3 years, and get the discount on usage up to that commitment. Compute Savings Plans are the flexible kind: the discount applies across EC2, Fargate and Lambda, across instance families, sizes and regions — so you keep flexibility (change instance types, move regions) while still getting the discount. EC2 Instance Savings Plans give a bigger discount but lock you to an instance family in a region.
Reserved Instances (RIs) — the older mechanism: you reserve specific instance types in a region. Less flexible than Savings Plans (tied to instance type), and largely superseded by Savings Plans for compute, though RIs still matter for some services (RDS, ElastiCache reserved capacity).

For most teams, Compute Savings Plans are the right default: a meaningful discount with the flexibility to keep changing your infrastructure (adopting Graviton, resizing, moving regions) without losing the saving. Reserve the less-flexible options for cases where the extra discount is worth locking in a specific shape.

How much to commit: cover the baseline, not the peak

The key decision is how much to commit, and the principle is: commit to your stable baseline, leave the variable part on-demand (or Spot).

Cover the baseline you are certain about — the always-on minimum you are confident will keep running for the term. This gets the discount on the bulk of steady spend.
Leave headroom and variability on-demand or Spot. The part of your usage that fluctuates (autoscaling surges, uncertain future growth, workloads that might change) stays on flexible pricing — on-demand for short-term flexibility, Spot for interruptible/replicated workloads (the compute module) at a bigger discount than any commitment.
Do not over-commit. Committing to more than your reliable baseline means paying for commitment you do not use — waste. It is better to commit conservatively (say, cover 60-80% of steady usage) and pay on-demand for the rest than to over-commit and eat unused commitment. AWS Cost Explorer provides Savings Plans recommendations based on your actual usage history — a good starting point for how much to commit.

So the shape is: a Savings Plan covering the confident baseline (big discount), on-demand for flexibility and uncertainty, and Spot for the interruptible burst (biggest discount). That combination minimises cost across the whole workload while keeping the flexibility to change.

Fitting commitments into the bigger picture

Savings Plans are the last cost lever, and they layer on top of everything else:

First cut waste (common-waste) and right-size (rightsizing) — so you commit to a lean baseline, not a bloated one.
Prefer Graviton and Spot (compute module) — Savings Plans even apply to Graviton usage, compounding the savings, and Spot covers the interruptible part more cheaply than any commitment.
Then commit to the optimised baseline with a Compute Savings Plan, sized conservatively from Cost Explorer's recommendations.
Review commitments (the cost-review lesson) — as usage grows, you may add commitment; as it changes, you ensure you are not holding unused commitment. Commitments are re-evaluated, not set-and-forget.

The result is that your steady workload runs at a large discount, your variable workload stays flexible, and your interruptible workload runs on Spot — the cost-optimal arrangement. The discipline, as throughout: optimise what you run first, then buy the discount for the lean baseline that remains — never commit to waste, and never over-commit.

Check your work

The idea: on-demand = full price for flexibility; your steady baseline is predictable, so commit (1 or 3 yr) for a big discount (~30% 1-yr to ~60-72% 3-yr) on usage you run anyway. Catch: you pay the commitment whether used or not — commit only to confident baseline. Cut waste + right-size FIRST, then commit (don't lock in over-provisioning).

Savings Plans vs RIs: Compute Savings Plans (commit $/hr of compute spend; flexible across EC2/Fargate/ Lambda, families, sizes, regions — the usual default) vs EC2 Instance Savings Plans (bigger discount, locked to family/region) vs Reserved Instances (older, tied to instance type — largely superseded for compute; still used for RDS/ElastiCache).

How much: cover the certain baseline (discount on the bulk); leave variability/headroom on on-demand and interruptible burst on Spot (bigger discount); don't over-commit (unused commitment = waste); use Cost Explorer's recommendations (cover ~60-80% of steady usage conservatively).

Order: cut waste → right-size → Graviton/Spot → commit to the lean baseline → review commitments. Optimise first, then discount the remainder. Never commit to waste; never over-commit.

Practice

Explain how committing to a baseline earns a discount, and why you must optimise before committing.
Compare Compute Savings Plans, EC2 Instance Savings Plans and Reserved Instances, and which is the usual default.
Explain how much of your usage to commit and why over-committing is waste.
Explain how Savings Plans, on-demand and Spot combine across a workload's baseline, headroom and burst.
Explain why Savings Plans are the last cost lever and what must come first.
Describe how you'd use Cost Explorer's recommendations to decide a commitment.

Official documentation

AWS — Savings Plans — Committing to usage for a discount.
AWS — Reserved Instances (EC2) — Reserved capacity and how it compares.
AWS — Savings Plans recommendations — Sizing a commitment from real usage.

Next: running a monthly cost review.