Savings Plans

TL;DR: Savings Plans (2019) deliver RI-level discounts — up to 72% off — but instead of matching specific instances, you commit to a fixed $/hour of compute for 1 or 3 years and AWS applies it automatically across EC2, Lambda, and Fargate. Two flavors: Compute SP (~66%, any family/region/service — the flexible default) and EC2 Instance SP (~72%, locked to a family + region). For most modern, evolving workloads Savings Plans are the better default over Reserved Instances — near-identical discounts, far simpler management.

The numbers

• Compute SP ~66% (EC2 + Lambda + Fargate, any family/region/OS — the discount follows workloads across migrations); EC2 Instance SP ~72% (family + region locked, size/OS/tenancy flexible).
• Use-it-or-lose-it hourly commit — under-use the committed $/hour and you still pay it; AWS auto-applies the plan to your most expensive eligible usage first.
• Payment: All Upfront (deepest) / Partial / No Upfront; 3-year deepest, 1-year lower-risk on-ramp.
• Sizing recipe: commit 70–80% of your consistent hourly baseline (the lowest hourly spend you always maintain), leaving headroom for variability.
• Field examples: a multi-service startup's $25/hr Compute SP followed compute across an EC2→Lambda migration for ~$65K/yr; an 18-month enterprise migration started at $50/hr and layered on $30/hr more once patterns stabilized — incremental beats one big bet.

Do this

1. Use Cost Explorer's Savings Plans Recommendations (or Compute Optimizer) — it computes the commitment for maximum ROI with projected savings.
2. Find your baseline in 6–12 months of hourly spend and commit to 70–80% of it — never 100%; leave room for growth and experimentation.
3. Pick the flavor by architectural stability — Compute SP if you experiment/migrate/multi-region even occasionally (the 6-point gap is cheap insurance); EC2 Instance SP only where the family+region is genuinely fixed.
4. Start conservative and queue future purchases — you can buy more later (queue a plan to activate at a planned scale-up) but can't unwind one early.
5. Monitor utilization — consistently 100% means under-committed (buy more); below ~70% means over-committed (adjust future buys).

Gotchas

• No refunds, no early exit — over-committing is the expensive mistake; conservative-then-layer is the safe path.
• Doesn't cover Spot — Spot is already cheaper than any SP discount, so exclude Spot usage from the commitment math.
• Doesn't cover RDS (RDS RIs are separate) — SPs are compute-plane only.
• It's an hourly commit — even an hour of zero compute still bills the commitment; the baseline must justify the level.

Skip this if

• Usage is wildly unpredictable (under ~50% consistent baseline), the project is short-term (under 6 months), or you're already a heavy Spot user — lean on Spot Instances, EC2 Instance Scheduling, and aggressive Auto Scaling Groups instead.
• You need guaranteed capacity reservation or the deepest discount on one specific instance type — see Reserved Instances (and EC2 Instance Savings Plans for the family-locked 72% variant). Stack any Savings Plan on top of Spot for compounding savings.