Savings Plans & Reserved Instance Strategy
Modelling the commitment decision properly, before you lock in three years.
- Turnaround
- 3–5 business days
- Who it is for
- Teams with stable baseline spend considering a one or three-year commitment.
01 — The problem
Commitments are the largest single lever on cloud cost and the easiest to get wrong. Over-commit and you pay for capacity you cannot use; under-commit and you pay on-demand rates indefinitely. Most teams guess.
02 — What is included
Exactly what you get, and nothing vague.
- Baseline versus burst analysis across 12 months of billing data
- Compute Savings Plans vs EC2 Instance Savings Plans vs Reserved Instances, modelled
- Coverage and utilisation targets with the risk of each stated plainly
- Spot suitability for the workload sitting above the committed baseline
- A laddering plan so commitments do not all expire at once
03 — What this usually finds
The recurring ones, named up front.
- Existing commitments under-utilised and quietly wasted
- Three-year commitments on workloads due for re-architecture
- No Spot usage at all above a very stable baseline
- Coverage gaps in an account nobody included in the last purchase
Listed because they recur, not because they are guaranteed. The audit reports what is actually there.
Next step
Twenty minutes to find out whether this is worth doing.
Every engagement runs under a signed mutual NDA with a read-only IAM role. If the audit would not pay for itself, I will say so on the call.