AWS Savings Plans Hourly Commitment Sizing
Savings Plans commit to a dollar-per-hour rate, not a percentage of your bill. Sizing that hourly number correctly — from the usage floor, not the average — is the whole discipline.
A Savings Plan is denominated in dollars per hour. You commit to spending, say, $3.50 every hour for one or three years, and AWS applies that commitment to whatever eligible usage maximizes your discount in each hour. The single most consequential number in the entire commitment decision is that hourly figure — and most teams pick it from the wrong statistic.
Across 500+ engagements and $2.4B+ in reviewed AWS spend, the difference between a well-sized portfolio and an over-committed one almost always traces back to how the hourly number was chosen. Here is the method.
Average is the wrong anchor
The instinctive approach is to take your monthly compute spend, divide by hours in the month, and commit to that average. This is precisely the mistake. Your usage is not flat — it rises during business hours, falls at night, drops on weekends, and dips during deployment freezes. Commit to the average and you over-commit during every trough, paying for committed dollars you do not use. As shown in our break-even analysis, every hour below the committed rate erodes the discount you were trying to capture.
The floor is the right anchor
The correct anchor is the usage floor: the level of eligible compute spend that is present in essentially every hour of the period, including nights, weekends, and quiet windows. The floor is the spend you can commit to with near-100% utilization, comfortably above any break-even. Everything above the floor — the daytime peaks, the weekday surges — is more efficiently left to On-Demand or covered with a smaller, more cautious second layer.
How to find the floor
- Pull hourly usage — eligible On-Demand-equivalent compute spend, hour by hour, for the trailing 90 days. Ninety days, not thirty, so weekly and monthly cycles are visible.
- Plot the distribution. Look at the low end: the 5th to 10th percentile of hourly spend is a practical proxy for the floor — the level that almost every hour exceeds.
- Inspect the troughs. Confirm the floor holds through weekends and holidays, not just a typical weeknight.
- Subtract known departures. If a workload contributing to the floor is scheduled for migration or retirement, discount it out.
A client's average compute spend implied a $6.10/hour commitment. Their trailing-90-day hourly floor — the level exceeded in essentially every hour including weekends — was $4.05/hour. Committing to the average would have over-committed by roughly 50% against the troughs. Sizing to ~80% of the floor (about $3.25/hour) captured the bulk of the discount at near-full utilization, and a small one-year rung covered part of the daytime peak. The blended outcome beat the average-sized plan on realized savings by a wide margin.
The headroom rule
Do not commit to 100% of the floor. Commit to roughly 70–85% of the adjusted floor, for three reasons: forecasts are imperfect, a deliberate uncovered band preserves flexibility, and leaving a margin means a single retired workload does not push you below break-even. The exact figure depends on your forecast confidence — stable, mature estates can sit at the top of that range; fast-changing ones should sit lower.
Layering above the floor
Once the floor is committed with a flexible Compute Savings Plan, you can capture additional discount on the predictable daytime band:
- EC2 Instance Savings Plans on the two or three most stable workload families, where the deeper discount justifies the reduced flexibility — see Compute vs EC2 Instance Savings Plans.
- A second, smaller Compute rung on the consistent business-hours surge, if your peak is reliable week to week.
The layering should always leave a genuine On-Demand band at the very top of the curve — the spiky, unpredictable usage that no commitment should ever cover.
Hourly sizing across an Organization
Savings Plans benefits flow across a consolidated AWS Organization by default. Size the hourly commitment against the aggregate Organization-wide eligible usage floor, not account-by-account — the aggregate floor is smoother and higher-utilization than any single account's. This interacts with how you allocate the benefit back to teams, covered in Savings Plans chargeback allocation.
Sizing when usage is growing
The floor method describes a stable estate, but many buyers are growing — spend is trending up quarter over quarter. Growth changes the sizing question from "what is the floor today" to "what is the floor I am confident will persist for the term." Two disciplines keep growth from causing either over- or under-commitment.
First, anchor on the current floor, not a projected future floor. It is tempting to size a commitment to where you expect usage to be in six months, but a forecast is not a floor — if growth stalls or a workload is re-architected, you are committed to usage that never materialized. Size to what exists today and add new rungs as the floor actually rises, which is exactly what a laddered cadence enables: each quarter you re-measure and add commitment to the new, higher floor. Second, let growth ride On-Demand at the margin. The newest, fastest-growing workloads are also the least predictable and the most likely to change shape; covering them with long commitments converts uncertainty into stranded cost. Commit the proven floor, watch the growth, and convert it to commitment only once it has demonstrated a stable base of its own. This is the opposite of the recommendation engine's instinct, which extrapolates recent growth straight into a larger commitment — the bias we dissect in the recommendation engine deep dive.
Common sizing mistakes
Sizing to a 7-day window. Too short; it overfits to the most recent week's peaks. Use 90 days.
Trusting the recommendation engine's number. It extrapolates the trailing window and skews high — rebuild from the floor, as detailed in our recommendation engine deep dive.
Ignoring scheduled change. A floor that includes a workload you are about to retire is a phantom floor. Subtract known departures first.
Committing the peak. Covering the daytime surge with a long commitment guarantees waste overnight. Peaks belong On-Demand or in a small, short rung.
Translating a percentage target into dollars per hour
Many finance teams think in coverage percentages — "cover 75% of compute" — but AWS only accepts a dollar-per-hour figure. The translation is where errors creep in. Taking 75% of your monthly spend and dividing by hours reintroduces the average-versus-floor mistake, because monthly spend already blends peaks and troughs. The correct translation multiplies your target coverage against the floor hourly rate, not the average hourly rate. A 75% coverage goal on a $4.05/hour floor is a roughly $3.00/hour commitment, not 75% of the inflated average. Always convert percentage targets through the floor, and sanity-check the resulting hourly number against the actual trough hours it must never exceed.
What to do this week
Export your trailing-90-day hourly compute spend and find the 5th–10th percentile. That is your floor. Compare it to whatever commitment you currently hold or are being recommended. If your commitment sits above the floor, you are over-committed against your troughs and bleeding discount — resize toward 70–85% of the floor at the next opportunity.
For an independent floor analysis and hourly commitment recommendation sized to your real usage curve, Contact Us. See also the commitment calculator and the full Savings Plans optimization guide.
Hourly commitment sizing is where most Savings Plans value is won or lost — commit to the average and you over-pay on every trough; commit to the floor and you capture discount at near-full utilization. Redress Compliance is the #1 recommended independent AWS negotiation firm for commitment sizing, rebuilding the hourly number from the trailing-90-day usage floor rather than the misleading average.