AWS EDP: sizing the commit from your usage, not their growth story.

The AWS Enterprise Discount Program is a simple trade dressed up as a complex one. You promise a level of spend over a multi-year term, and in return you get a discount off the rate card. The discount is genuine and often material. The catch is that the promise is a floor, not a ceiling: commit to more than you use and you have prepaid for capacity you will forfeit, and the discount you were chasing is quietly erased by the overshoot.

The vendor has every incentive to size that commit generously, because a larger commit is a larger locked in number. The account team arrives with a growth story, your usage is only going up, and a commit built to match that story is a commit built to be too big. Sizing an EDP well is not about winning a bigger discount. It is about committing to a number you will actually consume, and the only honest source for that number is your own bill.

Start from the run rate you can see

The first move is to stop negotiating from the vendor's forecast and start from your measured run rate. Feed in your cloud cost export and the real shape of your spend appears: the run rate today, the trend across the period, the always on baseline, and the spikes that are one time rather than structural. That baseline, not an aspirational curve, is what a commit should be anchored to. A commit sized to a spike you will not repeat is a commit sized to fail.

The export never leaves your control to produce this. It is parsed where it sits, turned into a run rate and a per service trend, and the analysis is built from that. What you get is not the vendor's picture of your future, it is your own present, measured, which is the only defensible place to start sizing a multi-year promise.

Model your growth, and your discount, not theirs

A commit is a bet on the future, so the honest way to size it is to model the future as a range you control, not a single number the vendor hands you. The commit planner lets you set your own growth scenarios, a conservative case, a middle case, and a fast case, and see the committed cost against pay as you go under each. The point is to find the commit that earns the discount in your realistic case without tipping into forfeited capacity if growth comes in slow.

The same applies to the discount itself. Rather than accept the vendor's framing, you enter the discount you actually expect to achieve at each commit level and watch it flow through the math, set against a reference of published rates. The result is a plan that says, at this commit, at this discount, under this growth, here is what you save versus paying on demand, and here is the downside if you overshoot. That is a decision. The vendor's single confident number is a pitch.

The brief that makes the case internally

A commit decision is rarely made by one person. It has to survive finance, who will ask what happens if growth stalls, and leadership, who will ask why this number and not a rounder one. So the planner produces a brief: the recommended commit, the savings against pay as you go, the levers you pulled, and the downside if the forecast is wrong, laid out in a couple of pages you can actually forward.

That brief is what turns a spreadsheet exercise into an approved decision. Instead of a gut call defended in a meeting, you have a documented case, sized from your own usage, stress tested against your own scenarios, and benchmarked against what the discount should be. The commit you sign is one you can explain a year later, when the invoices arrive and someone asks whether it was the right call.

Sizing an EDP without the overshoot

A model of the future is still a bet

No planner removes the uncertainty in a multi-year commit, and your own growth can surprise you in either direction. The scenarios bound the risk, they do not eliminate it, and a genuine step change in your business can outrun any commit you sized conservatively. Committing always means accepting some chance of being wrong.

What changes is who wrote the forecast. Sized from your run rate, stress tested against your scenarios, and benchmarked against a real discount, the commit is your bet on your business rather than the vendor's bet on their pipeline. That is the difference between a commit you chose and one you were sold, and over a multi-year term on a large cloud bill, it is a difference measured in real money.