The Savings Plans Commitment Calculator: A Sizing Methodology

The most expensive mistake in Savings Plans portfolio management is sizing the commitment wrong. Overcommit and you carry unused capacity for the entire term; undercommit and you leave the deeper discount on the table on a usage baseline that was always going to be there. The AWS Cost Explorer recommendation tool helps but is not the right calculator — it optimizes against historical usage rather than forecasted reality, and it rarely accounts for the layering structure that mature buyers use.

This guide walks through the sizing methodology we use across 500+ engagements and $2.4B+ in reviewed AWS spend. It is not a single formula; it is a sequence of decisions grounded in data, with explicit sensitivity testing and a layered output.

What the right calculator produces

The output of a proper Savings Plans sizing exercise is not "buy a $X/hour Compute Savings Plan." It is a layered commitment structure with three components:

• A long-term baseline layer (3-year commitment) sized against the irreducible floor of expected usage.
• A medium-term flexibility layer (1-year commitment) sized against probable usage above the baseline.
• An uncovered elastic layer remaining on On-Demand or Spot.

Plus a renewal posture for any expiring Savings Plans, and an explicit position on EC2 Instance Savings Plans for workloads that pass the family/region stability tests.

The total committed dollars is just the sum of those layers. The structure matters more than the total.

The five-step methodology

Step 1: Pull 90 days of hourly compute usage

The right data source is Cost & Usage Reports at hourly granularity, filtered to Savings-Plans-eligible categories: EC2 On-Demand, Fargate, Lambda, and (separately for the SageMaker calculator) SageMaker compute.

The right window is 90 days for general purposes. Shorter windows (30 days) underweight monthly cycles. Longer windows (180 days) introduce stale data that no longer reflects current architecture. 90 days is the operational sweet spot.

Pull the data with the existing RI and Savings Plans coverage removed — what would the spend look like if everything were on On-Demand? This is the gross baseline; layered discounts will be applied later.

Step 2: Plot the hourly usage histogram

For each hour in the 90-day window, calculate total Savings-Plans-eligible spend at On-Demand rates. Plot the distribution.

The shape tells you the workload character:

• Tight distribution (narrow histogram): Steady-state workload. The 25th and 75th percentiles are close. Savings Plans coverage can run high — 85–90% of expected baseline.
• Wide distribution (broad histogram): Bursty workload. Large gap between 25th and 75th percentile. Savings Plans coverage should target the 25th percentile aggressively but leave significant elastic capacity uncommitted.
• Bimodal distribution: Workload with discrete states — e.g., batch processing periods. The 25th percentile is the baseline; the second mode reflects scheduled bursts.

Step 3: Identify the stable baseline (25th percentile hour)

The 25th percentile hour is the level of usage that is essentially always present. This is the irreducible floor — the part of the workload that runs around the clock regardless of business cycles.

For most enterprise AWS estates, the 25th percentile sits at 60–75% of average usage. The gap between average and 25th percentile reflects the elastic component of the workload.

Step 4: Project the baseline trajectory

The 25th percentile from historical data is the baseline today. The commitment runs forward, so the relevant baseline is the forward 25th percentile. Project forward across the commitment term, accounting for:

• Growth. Typically the dominant factor. Use the trailing 12-month growth rate as a starting point; adjust for known business changes.
• Architectural changes. Graviton migration reduces compute cost (typically 20–40% per workload migrated). EKS adoption changes service mix. Lambda growth pulls compute off EC2.
• Migration cadence. Workloads coming into AWS from on-premises or another cloud. Workloads leaving AWS for any reason.
• Business events. M&A activity, product launches, divestitures, expected business cycles.

The output is a baseline trajectory — month-by-month for the first year, quarterly for years 2–3.

Step 5: Run the sensitivity scenarios

Run three scenarios:

• Base case. Mid-point forecast.
• Growth-down case. 20–25% below base case — slower growth, faster Graviton migration, less new workload migration, more workload leaving AWS.
• Growth-up case. 20–25% above base case — faster growth, slower architectural change, more new workload migration.

Size the long-term Savings Plans commitment against the growth-down case, not the base case. The cost of unused commitment is higher than the cost of additional On-Demand spend at the margin — overcommitment risk is asymmetric.

The medium-term layer absorbs the gap between growth-down and base case.

The layering output

