7
Cloud
Hold a 99.95% SLO or cut cloud costs by 30%?
Reliability ↔ Infrastructure spending
Context
Respond to a request for a 30% cut in cloud spend.
Finance wants a 30% cut in cloud spend. Our internal SLO is 99.95%; the customer SLA is 99.9%. CPU averages 35% because we keep headroom for 3× traffic spikes.
Option A: hold the SLO: find savings elsewhere, keep the headroom.
Option B: relax the internal SLO to 99.9% (matching the contract) and run hotter: fewer nodes, smaller buffers.
How do you frame this so it isn't "reliability versus money"?
Constraints
- SLO
- 99.95% (≈22 min/month)
- Utilisation
- CPU averages 35%; headroom for 3× spikes
- Contract
- Customer SLA is 99.9%
Hold the SLO and its headroomvsCut costs and relax the SLO to 99.9%
Community verdict
Hold the SLO and its headroom 43%Cut costs and relax the SLO to 99.9% 57%
7 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Hold the SLO and its headroom
Cut costs and relax the SLO to 99.9%
Cost efficiency →
Trade-offs
Dimensions
Hold the SLO and its headroomCut costs and relax the SLO to 99.9%out of 5
- Reliability
- 5Hold the SLO and its headroom scores 5 of 53Cut costs and relax the SLO to 99.9% scores 3 of 5
- Cost efficiency
- 2Hold the SLO and its headroom scores 2 of 55Cut costs and relax the SLO to 99.9% scores 5 of 5
- Contract safety
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentAutoscaling on real load signals lets you keep the SLO and drop average headroom. Headroom you pay for 24/7 for a 2-hour peak is the waste.
An internal SLO stricter than the contract is a choice, not a law. If customers are happy at 99.9% and we rarely burn budget, the extra half-nine is a product decision with a price tag.
Then write it down as an explicit decision with an error-budget policy, so nobody quietly erodes it further.
Most savings don't touch reliability: savings plans / reserved capacity (often 30%+ on steady load), rightsizing over-provisioned pods, deleting idle environments, and moving batch jobs to spot.
Do those first. Only then discuss the SLO, with data on how much error budget you actually burn.
Our idle staging environments alone were 11% of the bill. Embarrassing but useful.