Savings Plans are the single biggest lever on a steady-state AWS compute bill. Commit to a dollar-per-hour amount for 1 or 3 years and AWS discounts that usage up to ~66–72% off on-demand. This page walks the three plan types, the upfront options, the real discount math, Savings Plans vs Reserved Instances, the coverage and utilization targets to hit, and the laddering strategy that keeps you from over-committing — then how a CloudRoute-matched partner runs the whole program for you (often AWS-funded, so you cut the bill for $0).
The mental model trips people up. A Savings Plan does not reserve a server. It is a billing-layer commitment: you promise AWS a fixed dollars-per-hour of compute spend for a term, and in return AWS bills the usage that commitment covers at a discounted rate instead of on-demand.
Concretely: you commit to, say, $10.00/hour of compute for one year. Each hour, AWS takes your eligible usage and applies your Savings Plan rate (the discounted price) to it, working from the highest-discount usage first, until your $10.00/hour commitment is consumed. Anything above that runs at on-demand. Anything below means you under-used the commitment — you still pay the full $10.00 that hour because you committed to it.
That is the whole game, and it explains every downstream decision. Because the commitment is denominated in dollars-per-hour of spend (not in specific instances), a Compute Savings Plan automatically follows your usage as you change instance families, sizes, regions, or even shift from EC2 to Fargate to Lambda. You are not locked to a machine; you are locked to a spend rate. That flexibility is the headline advantage of Savings Plans over the older Reserved Instance model for compute.
The discount comes from commitment, not from any technical change. You run the exact same EC2 instances, the same Fargate tasks, the same Lambda functions — AWS simply charges them less because you guaranteed steady consumption. This is why Savings Plans are the first lever a FinOps team pulls: there is no migration, no code change, no risk to reliability. The only "cost" is the commitment itself, which is why sizing it correctly is the entire discipline.
Two numbers govern the health of any Savings Plan portfolio, and you will see them in Cost Explorer's Savings Plans dashboards: coverage (what share of your eligible on-demand-equivalent usage is sitting under a commitment vs. running at full on-demand) and utilization (what share of the $/hour you committed to is actually being consumed). High coverage means you are capturing the discount broadly; high utilization means you are not wasting commitment. The rest of this guide is, in effect, how to keep both high without over-committing.
AWS sells three Savings Plan products. They trade flexibility for discount depth in a predictable way: the more you pin down, the deeper the discount. Picking the right mix is the first real decision.
The honest default for almost every startup and growth-stage team is the Compute Savings Plan, for one reason: your architecture will change over the next 1–3 years, and a commitment that follows you is worth more than a few extra points of discount on a commitment you might strand. But the deeper-discount EC2 Instance plan has its place for genuinely stable, well-understood workloads. Here is how each behaves.
Applies to: EC2 (any instance family, size, OS, tenancy), AWS Fargate, and AWS Lambda — across all regions, automatically.
Discount: up to ~66% off on-demand (representative; the exact rate varies by instance family and term — check the AWS pricing pages / Cost Explorer recommendations for current numbers).
The pitch: you commit to a $/hour and AWS applies it wherever your compute runs. Migrate from m5 to m7g (Graviton), shift a service from EC2 to Fargate, move region — the commitment follows. Nothing to re-buy, nothing stranded.
Best for: the baseline compute of any team whose architecture is still evolving — i.e., almost everyone. This should be the foundation layer of your commitment portfolio.
Applies to: a specific EC2 instance family in a specific region (e.g., m5 in us-east-1). Within that family + region you keep flexibility across size, OS, and tenancy, and across Availability Zones — but you are committed to that family in that region.
Discount: up to ~72% off on-demand — a few points deeper than Compute SP, in exchange for the reduced flexibility.
The pitch: if you know a given family will run in a given region for the whole term — a stable production fleet that is not moving to Graviton or Fargate any time soon — the EC2 Instance plan harvests the extra discount.
The risk: if you later move that workload off the m5 family (say, to Graviton m7g) or to another region, the EC2 Instance plan does not follow. You either keep paying for a commitment that no longer matches, or you eat the change. This is the classic over-commitment trap.
Applies to: Amazon SageMaker ML instance usage — training, real-time inference, batch transform, notebooks, processing — across instance families and regions.
Discount: up to ~64% off on-demand SageMaker ML pricing (representative).
The pitch: teams running steady ML training or always-on inference endpoints on SageMaker can commit to a $/hour the same way and discount that spend. SageMaker usage is not covered by Compute or EC2 Instance plans, so if ML is a meaningful slice of your bill it needs its own commitment.
Best for: ML-heavy teams with predictable training cadence or production inference endpoints that run continuously. Spiky, occasional training is usually better left on-demand or on Spot.
Every step you take toward pinning down usage buys a few points of discount: Compute SP (flex everywhere, ~66%) → EC2 Instance SP (one family + region, ~72%). The extra ~6 points is only worth it if you are genuinely confident that usage will not move for the full term. When in doubt, take the Compute SP — a discount that follows you beats a deeper discount you might strand.
Two orthogonal choices set your discount once you have picked a plan type: the term length (1 or 3 years) and the payment option (No Upfront, Partial Upfront, All Upfront). Both push the discount in the same direction — more commitment, more upfront cash, deeper discount.
Term: 1 year vs 3 years. A 3-year commitment carries a materially deeper discount than a 1-year — often 10–20 percentage points more on the same usage. But three years is a long time for a company whose compute footprint could double, halve, or completely re-platform. The trade is real money against real uncertainty. Most fast-moving teams ladder mostly 1-year plans for the bulk of their baseline and reserve 3-year commitments for the rock-solid floor of usage they are certain will persist (core production databases' compute, always-on control planes, etc.).
Payment: No / Partial / All Upfront. All three give you the same hourly commitment; they differ in when you pay and how deep the discount goes:
The discount deltas between payment options are usually small — often only a few percentage points from No Upfront to All Upfront. For most teams, the term choice (1 vs 3 year) and getting coverage right move the bill far more than the upfront option does. Do not tie up six figures of cash in All Upfront for a 2–3 point gain you could get more safely by simply increasing coverage with No Upfront plans.
A practical pattern for a startup sitting on AWS Activate credits: use the credits to buy an All Upfront 1-year Compute Savings Plan on your stable baseline. The credits cover the lump sum (so no real cash leaves the building), you lock the deepest 1-year rate, and you have effectively converted soft, expiring credits into a hard, year-long discount on the usage you were going to run anyway. (See the AWS credits guide linked below.)
Reserved Instances (RIs) were the original commitment-for-discount mechanism. Savings Plans launched as the flexible successor for compute, and for EC2 they have largely replaced RIs. But RIs are not dead — they are now the right tool for a specific set of services.
For raw EC2 compute, Savings Plans win in almost every case: they deliver the same or better discount with far more flexibility (the commitment follows you across families, sizes, regions, Fargate, and Lambda, where a Standard RI is pinned and even a Convertible RI requires manual exchanges). There is very little reason to buy new EC2 RIs in 2026 when a Compute or EC2 Instance Savings Plan does the same job more flexibly.
Where RIs still matter is the services Savings Plans do not cover. Savings Plans apply only to EC2, Fargate, Lambda, and (via the SageMaker plan) SageMaker. They do not apply to RDS, ElastiCache, Redshift, or OpenSearch. For those, Reserved Instances (or Reserved Nodes) remain the commitment vehicle — and the discounts are substantial, often in the same ~30–65% range depending on service, term, and upfront option.
So the 2026 division of labor is clean: Savings Plans for compute (EC2 / Fargate / Lambda / SageMaker), Reserved Instances for the managed data services (RDS / ElastiCache / Redshift / OpenSearch). A complete commitment strategy uses both — a Compute Savings Plan covering the compute baseline, plus RDS/ElastiCache RIs covering the database baseline. The comparison table below lays out the compute-side choice in detail.
One more honest tradeoff that applies to every commitment instrument: it reduces flexibility in exchange for discount. A Savings Plan is genuinely more flexible than an RI, but it is still a commitment — you are obligated to the $/hour for the full term whether or not you use it. The mitigations are coverage discipline and laddering, both covered next. The CloudRoute angle is that you do not have to weigh all this alone: a partner models it against your actual usage and carries the analysis.
A Savings Plan portfolio is healthy when two metrics are both high: coverage (you are discounting most of your eligible usage) and utilization (you are consuming most of what you committed to). They pull in opposite directions, which is the whole reason sizing is hard.
Utilization is the share of your committed $/hour that gets consumed. If you commit to $10/hour and only run $9.50/hour of eligible usage in an hour, utilization is 95% — and you paid for $0.50/hour of discount you did not use. Target ≥ 95–100% utilization. Under-utilization is pure waste: you are paying the on-demand-equivalent of the unused commitment with none of the benefit. Because utilization measures the floor of your usage, you protect it by committing only up to the level your usage never drops below.
Coverage is the share of your total eligible (on-demand-equivalent) compute that is sitting under a commitment rather than running at full on-demand. If half your compute is on a Savings Plan and half is on-demand, coverage is ~50%. Higher coverage = more of your bill discounted. But you cannot push coverage to 100% safely, because the top slice of your usage is variable — it spikes and dips — and committing to it would tank utilization when it dips.
The resolution is to target coverage of your stable baseline, not your total. In practice that lands most teams at ~70–85% coverage: commit to the portion of compute that is reliably always-on, and let the variable top slice run on-demand (or, better, on Spot). At 70–85% coverage with ≥95% utilization, you are capturing the large discount on the bulk of the bill while keeping waste near zero and retaining headroom to scale down without stranding commitment.
How to find the baseline: pull the last 30–90 days of compute usage from Cost Explorer (or the Cost and Usage Report for line-item precision) and look at the trough — the lowest your eligible compute spend drops to across the period. That trough is the safe commitment floor; usage never goes below it, so a commitment up to that level stays ~100% utilized. Cost Explorer's built-in Savings Plans recommendations do exactly this analysis and propose a commitment; treat their numbers as a starting point and sanity-check against your own growth expectations.
Commit to the baseline, run the peaks on-demand or Spot. Target ~70–85% coverage of eligible compute at ≥95% utilization. If utilization slips below ~95% you over-committed; if coverage is well under 70% you are leaving easy discount on the table. The sweet spot discounts most of the bill while keeping waste near zero.
The single biggest mistake teams make with Savings Plans is buying one large, long commitment all at once. Laddering — staggering many smaller commitments on a rolling schedule — solves the two problems a single big block creates: rate lock-in at a bad moment, and a cliff when it all expires together.
Imagine committing your entire baseline to one 3-year All Upfront Compute Savings Plan today. Two things can go wrong. First, your usage might fall (a workload gets re-platformed, a customer churns, you migrate to Graviton and your dollar-baseline drops) — and now you are stuck paying for a 3-year commitment that no longer matches, for years. Second, even if usage holds, the whole commitment expires on the same day three years out, creating a re-purchase cliff where you must re-commit your entire baseline at once at whatever rates exist then.
Laddering fixes both. Instead of one $10/hour 3-year plan, you buy, say, a series of smaller 1-year plans spaced out over time — a few dollars-per-hour of commitment each quarter — so that at any given moment only a slice of your portfolio is up for renewal, and your commitments expire on a rolling schedule rather than all at once. As each small plan expires, you re-evaluate against current usage and either renew, resize, or let it lapse. Your committed total tracks your actual baseline far more closely, and you are never forced into a single all-or-nothing re-purchase decision.
The laddering mindset also disciplines growth. Rather than trying to predict your usage three years out (impossible for most startups), you commit conservatively to what you are sure of now, then add rungs to the ladder as usage proves out and the baseline rises. Under-commit and add later — the cost of being slightly under-covered for a month (a little on-demand spend) is trivial compared with the cost of being over-committed for years (paying for compute you no longer run).
A simple starter ladder for a growth-stage team: take your verified stable baseline, commit ~60–70% of it to 1-year No Upfront Compute Savings Plans bought in two or three tranches a quarter apart, leave the top variable slice on-demand/Spot, and reserve any 3-year commitment for the unambiguous always-on floor. Revisit quarterly: as the trough of your usage rises, add a rung. This keeps coverage in the 70–85% band and utilization near 100% while your footprint grows.
Sizing a Savings Plan is a repeatable analysis, not a guess. And because optimal coverage drifts every time your usage changes, it is exactly the kind of always-on optimization that automation (or a managed partner) does better than a quarterly human spreadsheet.
The manual sizing recipe: (1) pull 30–90 days of compute usage and cost from Cost Explorer or the CUR; (2) identify the trough — the level your eligible compute never drops below — as your safe commitment floor; (3) decide the mix of plan types (Compute SP for the flexible bulk, EC2 Instance SP only for genuinely stable family+region fleets, SageMaker SP if ML is material); (4) choose term and upfront per tranche (mostly 1-year No Upfront, 3-year only for the certain floor, All Upfront only if you have cash or credits); (5) buy in tranches to start the ladder; (6) watch coverage and utilization weekly in Cost Explorer and adjust.
The catch is step 6. Your baseline is not static — it moves with every deploy, every autoscaling change, every new service, every Graviton migration. A commitment that was perfectly sized in January can be over- or under-covered by April. Keeping coverage in the 70–85% band and utilization near 100% as the underlying usage drifts is continuous work, and doing it well by hand requires someone watching the dashboards and topping up the ladder on a regular cadence.
This is where automated commitment-management platforms (ProsperOps-style services) and managed partners come in. They watch coverage and utilization continuously, buy small Savings Plans to keep coverage optimal as usage rises, let plans expire as usage falls, and blend Savings Plans with RIs across the account to maximize the effective discount — all without a human re-running the analysis every week. The result is typically higher effective savings than a team achieves managing it manually a couple of times a quarter, because the portfolio is continuously tuned rather than periodically corrected.
There is a real risk to flag honestly: automation can over-buy if it is configured aggressively or chases short-term spikes, leaving you with commitment you have to grow into. Good automation (and good partners) buy conservatively — short terms, small increments, weighted to what is already proven — precisely so the laddered portfolio degrades gracefully if usage dips. Ask any automation provider or partner how they protect utilization on the downside before you let them touch the account.
Sizing, laddering, and continuously tuning a commitment portfolio is exactly the work a vetted AWS partner does as part of a cost-optimization engagement — and for qualifying engagements, AWS funds it, so you cut the bill for $0.
CloudRoute routes you to an AWS partner who runs a commitment analysis against your real Cost Explorer / CUR data, models the optimal mix of Compute Savings Plans, EC2 Instance Savings Plans, and RIs, recommends terms and upfront options sized to your cash position and credit balance, sets up the laddering schedule, and then manages coverage and utilization on an ongoing basis. You get the savings without standing up the FinOps muscle to chase it yourself.
The honest funding framing: AWS funds partner-led cost-optimization and Well-Architected engagements through dedicated programs, and a Well-Architected Review can unlock remediation credits. For qualifying, credit-eligible engagements that means the optimization work is AWS-funded — the partner is paid through AWS, and you cut your bill for $0. Where an engagement does not qualify for funding, it is a vetted-partner referral that pays for itself many times over in the commitment savings (a Savings Plan program on a six-figure annual compute bill routinely saves more in the first quarter than the engagement costs). Either way, the savings are yours to keep.
This pairs naturally with the rest of a cost-optimization sweep — right-sizing instances first (so you commit to a lean baseline, not a bloated one), moving stateless workloads to Spot, and migrating to Graviton — all of which the same partner can do in one engagement. The Savings Plan sits on top of an already-right-sized fleet for the deepest combined effect. See the right-sizing and broader cost-optimization siblings linked below, and the Well-Architected Review for the funding mechanics.
The compute-side commitment decision in one view. Discounts are representative ranges for 2026 — exact rates vary by instance family, region, term, and upfront option, so confirm against AWS pricing pages and Cost Explorer recommendations before committing.
| Variable | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instances (EC2) |
|---|---|---|---|
| What you commit to | $/hour of compute spend | $/hour, one instance family + region | Specific instance type (or normalized family) |
| Applies across | EC2, Fargate, Lambda — all regions/families | One EC2 family in one region (any size/AZ/OS) | The reserved type; Convertible can be exchanged |
| Max discount (representative) | up to ~66% | up to ~72% | up to ~72% (Standard); less for Convertible |
| Flexibility | Highest — follows family, size, region, Fargate, Lambda | Medium — flex within family + region only | Lowest (Standard) / manual exchange (Convertible) |
| Terms | 1 or 3 year | 1 or 3 year | 1 or 3 year |
| Payment options | No / Partial / All Upfront | No / Partial / All Upfront | No / Partial / All Upfront |
| Over-commitment risk | Lowest — moves with you | Higher — stranded if you leave the family/region | Highest — pinned to the type |
| Best for | The flexible compute baseline (default) | Stable, well-understood fleets staying put | Largely superseded by SPs for EC2 in 2026 |
Situation: The bill had grown ~3× in a year as they scaled, and the whole compute fleet was running at full on-demand rates. Leadership wanted the savings but the cloud lead was fully allocated to product and nobody had the bandwidth to learn Savings Plans, model coverage, or own the ongoing laddering. They were nervous about locking into a 3-year commitment given how fast the architecture was still changing.
What CloudRoute did: Routed in under 24h to a partner with a FinOps / cost-optimization track record. The partner pulled 90 days of CUR data, found the stable compute trough, and right-sized the obviously over-provisioned instances first (~12% off compute before any commitment). Then they laddered a Compute Savings Plan portfolio: ~70% coverage of the right-sized baseline across three 1-year No Upfront tranches a few weeks apart, a small 3-year plan on the always-on control plane, RDS RIs on the steady database fleet, and the variable top slice left on-demand. Engagement qualified for AWS-funded cost-optimization support.
Outcome: Blended compute cost down ~58% vs the pre-engagement on-demand run-rate (right-sizing + Savings Plans combined); coverage steady at ~78% with utilization ~99%; total AWS bill down roughly ~$19K/month. The partner now manages the ladder on a rolling basis. Because the engagement qualified for AWS funding, the optimization work cost the customer $0.
engagement window: ~4 weeks · founder time: ~6 hours · monthly savings: ~$19K · cost to customer: $0
CloudRoute routes you to a vetted AWS partner who sizes, ladders, and manages your Savings Plan portfolio against your real usage. For qualifying engagements the work is AWS-funded — you cut the bill for $0. Otherwise it pays for itself in the savings.