With the trajectory and scenarios in hand, build the layered commitment structure:

For a $5M annual compute spend with a typical baseline distribution, this might decompose into:

• ~$2.5M as 3-year Compute Savings Plans (long-term baseline at growth-down).
• ~$1.0M as 1-year Compute Savings Plans (medium-term layer).
• ~$1.5M remaining on On-Demand or Spot.

Effective blended discount on this structure typically lands at 32–38% against the On-Demand baseline.

What the AWS recommendation tool gets wrong

AWS Cost Explorer includes a Savings Plans recommendation tool. It is useful as a starting reference but consistently produces sizing that diverges from the layered methodology above:

• It defaults to "lookback period" sizing. The default 7-day lookback overweights very recent usage; the 30-day option is better but still backward-looking.
• It recommends a single commitment level, not a layered structure. The output is "buy $X/hour" — no separation of long-term and medium-term layers.
• It does not account for forecasted architectural change. Graviton migrations, EKS adoption, planned region changes — none of these are in the model.
• It does not run sensitivity scenarios. The output is a single number, not a structured analysis of overcommitment risk.
• It optimizes for total savings, not risk-adjusted savings. The recommendation maximizes expected discount; the right number balances discount against overcommitment risk.

Use the AWS recommendation as a sanity check. If your independent sizing is dramatically different (more than 20% apart), investigate why; one of you is wrong.

The renewal calculator

The same methodology applies to renewing expiring Savings Plans, with one adjustment: the historical data should be analyzed without the expiring plan's coverage included, to reveal the gross baseline.

Otherwise the methodology is identical: 90-day hourly usage, 25th percentile baseline, growth-down sensitivity, layered structure.

One additional consideration: at renewal, re-evaluate the EC2 Instance Savings Plans question. Workloads that have stabilized into specific families/regions may now support an EC2 Instance Savings Plans layer that wasn't justified at original purchase.

The multi-account aggregation question

For buyers running multiple AWS accounts under an Organization, the question is whether to size the commitment against the consolidated Organization total or against individual account baselines.

The right answer is consolidated, in nearly all cases. Savings Plans benefits flow across accounts by default through consolidated billing, so the relevant baseline is the Organization total, not individual accounts.

Exception: accounts where sharing has been explicitly disabled for chargeback or compliance reasons. In those cases, size the commitment against the account total. But disabling sharing is rarely the right structure — the discount loss usually outweighs the chargeback simplicity.

The EDP interaction

For buyers on an Enterprise Discount Programme, Savings Plans commitments count toward EDP commit. If EDP under-burn is a risk, Savings Plans purchases can absorb commitment.

But sizing Savings Plans to manage EDP under-burn alone is commercially distorting. The Savings Plans absorb the EDP commitment today and create their own commitment liability tomorrow — if the Savings Plans coverage exceeds real consumption baseline, the buyer trades one overcommitment for another.

The right structure: size Savings Plans against actual baseline first; address EDP under-burn through other levers (architectural change, additional workloads, EDP restructuring) before turning to incremental Savings Plans.

Common sizing errors

Five errors we see repeatedly:

• Sizing against average usage. Average is between the 25th and 75th percentile; sizing here guarantees overcommitment in the elastic-down hours and undercommitment in the elastic-up hours.
• Sizing without forward forecast. Historical 25th percentile is not the forward 25th percentile. Growth, architecture change, and migrations all shift the baseline.
• Sizing the single largest commitment possible. A single-bullet commitment is harder to adjust than a layered set. Layering reduces risk at minimal discount cost.
• Sizing without accounting for existing commitments. RIs and existing Savings Plans already cover part of the baseline. The incremental purchase should be sized against the uncovered portion.
• Sizing against EDP under-burn. Discussed above — operationally tempting, commercially distorting.

What to do this quarter

Run the five-step sizing calculator against your current portfolio. If you have any Savings Plan expiring in the next 12 months, run the methodology against the renewal. If you don't have hourly usage data, prioritize extracting it from Cost & Usage Reports — operating without that visibility consistently produces wrong-sized commitments.

If you would like an independent sizing analysis run against your current and forecasted AWS spend, Contact Us. We will produce a layered structure with explicit sensitivity scenarios within 1–2 weeks. For deeper reading, see our pillar guide on AWS Savings Plans strategy, the coverage target analysis, and the 1-year vs 3-year decision framework.