The AWS commitment trap: why teams lock in 66% discounts on waste instead of savings
The number one mistake in AWS cost optimization isn’t choosing the wrong commitment model. It’s committing at all before you’ve rightsized your workloads. Teams routinely lock in 1- or 3-year commitments to bloated baselines, turning a 66% discount into a 66% discount on waste.
The correct order is right-size first, then layer commitments using a 65-75% savings plan baseline, database-specific RIs, and spot for everything interruptible. This approach typically delivers 50 to 65% overall savings versus a pure on-demand footprint. But skip the rightsizing step, and you’ve signed a long-term contract to overpay for resources you shouldn’t be running.
The catastrophic first move: committing to an unsized baseline
Purchasing Reserved Instances or Savings Plans before establishing 4+ weeks of rightsized production data locks you into paying discounted rates for resources you shouldn’t be running in the first place. Don’t buy any of these models before collecting stable production data for at least a month. Committing too early turns a savings tool into a waste source.
Here’s the problem: Standard Reserved Instances cannot be modified or canceled once purchased, they are only sold on the AWS Marketplace for Standard RIs specifically. Savings Plans can’t be canceled during the term and cannot be sold on the Marketplace if unused. You’re locked in for 1 or 3 years to whatever baseline you committed to on day one.
If that baseline includes oversized EC2 instances, unused database capacity, or workloads that could run on Spot, you’ve just converted temporary inefficiency into contractual obligation. A t3.xlarge running at 15% CPU utilization gets the same 66% Savings Plan discount as a rightsized t3.medium, but you’re still paying 100% more than necessary. The discount applies to the price, not the waste.
The prerequisite all vendors omit: rightsize first, commit second. That means pulling 30 days of production metrics, identifying oversized instances, eliminating zombie resources, and establishing what your actual minimum consistent usage looks like. Only then do you know what floor to commit to.
The correct layering framework: Savings Plans at 65-75% baseline, RIs for databases, Spot for interruptible work
The optimal AWS cost structure is not a single commitment type but a deliberate stack: Compute Savings Plans covering your consistent minimum spend, Reserved Instances for RDS/Aurora/ElastiCache where Savings Plans don’t apply, and Spot for batch jobs and CI/CD.
Target Savings Plan coverage at 65-75% of your stable baseline, leaving 25-35% on-demand for flexibility and growth. That 65-75% figure represents your floor, the amount you are confident you will spend every hour for the next 1 or 3 years. Leave peaks, growth, and variable loads to be covered by On-Demand, which the Savings Plan automatically supplements.
Savings Plans commit to a dollar-per-hour spend, not instance count, and apply automatically across EC2, Fargate, and Lambda. You commit to spending, say, $10/hour across compute resources, and AWS automatically applies the discounted rate to matching usage. No instance-level management, no manual application.
But there’s a critical gap: Savings Plans don’t cover RDS, Aurora, or ElastiCache. Those need reserved instances. For databases, you’re back to committing to specific instance configurations in exchange for discounts. This is where the layered approach matters. Use Savings Plans for the flexible compute layer, RIs for the database layer where Savings Plans don’t apply, and Spot for the interruptible workload layer.
The layered approach typically delivers 50 to 65% overall savings versus a pure on-demand footprint. Not 50-65% off each resource, but a 50-65% reduction in total compute spend when you stack the three commitment types correctly.
Why Savings Plans beat RIs for everything except databases
For compute workloads, Savings Plans deliver equivalent discounts with automatic application across instance families, regions, and services, making them the recommended default over the rigid instance-locking of Reserved Instances.
Compute Savings Plans offer up to 66% off on-demand, similar to Convertible RIs, with automatic coverage of any instance family and across AWS regions. You buy a Compute Savings Plan, and it applies to t3.medium in us-east-1, m5. large in eu-west-1 and c6i.xlarge in ap-southeast-1 without any configuration changes.
EC2 Instance Savings Plans provide up to 72% off on-demand, similar to Standard RIs, with automatic application to any instance size in your chosen family. Commit to the M5 family in us-east-1, and the discount applies to m5.large, m5.xlarge, and m5.2xlarge automatically.
Savings Plans automatically apply to Amazon ECS and Amazon EKS using Fargate and Lambda. Reserved Instances do not. If you’re running containerized workloads on Fargate or serverless functions on Lambda, only Savings Plans will cover that usage. RIs are locked to EC2 instance shapes.
Savings Plans are the recommended default for compute commitments due to their flexibility and low management overhead. RIs require committing to specific instance configurations, including type, size, OS, region, and tenancy. Change your architecture and that RI becomes a stranded commitment.
The exact math: how to calculate your Savings Plan commitment without overcommitting
The correct Savings Plan size is your consistent minimum hourly spend across 30 days of stable usage, not your average or peak. Commit to the floor, let On-Demand absorb variability.
Step one: pull 30 days of On-Demand spend from Cost Explorer filtered to EC2, Fargate, and Lambda only. Not total AWS spend, not including databases or storage, just the services Savings Plans cover.
Step two: identify your consistent minimum dollar-per-hour spend across that period, the floor of your usage, not the average or peak. Look at the lowest sustained hourly spend level over the 30-day window. That’s your commitment level.
Step three: that floor is your savings plan commitment level, the amount you are confident you will spend every hour for the next 1 or 3 years. If your minimum hourly spend is $50/hour and your peak is $200/hour, you commit to $50/hour and let On-Demand cover the $150/hour variance.
Here’s the math for a concrete example: if your monthly On-demand spend across EC2 is $36,500, that’s $50/hour ($36,500 divided by 730 hours). But that’s the average. Your actual minimum might be $35/hour and your peak $80/hour. You commit to $35/hour, leaving the $45/hour difference to On-Demand.
Leave peaks, growth, and variable loads to be covered by On-Demand. The Savings Plan discount only applies up to your commitment level. Spend above that gets billed at On-Demand rates, but you’re not locked into paying for capacity you might not need. Target coverage of 65-75% of stable baseline; keep 25-35% On-Demand for flexibility and growth.
When Reserved Instances still win: RDS, capacity reservations, and the Marketplace edge case
Reserved Instances remain necessary for RDS/Aurora/ElastiCache which Savings Plans don’t cover, when you need guaranteed capacity, and when you want the ability to resell unused Standard RIs on the AWS Marketplace.
Savings Plans don’t cover RDS, Aurora, or ElastiCache. Those need RIs. This is the most important gap in the Savings Plans model. If you’re running production databases, you’re buying Reserved Instances, whether you like it or not. RIs are available for EC2, RDS, ElastiCache, Redshift, OpenSearch, and DynamoDB, while Savings Plans exclude databases entirely.
Savings Plans do not provide a capacity reservation. If you need guaranteed capacity in a specific availability zone for compliance or disaster recovery requirements, you have two options: purchase Reserved Instances, which include capacity reservation, or use On-Demand Capacity Reservations with Savings Plans. The latter gives you Savings Plan flexibility with capacityguarantees butt requires managing two separate mechanisms.
Unused RIs can be sold on the AWS Marketplace for Standard RIs only. Savings Plans cannot be sold on the Marketplace if unused. If you over-commit on a Standard RI, you can list it on the AWS Reserved Instance Marketplace and recoup some of your investment. Over-commit on a Savings Plan, and you’re stuck paying for unused commitment for the full term. This creates a small risk premium favoring RIs for workloads where commitment level uncertainty is high.
Standard RIs offer up to 72% discount with the highest discount ceiling at approximately 75% for completely static workloads with 3-year all-upfront payment. That’s 6-9 percentage points deeper than Compute Savings Plans’ 66% maximum. For a truly static database workload that won’t change instance family, region, or configuration for three years, that 6-9% premium justifies the inflexibility.
The Spot layer: 90% discounts for batch, CI/CD, and fault-tolerant workloads
Spot Instances deliver deeper savings than any commitment model and should handle all interruptible workloads: batch processing, CI/CD pipelines, and stateless services with 2-minute interruption tolerance.
Spot offers up to 90% off versus Savings Plans’ 66% and RIs’ 72% maximum. No other AWS pricing model approaches 90% discount. The trade-off is a 2-minute interruption notice, the only constraint. AWS can reclaim Spot capacity with two minutes of warning when demand for On-Demand instances increases.
That 2-minute window is suitable for batch and CI/CD workloads. Data processing jobs that checkpoint progress every 60 seconds, CI/CD build agents that can restart builds, stateless web services behind load balancers that can drain connections and shift traffic. Route all interruptible workloads to Spot.
Spot provides the deepest savings but requires architectural tolerance for interruption. You can’t run your primary production database on Spot. You can run the nightly ETL job that processes yesterday’s transactions. You can’t run your always-on API gateway on Spot. You can run the test environment that’s only needed during business hours.
Used for interruption-tolerant jobs and fault-tolerant scaling, Spot completes the layered stack. Savings Plans cover the baseline, database RIs cover persistent data stores, and Spot covers everything that can tolerate interruption in exchange for 90% discount.
Counterargument: Why not choose Standard RIs for the deeper 72% discount?
Standard Reserved Instances offer up to 72% savings compared to Compute Savings Plans’ 66% maximum. Why not choose the deeper discount?
The 6% theoretical discount advantage of Standard RIs evaporates in practice because they lock you to a specific instance family, size, region, OS, and tenancy. When your architecture evolves—instance generation upgrades, region expansion, containerization—that locked-in Standard RI becomes stranded commitment paying for unused capacity.
Here’s the real-world scenario: you purchase Standard RIs for m5.xlarge instances in us-east-1 running Amazon Linux at a 72% discount with a 3-year commitment. Eighteen months in, AWS releases the m6i generation with 15% better price-performance. Your architecture team wants to migrate. Your Standard RI is locked to the M5 family. You can’t convert it, can’t modify the instance family, and can’t apply it to m6i. You’re paying the RI rate for m5.xlarge capacity you’re no longer using while paying On-Demand rates for the new m6i.xlarge instances you actually need.
Compute Savings Plans deliver the same 66% as Convertible RIs while automatically applying to any instance family and across AWS Regions. The flexibility premium is worth 6% when it prevents commitment waste. You migrate from m5 to m6i, the Savings Plan automatically applies to the new instance family. You expand from us-east-1 to eu-west-1, the Savings Plan automatically applies to the new region. You containerize workloads and move to Fargate, the Savings Plan automatically applies to Fargate compute.
Use the 72% Standard RI discount only for RDS and other database workloads where Savings Plans don’t apply and configurations remain truly static for 1-3 years. Production PostgreSQL on RDS running db.m5.xlarge in us-east-1 for customer transaction data is a valid Standard RI target. It won’t change instance family, won’t change region, won’t change database engine for years. Lock that in at 72% and extract the full discount.
For everything else, the architectural evolution risk of Standard RIs outweighs the 6% discount advantage. Modern infrastructure changes faster than 3-year RI terms.
The commitment decision is not which model to choose, it’s whether you’ve rightsized first
The reserved instances versus savings plans decision is a false choice. The real decision is whether you’ve rightsized first and whether you’re layering all three commitment types correctly.
Skip the rightsizing step and you’ve simply locked in a long-term contract to overpay for resources you don’t need. A 66% discount on an oversized m5.2xlarge costs more than On-Demand rates on a rightsized m5.large. Discounted waste is still waste.
Layer correctly—65-75% Savings Plan baseline, database RIs, Spot for interruptible work—and you convert AWS commitment models from vendor lock-in into a 50-65% cost reduction engine. Miss one layer and you leave money on the table. Commit before rightsizing and you lock in the wrong baseline for 1-3 years.
The commitment decision happens after you know what your minimum consistent usage actually is. Not what you think it is, not what it was last quarter, but what 30 days of post-rightsizing production data shows it to be. That floor becomes your Savings Plan commitment. Everything interruptible goes to Spot at 90% discount. Databases get RIs because Savings Plans don’t cover them. On-Demand fills the 25-35% flexibility buffer for peaks and growth.
Get the order right, and AWS commitment models work exactly as advertised: significant discounts in exchange for usage commitment. Get the order wrong, and you’ve traded flexibility for discounted waste.
