Why this matters
AWS sells two main commitment discounts: Savings Plans and Reserved Instances. A Savings Plan is a promise to spend a set amount per hour for one or three years. A Reserved Instance ties a discount to a service and instance attributes, and a zonal RI also reserves capacity. Unused commitment is still billed.
Overcommitment rarely comes from a bad price. It comes from sizing to average usage, peak usage, or a workload that is about to change. A migration, a container move, or an instance family refresh can leave you paying for a commitment you no longer use.
Treat commitments as a floor, not a forecast. Cover the usage that stays steady in your slowest normal week, keep the rest on demand, and add more in small steps as the floor proves stable.
Before you start
Pull 60 to 90 days of usage at hourly granularity. In Cost Explorer, open the Savings Plans purchase recommendations and RI recommendations, but do not buy from the summary. Export the Cost and Usage Report to S3 and query it if you need the lowest normal hour, not the average. Filter to eligible services: EC2, Fargate, and Lambda for Savings Plans, and each service's own reserved offering for RIs.
Map the billing structure. Confirm the AWS Organizations payer, linked accounts, and whether Reserved Instance and Savings Plans discount sharing is on in Billing preferences. Find every active commitment, its term, payment option, scope, expiration date, and current utilization. A new purchase should fill the gap after existing commitments, not add to usage you already covered.
Separate stable from variable workloads with tags or Cost Categories. Mark production steady state, batch, sandbox, seasonal peaks, and known migrations. Exclude any workload with a planned change inside the term, such as a region move, database upgrade, or move to containers. Get finance to agree on term length, payment option, approval steps, and who reviews utilization each month.
How to do it
Run the purchase analyzer as a model, then override it. AWS recommendations assume recent usage continues. Your job is to remove hours that will not continue. Model a no upfront, one year term first, because it keeps cash free and limits the damage if the workload changes.
Buy in tranches. A single large commitment is hard to correct; several smaller ones let you adjust as you learn. The steps below turn that into a repeatable process.
- Find the hourly floor. Export the Cost and Usage Report and group eligible usage by hour. Find the lowest normal hour after removing outages, launches, and one-off batch runs. That number, not the monthly average, is your starting commitment.
- Separate stable workloads. Use tags and Cost Categories to label steady production, batch, sandbox, and migration candidates. Leave out any workload with a planned change inside the commitment term. A commitment should follow usage you can defend on a quiet week.
- Net out existing commitments. List active Savings Plans and RIs with term, expiry, scope, and utilization. Subtract the usage they already cover before you size a new purchase. Buying against total usage instead of uncovered usage is a common way to double cover.
- Prefer Compute Savings Plans. Use Compute Savings Plans for EC2, Fargate, and Lambda unless you need reserved capacity or a scoped discount. They follow usage across regions, instance families, operating systems, and tenancy. That flexibility is worth more than a deeper discount when your architecture is still moving.
- Set a conservative commitment. Take the analyzer number and reduce it to your floor. Leave room for the next instance refresh, normal weekly dips, and a small error. You can add another commitment later; you cannot easily shrink a bad one.
- Match term to confidence. Start with a one year, no upfront plan for workloads new to commitments. Use a three year term only for services with a named owner, steady usage, and no migration plan. The payment option changes cash flow, so treat all upfront as a finance decision, not just a discount decision.
- Ladder and stagger expiries. Buy in smaller tranches over several weeks instead of one large purchase. Spread end dates across quarters so renewals do not all land at once. This keeps you from being forced to renew a block that no longer fits.
- Use RIs for specific services. Buy zonal EC2 RIs only when you need capacity reservation in an Availability Zone. For RDS, ElastiCache, Redshift, OpenSearch, and DynamoDB, use the service's own reserved offering because Savings Plans do not cover them. Check instance attributes carefully before you buy.
- Write it down and set alerts. Record the owner, term, scope, and review date for each commitment. Create AWS Budgets alerts for Savings Plans utilization and coverage, and put expiries on the team calendar. A commitment without a calendar entry becomes a surprise.
How to check it worked
Review utilization and coverage separately. Utilization shows how much of the commitment you used; coverage shows how much eligible usage the commitment covers. High coverage with falling utilization means you bought too much. High utilization with low coverage means you may still have room to buy, but only up to the floor.
Use the Savings Plans utilization and coverage reports in Cost Explorer, and the RI utilization and coverage reports for each service. In Billing and Cost Management, check for unused commitment charges during low usage hours. Set AWS Budgets alerts on Savings Plans utilization and coverage so a drop reaches someone before the next purchase.
Compare amortized cost by account and service before and after the purchase. Confirm discounts land where you expect, especially if RI or Savings Plans discount sharing is off for an account. For zonal RIs, check that the reservation matches the instance's Availability Zone, platform, tenancy, and size. An unused zonal RI is worse than no RI.
Mistakes to avoid
Sizing to peak is the classic error. If the commitment covers your busiest hour, you pay for unused capacity most of the day. Sizing from one month is the second error; a launch, batch job, or migration can make that month look stable when it is not.
Do not put a three year term on a workload that is still moving. Container adoption, a database upgrade, or a region change can break the match. Convertible RIs allow exchanges, but only within their rules and not for every service. Read the exchange terms before you treat them as a safety net.
Do not ignore account scope. Savings Plans apply across the consolidated billing family; RIs may be shared only when discount sharing is on. A purchase in one account can change costs in another, so agree who owns the decision and who reviews it.
Do not assume Savings Plans cover every service. They do not cover RDS, ElastiCache, Redshift, OpenSearch, or DynamoDB. Those need their own reserved capacity or RIs. If you want an independent read before you commit, the Cloud cost audit from Cloudverg is a two-week, read-only review at a fixed price of $4,500 that includes a commitment plan for Savings Plans, Reserved Instances, or committed use. It is one option among others.
Frequently asked questions
Do AWS Savings Plans cover RDS and ElastiCache?
No. Compute Savings Plans cover EC2, Fargate, and Lambda. RDS, ElastiCache, Redshift, OpenSearch, and DynamoDB have their own reserved offerings. Buy those separately and match the attributes carefully.
Should I buy a one year or three year AWS Savings Plan?
Start with one year when the workload is new to commitments or likely to change. A three year term fits a service with steady usage, a clear owner, and no migration plan. The longer term usually gives a larger discount, but it also raises the cost of being wrong.
What happens if I do not use my AWS commitment?
You still pay the committed amount. For Savings Plans, the unused hourly commitment is charged even when eligible usage is lower. Watch utilization reports and keep the commitment at a floor you can use in a slow week.