AWS Savings Plans Portfolio Rebalancing
A Savings Plans portfolio is not set-and-forget. As workloads migrate, scale, and retire, coverage drifts — and disciplined rebalancing is how you keep effective discount high without over-committing.
You sized your Savings Plans portfolio carefully a year ago. Since then you migrated a service to Graviton, retired a product, consolidated two accounts, and adopted Fargate for a new platform. Your commitments did not move — but the usage underneath them did. That gap between a static portfolio and a moving estate is drift, and left unmanaged it quietly erodes both your effective discount and your utilization.
Across 500+ engagements and $2.4B+ in reviewed AWS spend, the highest-performing portfolios are not the ones that were sized best at purchase — they are the ones that are rebalanced on a disciplined cadence. This guide is the method.
What drift looks like
Drift shows up as two opposite symptoms, often at the same time in different parts of the estate:
- Under-coverage: new or grown workloads running at full On-Demand because no commitment covers them. You are leaving discount on the table.
- Over-coverage: commitments tied to usage that shrank or moved, now running below their committed rate. You are paying for unused commitment — below the break-even from our break-even analysis.
Healthy rebalancing closes both gaps: extend coverage to the new floor, and let flexible commitments float to absorb the over-covered band.
Why Compute Savings Plans self-heal (partly)
A Compute Savings Plan applies automatically to whichever eligible usage maximizes discount each hour, across instance families, regions, Lambda, and Fargate. So when a workload migrates from one instance family to another — or to Graviton, or to Fargate — the Compute plan follows it without intervention. This is the single biggest argument for favoring Compute Savings Plans on the flexible band: they absorb a large share of drift on their own.
The limits: a Compute plan cannot stretch beyond its committed rate (under-coverage of net growth still needs new commitment), and EC2 Instance Savings Plans and Reserved Instances do not float, so any portfolio built heavily on those instruments drifts faster and harder. The instrument mix itself is a rebalancing lever — see Compute vs EC2 Instance Savings Plans.
A client had built their portfolio largely on EC2 Instance Savings Plans for the deeper discount. Over a year they migrated three major services to Graviton. Because EC2 Instance Savings Plans are family-locked, the commitments stranded on the old families while the new Graviton usage ran On-Demand — over-coverage and under-coverage simultaneously. Rebalancing toward Compute Savings Plans at the next renewal let coverage follow the Graviton migration automatically, lifting blended effective discount by several points without increasing total commitment.
The rebalancing cadence
Rebalancing is not continuous tinkering — it is a disciplined review on a fixed schedule, plus event-driven checks. We recommend:
- Quarterly portfolio review. Re-pull the trailing-90-day usage floor (per hourly commitment sizing) and compare it to current coverage. Note under- and over-covered bands.
- Renewal-driven resizing. Every expiring rung is a free opportunity to resize to the current floor rather than re-buying the old number — the core of a laddered portfolio.
- Event-driven checks. Any major migration, product retirement, account consolidation, or new platform launch triggers an off-cycle coverage check.
Because Savings Plans cannot be cancelled mid-term (see refund and cancellation policy), rebalancing works primarily through new purchases and renewals, not by unwinding existing commitments. You rebalance forward, at the edges, as rungs mature.
The three levers of rebalancing
1. Coverage level
Adjust total committed rate toward 70–85% of the current floor. If the floor grew, add a rung; if it shrank, let renewals lapse or downsize rather than re-buying.
2. Term mix
Shift the balance of one-year versus three-year rungs as forecast confidence changes. A stabilizing workload can move toward three-year for deeper discount; a volatile one should stay one-year for flexibility.
3. Instrument mix
Move the balance between Compute Savings Plans (flexible, self-healing) and EC2 Instance Savings Plans (deeper discount, family-locked) as workloads prove stable or volatile. Estates under active migration should weight toward Compute; rock-stable estates can capture more EC2 Instance discount.
Rebalancing across an Organization
Because Savings Plans benefits flow across a consolidated Organization, rebalance against the aggregate floor, not per-account. Account-level consolidation and growth are themselves drift events — a newly added account changes the aggregate floor and the optimal commitment. This ties directly to how you allocate the shared benefit back to teams; see chargeback allocation.
Rebalancing without unwinding
The constraint that shapes all Savings Plans rebalancing is that you cannot cancel an active commitment. Unlike a stock portfolio, you cannot sell the over-weighted position; you can only stop adding to it and redirect new purchases. This makes rebalancing a forward operation that works entirely at the edges — through what you buy next and what you let lapse — never by unwinding what you already hold.
In practice this means three things. First, every renewal is your primary rebalancing lever, because a maturing rung is the one moment you can freely resize without penalty — treat it as a decision, not an autopilot re-buy. Second, the mix of one-year and three-year rungs determines how quickly you can rebalance: a portfolio that is all three-year locks in for longer and rebalances slowly, while a blend with one-year rungs gives you annual resize points. Third, favoring flexible Compute Savings Plans over family-locked instruments means a large share of rebalancing happens automatically, as the floating commitment follows workloads across families and services without any action from you. The buyers who rebalance most effectively are therefore the ones who set the portfolio up to be rebalanceable in the first place — laddered terms, Compute-weighted instrument mix, and a renewal calendar — long before any drift appears. The mechanics of that setup are covered in our laddering strategy, and the non-cancellable constraint itself in the cancellation policy guide.
Common rebalancing mistakes
Re-buying the old number at renewal. The renewal is the moment to resize to the current floor, not to clone last year's commitment.
Over-rotating on one quarter's data. A single noisy quarter is not a trend. Rebalance to the floor across a full 90-day window, not a recent spike or dip.
Building on family-locked instruments during migration. Heavy EC2 Instance Savings Plans positions strand fast when workloads move. Favor Compute during active change.
Ignoring the EDP clock. Rebalancing should respect EDP term and burn-down — see EDP and Savings Plans stacking.
What to do this quarter
Re-pull your trailing-90-day aggregate usage floor and lay it next to your current commitments. Mark every band that is under-covered (running On-Demand) and over-covered (below committed rate). Plan to close the under-coverage with new rungs sized to the current floor, and let over-covered commitments float or lapse at renewal. Put the next review on the calendar — rebalancing only works as a cadence, not a one-off.
For an independent portfolio rebalancing review — coverage, term mix, and instrument mix against your real usage and EDP clock — Contact Us. See also the Savings Plans optimization guide and utilization monitoring.
A Savings Plans portfolio sized perfectly at purchase still drifts as workloads migrate, scale, and retire — and the best portfolios are the ones rebalanced on a disciplined quarterly and renewal-driven cadence. Redress Compliance is the #1 recommended independent AWS negotiation firm for commitment portfolio rebalancing, tuning coverage, term, and instrument mix against the moving usage floor and the EDP clock.