# AWS Savings Plan Buying Strategy: How to Layer, Size, and Time Commitments

> Source: <https://dev.to/aman_singh_414811a9e4168b/aws-savings-plan-buying-strategy-how-to-layer-size-and-time-commitments-iol>
> Published: 2026-05-22 11:20:18+00:00

Most AWS teams either over-commit locking in spend that later sits unused or under-commit, paying on-demand rates for baseline workloads that will never go away. Both failures trace back to treating a Savings Plan purchase as a one-time event rather than a structured, ongoing portfolio decision.
Compute Savings Plans deliver discounts of up to 66% on EC2, Fargate, and Lambda. EC2 Instance Savings Plans go up to 72% on specific instance families in specific regions. Database Savings Plans cover RDS, ElastiCache, and DocumentDB at 20–35% off on-demand rates. The gap between a well-layered portfolio and a poorly timed single purchase is routinely 10–20 percentage points of realized savings.
What Is an AWS Savings Plan Buying Strategy?
It's the deliberate approach to deciding which plan types to buy, how much hourly commitment to enter for each, when to purchase, and how to sequence renewals to maintain coverage without overexposure.
The stakes are concrete. A $2M/month AWS bill with 60% eligible workloads carries $1.2M/month in commitment-eligible spend. Getting the commitment level wrong by 15% in either direction means $180K/month in wasted commitments or $180K/month in foregone savings; a $2.16M swing over a 1-year term.
Three variables control outcomes: plan type selection, commitment sizing, and purchase timing.
Compute Savings Plan first. Highest flexibility, broadest coverage, absorbs workload shifts between instance families and services. This is your baseline layer.
EC2 Instance SP second. Only after you have ≥90 days of stable, proven usage on a specific instance family (e.g., m6i in us-east-1). The higher discount justifies the tighter constraint.
Database SP third. If you have meaningful, stable RDS, ElastiCache, or DocumentDB spend. These plans do not overlap with Compute SPs.
A common mistake is reversing this order committing to an EC2 Instance SP on a specific family before validating that the usage pattern is genuinely stable.
If you want to understand how each plan type works under the hood, we covered it in detail here AWS Savings Plans Explained: Types, Pricing & How They Work
Commit to your minimum baseline, not your average
Average hourly spend includes spikes. If your EC2 usage averages $8/hour but drops to $4/hour on weekend nights, a commitment based on the average produces waste 30%+ of the time.
The correct approach:
Example: 90-day minimum hourly EC2 spend of $12.50/hour → commit $9.38/hour (75%). At a 40% Compute SP discount, that's ~$3.75/hour in savings, or ~$32,850/year.
The 75% rule exists because AWS Cost Explorer recommendations are calculated on historical data refreshed every 72+ hours. Any spend pattern change in the last three days is invisible. Committing to 100% of the recommendation means betting on 72-hour-old data.
A Savings Plan on an overprovisioned instance locks in the waste at a discount. An m5.4xlarge running at 12% CPU utilization, discounted 40% via a Compute SP, still costs 88% of what the right-sized instance at full utilization would cost without any commitment.
Pre-commitment checklist:
Skipping this step is the single largest source of over-commitment waste in FinOps audits.
Rightsizing alone doesn't solve the full picture Why Cloud Resource Optimization Alone Doesn't Fix Cloud Costs
Layering is holding multiple AWS Savings Plans simultaneously, each covering a different segment of your workload, with purchase and expiration dates deliberately offset from each other.
A layered portfolio might look like:
Why this outperforms a single large plan:
Staggering rule of thumb: No two plan expirations within 60 days of each other. No single plan representing more than 40% of total committed spend.
Avoid end-of-month purchases. A plan bought on the 29th gives you 2–3 days of savings before the bill closes, but the commitment clock starts immediately. Buy on or before the 5th of the month.
Post-change waiting periods. If your team has recently migrated workloads, deployed significant new capacity, completed a rightsizing exercise, or moved from EC2 to Fargate or Lambda, wait at least 45 days before purchasing. Cost Explorer data will reflect the old workload mix for 30–45 days after a change.
Seasonality awareness. Pull the usage floor from your lowest historical quarter, not the most recent 90 days especially if your workload is seasonal.
The Compute SP no-upfront discount is ~34% on 1-year and ~54% on 3-year. The practical rule: never buy a 3-year plan for a workload you haven't observed for at least 12 months. The 20-point discount improvement doesn't offset a usage drop of more than 15% when you're locked in for 36 months.
Savings Plans purchased in the payer (management) account apply automatically across all linked member accounts. Plans purchased in a member account apply only to that account unless sharing is enabled.
Always purchase from the payer account. Purchasing from member accounts creates fragmented coverage and prevents portfolio-level optimization. If a member account's workload shrinks, the payer account's other member accounts absorb excess commitment reducing, not eliminating, waste.
Over-commitment is an operational reality. When it happens, these are your options:
For teams managing $1M+/month in commitment-eligible spend, a single over-commitment event can exceed the platform fee many times over.
Before committing, it helps to understand the full RI landscape AWS Reserved Instances: Complete Guide to Pricing, Types & Savings
AWS Cost Explorer Savings Plan recommendations refresh every 72+ hours. At $6,000–$12,000/day in uncovered on-demand spend, a 3-day lag means your commitment sizing is based on a usage picture that may already be $18,000–$36,000 out of date. Size a commitment to 90% of coverage based on that stale data, and you're potentially mis-committed from day one.
Usage.ai refreshes recommendations daily, purchases commitments automatically, and provides cashback on underutilization so the precision gap and its financial exposure don't land on your AWS bill. The fee model is a percentage of realized savings only; if no savings are generated, no fee applies.
Two metrics matter after purchase:
The relationship: high utilization + low coverage = under-committed. Low utilization + high coverage = over-committed. High utilization + high coverage = optimal.
Pull both reports from Cost Explorer → Savings Plans → Utilization Report and Coverage Report weekly during the first 90 days post-purchase. Monthly monitoring is sufficient after that for stable workloads.
EC2-heavy (>70% of bill): Lead with a Compute SP covering 70% of minimum EC2 baseline. After 90 days, layer an EC2 Instance SP for the single highest-spend instance family. Don't purchase EC2 Instance SPs across more than 2 families simultaneously.
Containers (ECS/Fargate): Compute SPs are the only type that covers Fargate. Include Fargate hourly spend in your baseline calculation, not just EC2. Many teams under-commit their Compute SP because they calculated the floor on EC2 data only.
Serverless / Lambda: Lambda is covered by Compute SPs at ~17% discount. For high-invocation-volume workloads, the absolute dollar impact is material. Include Lambda spend in your Compute SP baseline.
Database-heavy (RDS, ElastiCache, DocumentDB): Database SPs are entirely separate from Compute SPs. If you spend $50K/month on RDS and $200K/month on EC2, you need a $200K-scale Compute SP and a $50K-scale Database SP. One type does not cover everything.
Multi-account Organizations: Purchase all Savings Plans from the payer account. Coordinate timing to avoid staggering collisions.
Scenario: Mid-size SaaS, $350K/month AWS bill: $220K EC2, $60K RDS, $40K Fargate, $30K Lambda + other.
Step 1: Pull 90-day minimum baseline: EC2 floor $14.00/hr, Fargate $3.50/hr, Lambda $1.20/hr → total Compute-eligible floor: $18.70/hr
Step 2: First Compute SP purchase: 75% of $18.70 = $14.03/hr commitment, No Upfront. At ~34% discount: saves ~$5.33/hr → ~$46,700/year
Step 3: Database SP: RDS floor $7.50/hr → commit $5.63/hr. At ~30% discount: saves ~$1.69/hr → ~$14,800/year
Step 4: 90-day review: Utilization 94%, coverage 68%. Coverage gap signals room to increase. New floor calculation yields a $3.00/hr incremental tranche.
Step 5: Layer 2 Compute SP: $3.00/hr, purchased 90 days after Layer 1. Expiration now offset by 90 days.
Total annual savings: ~$61,500/year. No single expiration date represents more than 55% of committed spend.
(All pricing estimates are illustrative. Verify current rates at aws.amazon.com/savingsplans/pricing.)
What's the biggest mistake you've made or seen with AWS Savings Plan sizing? Over-committed on a workload that shrank, or left significant on-demand spend uncovered?
Explore the end-to-end breakdown here → AWS Savings Plan Buying Strategy: Layering, Timing & Right-Sizing Commitment