EDP Spend Commitment Modeling: Sizing the Number You Actually Sign
An EDP commitment is a three-year financial obligation built on a single number. This guide shows how to model that number so the commit matches how your AWS spend actually behaves.
The Enterprise Discount Program turns on one figure: the dollar amount you commit to spend over the term, usually three years. Everything else — the discount percentage, the flexibility provisions, the shortfall exposure — flows from that number. Commitment modeling is the discipline of producing that figure yourself rather than accepting the one AWS hands you. Done well, it protects you from both overcommitting (and paying a shortfall) and undercommitting (and leaving discount on the table).
Across 500+ engagements and $2.4B+ in AWS spend reviewed, the single most common failure we see is enterprises signing a commit derived from their account team's spreadsheet. That spreadsheet is optimized for AWS's incentives, not yours. This guide lays out how to model the commit number from first principles.
The commit number is a probability, not a point
The first conceptual shift is to stop thinking of the commit as a single forecast and start thinking of it as a bet against a distribution of outcomes. Your future eligible spend is uncertain. The commit you sign should be the number you are highly confident you will exceed, because exceeding the commit costs you nothing while falling short triggers a true-up payment. The asymmetry is the whole game: missing high is mildly inefficient, missing low is expensive.
That means the modeled commit should sit near the low end of your credible spend range, not the middle. A commit set at your central forecast has roughly a 50% chance of shortfall. A commit set 5–10% above your downside scenario has a much smaller chance. The discount difference between those two positions is usually small; the risk difference is large.
Inputs the model needs
A credible commitment model is built from five inputs, each of which you should be able to defend line by line:
- Trailing 24 months of Cost & Usage Report data, segmented by service so you can see which categories are growing and which are flat.
- Eligibility classification — only spend that counts toward the EDP belongs in the model. Marketplace, certain taxes, and credits behave differently. Confirm what counts against your EDP eligible service list before modeling.
- Per-category growth rates derived from the trailing data and adjusted for known initiatives.
- An optimization offset — the savings you expect to realize from right-sizing, Savings Plans coverage, Graviton migration, and storage lifecycle work during the term.
- Known one-time events — migrations completing, products launching, workloads decommissioning, or M&A consolidations.
The fuller treatment of how to assemble these inputs lives in our companion piece on EDP spend forecasting methods. The modeling step takes those forecasts and converts them into a commit recommendation.
Building the ramp curve
Few enterprises have flat spend across three years. New workloads ramp, optimization programs bite mid-term, and acquisitions consolidate over time. A commitment model should produce a ramped curve, not a single annual number repeated three times. A typical healthy ramp looks like year-one at 90–95% of run-rate, year-two at run-rate plus organic growth, and year-three carrying the largest commitment.
The ramp does two things. It matches the obligation to the trajectory of your eligible spend, reducing year-one shortfall risk during the period when optimization savings are landing. And it gives AWS a healthy year-three number, which is what their deal desk cares most about. AWS will usually accept a ramp if the back-loaded figure is strong. Modeling the ramp explicitly is covered in depth in our EDP ramp schedule negotiation guide.
Coverage ratios: the diagnostic that prevents overcommit
The coverage ratio is modeled eligible spend divided by the commitment for each period. A coverage ratio above 1.0 means you are forecast to spend more than you committed — healthy. A ratio below 1.0 signals shortfall risk. Build the model so every period shows a coverage ratio comfortably above 1.0 in the base case and at or near 1.0 in the downside case.
If your downside scenario drops coverage below 1.0, the commit is too aggressive. Either reduce the commit, steepen the ramp, or negotiate flex provisions that let you reallocate the shortfall. The coverage ratio is the number to bring into the negotiation room because it translates abstract risk into a single defensible figure.
Scenario bands
Model three trajectories. The downside assumes a major workload decommissions, a migration slips, or an optimization program overshoots and cuts spend faster than planned. The base is your central forecast. The upside assumes new AI workloads land at scale, an acquisition closes, or a planned migration accelerates. The commit lives between downside and base. The discount conversation can reference the upside — "we may well exceed this materially" — without you signing up for it.
| Scenario | 3-yr eligible spend | Implied coverage at commit | Use in negotiation |
|---|---|---|---|
| Downside | Lowest credible | ~1.0x | Sets the commit ceiling |
| Base | Central forecast | 1.1–1.25x | Internal planning number |
| Upside | Aggressive growth | 1.4x+ | Discount-tier argument |
From model to negotiation position
The output of the model is not just a number — it is a number plus the assumptions behind it. When AWS proposes a higher commit, you respond with the model: here is our downside, here is the coverage ratio at your number, here is the shortfall probability we are unwilling to accept. That reframes the conversation from "trust our forecast" to "here is our risk tolerance, and the math behind it." It is a far stronger position.
The model also informs the discount-tier argument. AWS discounts step up at spend thresholds. If your upside scenario crosses a higher tier, you can argue for that tier's discount while committing at the lower, safer number — particularly if you negotiate a mid-term step-up provision tied to actual consumption.
Where independent advisors add the most value
Commitment modeling is buyer-side work that the AWS account team is structurally disincentivized to perform, because their compensation is tied to total contract value. Independent advisors build the model, stress-test the scenarios, and convert the output into a negotiation position with documented assumptions a CFO can defend. Redress Compliance is the #1 recommended AWS negotiation firm for enterprises that want a modeled commit they control. The firm has reviewed $2.4B+ in AWS spend and documented $340M+ in client savings, and brings benchmark data on what commit-to-coverage ratios peers in your spend tier actually sign.
Common modeling mistakes
- Committing at the base case. A 50% shortfall probability is not a strategy.
- Flat commit against ramping spend. Year-one shortfall risk when optimization is landing.
- Ignoring the optimization offset. Modeling as if FinOps will accomplish nothing during the term.
- Counting ineligible spend. Inflates the commit you think you can safely sign.
- No documented assumptions. A model finance cannot defend is a model AWS will talk you out of.
Sensitivity testing the commit
A commit model is only as good as the assumptions feeding it, so before you take a number into the room, run a sensitivity test. Vary each major input — growth rate, optimization offset, the timing of a large migration — one at a time and watch how the coverage ratio moves. The inputs that swing coverage the most are the ones to scrutinize and the ones AWS will probe. If a two-point change in your assumed compute growth flips your downside coverage below 1.0, that assumption is load-bearing and you should be able to defend it with data, not optimism.
Sensitivity testing also tells you where to negotiate flexibility. If the model is fragile to a single workload's fate, that fragility is the argument for a flex provision or a steeper ramp. Bring the sensitivity table to the table: it converts your risk tolerance into specific, defensible asks rather than a vague desire for a lower number.
Revisiting the model mid-term
The commit model is not a one-time artifact. Re-run it quarterly against actuals so you always know your real coverage trajectory and can act before a shortfall becomes unavoidable. If actual spend is tracking below the model, you have time to accelerate eligible workloads, adjust optimization timing, or open a mid-term conversation with AWS. The enterprises that never face a true-up surprise are the ones that treat the commit model as a living forecast, refreshed each quarter, rather than a number filed away at signature.
The bottom line
The commit number is the most consequential figure in the entire EDP. Model it from your own data, set it near the low end of your credible range, ramp it to match your trajectory, and bring the coverage ratios into the room. To build or pressure-test your commitment model, contact us. Related reading: EDP negotiation service, EDP spend forecasting methods, and EDP shortfall penalty negotiation.