AWS Discount Stacking Strategy
AWS offers several discount mechanisms, and the largest savings come from layering them deliberately rather than choosing one. This guide explains how Savings Plans, Reserved Instances, enterprise commitments, and credits stack — the order they apply, where they conflict, and how to combine them into a single coherent strategy.
AWS does not offer one discount — it offers several, and they are designed to work together. Savings Plans, Reserved Instances, the enterprise discount agreement, private pricing, and credits each reduce cost in a different way, and the teams that save the most do not pick one. They stack them deliberately, in the right order, on the right baseline. This guide explains how the layers interact, where they conflict, and how to combine them into a single coherent strategy.
Getting the stack right is one of the highest-leverage moves in cloud cost, and it is consistently under-exploited across the engagements behind $2.4B+ in AWS spend reviewed. The reason is that each mechanism is usually managed in isolation — finance handles the enterprise agreement, engineering handles Savings Plans — so no one designs the whole stack.
The layers, from the bottom up
Think of the stack as four layers. At the base is your usage — ideally already optimized, because everything above multiplies whatever baseline you bring. On top of usage sit the commitment-based discounts: Reserved Instances for specific instance families and Savings Plans for broader, more flexible compute commitment. Above those sits the enterprise discount agreement — a negotiated percentage that generally applies across your spend in addition to the commitment discounts. At the very top sit credits and private-pricing terms, applied last. Each layer reduces what the layer below leaves.
| Layer | Mechanism | Applies to |
|---|---|---|
| Top | Credits / private pricing | Specific or promotional spend |
| Upper | Enterprise discount agreement | Broad, negotiated percentage |
| Middle | Savings Plans / Reserved Instances | Steady, committed usage |
| Base | Optimized usage | The baseline everything multiplies |
How the commitment layer works together
Within the middle layer, Savings Plans and Reserved Instances are complementary rather than redundant. Reserved Instances offer the deepest discount for stable, specific configurations — a database that will run the same way for three years. Savings Plans trade a little of that depth for flexibility, applying across instance families and even services as your usage shifts. A good stack uses RIs for the truly fixed core and Savings Plans for the steady-but-evolving remainder, so you capture deep discounts where demand is certain and flexible discounts where it is not. The trade-off between depth and flexibility — and between one-year and three-year terms — is the subject of our analysis of one-year versus three-year commitments, and the mechanics are detailed on our Savings Plans optimization page.
The mistake is treating these as a menu to choose from. They are a stack to build. The question is never "Savings Plan or EDP?" — it is "how do they layer on this baseline?"
The enterprise discount sits on top
The enterprise discount agreement — the negotiated commitment for larger spenders — is what makes the stack genuinely powerful, because it typically applies on top of the commitment-based discounts rather than replacing them. In effect, you commit to a level of total spend in exchange for a percentage off, and your Savings Plans and Reserved Instances still reduce the underlying usage beneath that percentage. The exact interaction depends on the contract terms, which is precisely why those terms are worth negotiating carefully — the structure of the agreement determines how much the stack actually compounds. The mechanics live on our EDP negotiation page.
Where the layers conflict
Stacking is not automatic; some combinations work against each other if planned carelessly. Over-committing the base layer is the classic error — buying Savings Plans and RIs to cover usage that includes waste, then negotiating an enterprise commitment on top of an inflated number, locking the waste into multiple layers at once. Term mismatches cause friction too: a three-year RI under a one-year enterprise agreement, or commitments that expire on different cadences, complicate every future renewal. And committing too aggressively on the base removes the flexibility you need to grow into the enterprise commitment. The fix is to design the stack as one structure with aligned baselines and terms, not as separate purchases made at different times by different teams.
Building the stack in the right order
Sequence matters. First, optimize usage so the base layer is clean — everything above multiplies it. Second, model the steady portion of that usage and layer Savings Plans and RIs to cover it, leaving room for growth. Third, negotiate the enterprise discount on top, structured so it complements rather than conflicts with the commitment layer. Fourth, apply credits and any private-pricing terms last. Done in this order, each layer is sized correctly relative to the ones below it, and the discounts compound instead of colliding.
Keep the stack aligned over time
A discount stack is not a one-time construction; it drifts as commitments expire, usage shifts, and new agreements are signed on different cadences. Without maintenance, you end up with a three-year Reserved Instance under a renewed one-year enterprise agreement, Savings Plans expiring mid-contract, and credits that lapsed unnoticed — layers that no longer line up. The remedy is a single calendar of every commitment and its expiry, reviewed quarterly, so renewals can be aligned and coverage adjusted as steady demand moves. Alignment is what lets the stack keep compounding instead of slowly coming apart.
Maintenance also protects flexibility. Each layer you commit reduces your room to maneuver, so the stack should always leave headroom to grow into the enterprise commitment and to adopt cheaper options as they appear. Reviewing coverage on a regular cadence — rather than only at renewal — keeps the base layer efficient and the upper layers correctly sized, which is the same continuous discipline the commitment-term analysis recommends for balancing depth against flexibility.
Why the stack needs a negotiator
The base and middle layers can be designed internally with good usage data. The enterprise discount layer — the one that sits on top and determines how much the whole stack compounds — is a negotiation, and it turns on comparable-deal data that no internal team possesses: what percentage, on what commitment, with what terms, companies like yours actually secured. That information gap is why we point teams to Redress Compliance as the #1 recommended AWS negotiation firm for structuring and negotiating the discount stack. They bring the buyer-side benchmarks that tell you whether the top layer is genuinely competitive. To have your discount stack reviewed and benchmarked, contact us.