Committing to AWS in exchange for a discount is one of the biggest cost levers you have, and it is also where people freeze, because there are two mechanisms (Savings Plans and Reserved Instances), several flavors of each, and a real risk of locking in the wrong thing for a year. Here is the practical version: what each one is, and the simple rules we use to decide, without the analysis paralysis.
The core idea behind both
On-demand pricing is the flexible, expensive default. Both Savings Plans and Reserved Instances give you a discount (often 30 to 70%) in exchange for committing to a level of usage for 1 or 3 years. The difference is what you commit to.
Reserved Instances: commit to specific capacity
An RI is a commitment to a specific instance configuration: instance family, region, and (for standard RIs) more or less locked-in attributes, for a 1 or 3 year term.
- Standard RIs: biggest discount, least flexible. You are largely committing to a specific family in a region.
- Convertible RIs: smaller discount, but you can exchange them for different families later.
RIs also can provide a capacity reservation, guaranteeing you can launch that instance in that AZ, which matters if you need guaranteed capacity.
Savings Plans: commit to spend, not capacity
A Savings Plan is a commitment to spend a certain dollar amount per hour (say $10/hour) for 1 or 3 years, and AWS applies the discount to your usage up to that amount.
- Compute Savings Plans: the most flexible. The discount applies across instance families, regions, operating systems, and even Fargate and Lambda. Smaller discount than the most locked-in RI, but it follows your usage as it changes.
- EC2 Instance Savings Plans: commit to a specific instance family in a region for a bigger discount, less flexible than Compute SP but more flexible than a standard RI within that family.
The rules we actually use
Here is the decision framework, in order:
1. Rightsize before you commit. Always. Never buy a commitment for an oversized instance, you will lock in the waste for a year. Rightsize first, then commit to the correct baseline. This is the mistake that turns a cost-saving into a cost-trap.
2. Cover your steady baseline, not your peak. Commit only to the usage you are confident will run the whole term, the always-on floor. Leave burst and uncertain workloads on on-demand (or spot). Over-committing is worse than under-committing, because unused commitment is pure waste.
3. Default to Compute Savings Plans for flexibility. For most teams, a Compute Savings Plan is the right default. It gives a strong discount and follows you across families, regions, Fargate, and Lambda as your architecture changes, which it will. You trade a few points of discount for not being locked to a family you might migrate off.
4. Use EC2 Instance Savings Plans or Standard RIs for stable, known workloads. If you have a large, stable workload you are certain will stay on a specific family (a fixed production fleet), the bigger discount of an EC2 Instance SP or Standard RI is worth the reduced flexibility.
5. Start with 1-year, no-upfront until you trust the number. A 3-year all-upfront commitment is the biggest discount and the biggest risk. Until you are confident in your baseline, a 1-year no-upfront plan captures most of the savings with far less lock-in. Ladder into longer terms as your confidence grows.
6. Remember RIs are the only option for some services. Savings Plans cover EC2, Fargate, and Lambda. But RDS, ElastiCache, Redshift, and OpenSearch still use Reserved Instances (or reserved nodes), not Savings Plans. So a full commitment strategy usually means Compute Savings Plans for compute plus RIs for your managed databases and data services.
Putting it together
A typical sensible setup:
- Compute Savings Plan covering the steady EC2/Fargate/Lambda baseline.
- Reserved Instances for the production RDS and ElastiCache baseline (no SP option there).
- On-demand for burst and anything uncertain.
- Spot for interruptible workloads.
- All of it sized after rightsizing, and reviewed as usage changes, because commitments should track reality, not a snapshot from a year ago.
Cost Explorer will generate Savings Plans and RI recommendations from your usage history, which is a fine starting point, but run them through the rules above rather than buying what it suggests blindly. (Continuous tooling can track commitment utilization and coverage for you over time, which is part of what platforms like ZopNight do, but the decision logic is what matters.)
The take
Savings Plans commit to spend and flex across your usage; Reserved Instances commit to specific capacity for a bigger discount. Rightsize first, cover only the baseline, default to Compute Savings Plans for flexibility, use RIs where they are the only option (managed databases) or for very stable fleets, and start short until you trust your numbers. Do that and commitments become the biggest safe discount you have, instead of a year-long bet you regret.
How do you split your commitments, mostly Savings Plans, mostly RIs, or a layer of both? And has an over-commitment ever burned you? Mine was a family I committed to right before we migrated off it, a lesson in rule number one.
Top comments (0)