What Commitment Coverage Actually Looks Like at Four Company Sizes

Part 1 laid out the instruments. Part 2 gave the procedure. This part runs that procedure end to end at four different scales, so you can find the profile nearest to yours and see the shape of the answer.

Profile 1 — The startup

~$18,000 a month on AWS. Series A, 40 people, product still changing shape monthly. Roughly $11,000 of that is compute.

What is tempting. The console cheerfully recommends a Savings Plan sized to recent usage, and the three-year number looks enormous. Growth is up and to the right, so committing to today's usage feels conservative.

Why that is wrong. Growth being up and to the right is exactly the argument against a long instrument-specific commitment. This company will not be running the same architecture in eighteen months. What it needs is a discount that survives the company changing its mind.

What we would do. Measure the trailing-90-day floor, which lands at roughly 45% of compute — about $5,000 a month. Commit only to that, with a one-year, No Upfront Compute Savings Plan. No Upfront because at Series A runway is the binding constraint, and cash today is worth more than a slightly better rate.

The numbers. $5,000/month covered at roughly 27% is about $1,350 a month, or $16,200 a year. Coverage sits near 45%, which looks low against the 70–85% guidance and is correct here.

The lesson. Commit to the floor, not the forecast. "We could have saved more" is the wrong regret to optimize against — the expensive regret is a stranded three-year commitment on an architecture you abandoned.

Profile 2 — The SMB

~$55,000 a month. 200 people, a real product with real customers, infrastructure that has grown by accretion. About $34,000 is compute. Nobody has ever formally right-sized.

What is tempting. $34,000 a month of compute with almost no coverage is an obvious win. Buy a Savings Plan on Monday, book the saving.

Why that is wrong. It would lock in the waste. This estate is over-provisioned and nobody has checked.

What we would do. Right-size first. In an estate like this we typically find around 18% over-provisioning — instances two sizes larger than their sustained utilization justifies. That alone takes compute from $34,000 to roughly $27,900 a month, a $6,100 monthly saving with no commitment at all. Then re-derive the floor, now around $18,100 a month, and cover it with a one-year Compute Savings Plan.

That is $132,000 a year, about 20% of the original bill.

The order mattered more than the instrument. Had they committed first, the floor would have been computed against the bloated $34,000 — a commitment near $22,100. After right-sizing, actual usage falls to roughly $18,100, leaving about $4,000 a month of commitment they cannot use and cannot exit, for a year. The right-sizing saving would have been partly cancelled by the stranded commitment.

The lesson. Sequence beats selection. Right-size, wait a month, re-measure, then commit.

Profile 3 — The mid-market company

~$240,000 a month. Roughly $150,000 compute, $45,000 databases, $45,000 everything else. A platform team exists. A modernization programme is underway: RDS for Oracle onto Aurora PostgreSQL over the next fourteen months.

What is tempting. One big three-year Compute Savings Plan across the whole estate. Simple, one decision, good headline rate.

Why that is wrong. It flattens three genuinely different risk profiles into one instrument, and it ignores that the database estate is actively moving.

The database decision is the interesting one. A three-year RDS Reserved Instance would save roughly 45% on $45,000 — about $20,250 a month. A Database Savings Plan on provisioned instances saves roughly 20% — about $9,000 a month.

The DSP is worse by about $11,250 a month. We would still recommend it here, because the Oracle-to-Aurora migration will invalidate engine-specific reservations partway through the term, and a stranded RDS RI cannot be exchanged or sold. The DSP follows the workload across the engine change.

That is a real, quantified trade — roughly $11,250 a month to keep the discount attached to a moving estate — and it turns entirely on how much you trust the migration timeline. If that fourteen-month plan were a two-year plan with a shaky sponsor, the calculus would change.

The numbers. About $54,900 a month, or $659,000 a year against $2.88M of annual spend — roughly 23%.

The lesson. At this scale, layering stops being theory and starts being worth six figures. And the right answer sometimes costs you money on purpose.

Profile 4 — The enterprise

~$1.4M a month. Roughly $800,000 general compute, $180,000 GPU, $200,000 databases, $220,000 everything else. Dozens of accounts under one organization. They already hold a Private Pricing Agreement at about 12% off list.

What is tempting. Assume the PPA is the discount conversation, and treat Savings Plans as a rounding error on top.

Why that is wrong, and it is the most common enterprise modelling error we see. A PPA and a commitment discount are different layers, not additive percentages. Private pricing applies to your bill; Savings Plans and RIs apply to usage. Adding "12% PPA + 27% Savings Plan" and reporting 39% overstates the combined effect, and finance will eventually catch it. Model commitment savings against post-PPA rates, or model them separately and reconcile — but never just add them.

• General compute ($800k). Layer as in Profile 3, to 80% coverage: a 3-yr EC2 Instance SP over the frozen 50% (~$400k, saving ~$200k/mo) and a 1-yr Compute SP over the predictable 30% (~$240k, saving ~$65k/mo).
• GPU ($180k). Capacity first, discount second. These are the workloads where an unavailable instance is an incident, not an inconvenience. Secure capacity with On-Demand Capacity Reservations or zonal RIs, then let a commitment apply on top — roughly $50k/mo. The saving is not the point; the training jobs starting is the point.
• Databases ($200k). Stable and modern, so RDS Reserved Instances win outright — about $67k/mo across a 75%-covered estate.

The numbers. Roughly $382,000 a month, about $4.58M a year on $16.8M of annual spend — around 27%, layered on top of the existing PPA rather than added to it.

The real failure mode at this scale is organizational, not mathematical. Nobody owns the renewal calendar. Commitments were bought by a team that has since reorganized. Coverage looks fine in aggregate while three accounts run entirely uncovered. The fix is governance: a named owner per commitment, expiry dates ninety days ahead in a shared calendar, and a quarterly re-plan.

The four side by side

The pattern across the four is worth sitting with: the savings percentage rises with scale, but not because bigger companies get better rates. The rates are published and identical. It rises because scale brings a larger genuinely-predictable base, and predictability is the thing commitment discounts actually pay for.

What to do with this

Find the row closest to your spend, then run the six-step procedure from Part 2 against your own data. The profiles are a shape, not a prescription — your floor, your roadmap, and your capacity requirements determine the answer.