The ship that costs the most is the one at anchor. Every provisioned instance is a crew being paid to sit. The signal that matters is not uptime — it's utilization under real load. I've run teams that bragged about 99.9% availability while bleeding budget on a fleet that was 98% idle. This page is the ledger I now open before any capacity decision.
| Role | Real duty cycle | What to do with it |
|---|---|---|
| Prod web tier | 24/7, p95 < 60s | Keep hot. Autoscale on the p95, not the mean. |
| Batch workers | 4 hrs / night | Right-size to the peak job, then let them stop. Spot if it can retry. |
| Throwaway demo box | "just in case" | Release it. Clone on demand in 3 minutes. |
| Line | Monthly cost | Utilization | Action |
|---|---|---|---|
| Prod web tier | $1,840 | 41% | halve to 3× m5.large → $1,060 |
| Batch workers ×4 | $212 | 14% | 2 workers + on-demand pickups → $98 |
| Demo box | $190 | 0.2% | release → $0 |
| Total | $2,242 | → $1,158/mo |
That's 48% off the ledger — $13,008 a year — and the only thing we gave up was a box nobody was using anyway. The benchmark I set for my team: every rightsizing review should find at least one throwaway.
Formula: wasted = cost × (1 − utilization/100) × months. Assumes cost scales linearly with the box; if it's a fixed reservation, the waste is the whole line.
The calculator lies when your utilization number is a lie. If you're measuring the mean of a spiky load, you'll under-provision the fast path and toast the p95. Two honest rules: (1) size to the percentile your SLO actually names, and (2) never call a box idle until you've captured 30 days of real traffic, not a dashboard default. A wrong release is more expensive than the waste it solved.
Back to basecamp →