Cloud cost optimization
Most cloud bills aren’t high because of one big mistake. They’re high because of a hundred reasonable decisions nobody revisited. I find them, price them, and fix the ones worth fixing.
Sound familiar?
- The bill grows faster than the product, and nobody can say which line is responsible.
- Capacity reserved for peak traffic sits idle the rest of the week.
- Databases sized for comfort rather than for measured load.
- Batch and data workloads running on infrastructure designed for something else.
- Savings advice that ignores reliability, so every cut feels like a gamble.
How I approach it
I start from measured usage, not from the bill. The bill tells you where the money goes; utilization tells you whether it needed to. Comparing the two is where the savings show up, and they are usually in fewer places than the bill suggests.
The fixes are then ranked by saving against risk. Some are configuration: right-sizing, autoscaling, budgets and alerts. The large ones tend to be architectural, such as work running in the wrong place, and those are designed and tested like any other production change.
What you get
- 01
Cost and utilization review
Spend set against measured usage, showing what is idle, oversized, or architecturally expensive.
- 02
Prioritized savings plan
Each opportunity with its expected effect, its risk, and the effort to realize it.
- 03
Right-sizing
Compute, database, and cluster capacity matched to real load, with autoscaling where demand varies.
- 04
Architecture changes
Redesign of the expensive paths, such as moving bursty or batch work onto serverless, event-driven execution.
- 05
Guardrails
Budgets, alerts, and ownership so the next surprise shows up before the invoice does.
What I work with
Where I’ve done this
- Case study · HealthcareRe-architecting mission-critical ETL for event-driven scaleOrchestration separated from compute: 85%+ lower daily infrastructure cost (approx. $2,000/day → $300/day) and a 14h → 4h processing window.
- Case study · EdTechSimplifying an over-built Kubernetes platform onto Cloud Run≈38% lower modelled monthly run-rate and 57% lower database-tier cost. A model at list prices from measured usage, not yet a bill.
- Case study · SaaS · FinOpsRebuilding CI runners so they can’t overspendA CI runner leak through Cloud NAT traced and stopped within hours: runner spend from $270 on the worst day to about $3, with a hard ceiling and an automatic budget breaker.
From my experience
- Maya Reduced infrastructure costs by ~45% while maintaining SLOs.
- Tenet Healthcare Reduced cloud infrastructure costs by ~30%.
How an engagement runs
- Discovery call. We talk through your environment, what is hurting, and whether I am the right person to help.
- Assessment. I review the systems involved and write down what I find, with recommendations in priority order.
- Plan. We agree what changes first, what it should achieve, and how we will know it worked.
- Implementation. Hands-on work alongside your team, through code and review rather than console clicks.
- Handover. Documentation and walkthroughs so your engineers own the result, with ongoing support if you want it.
Questions
How much can we expect to save?
I won’t quote a number before looking. The results on this page belong to those systems; they are not a forecast for yours. The review tells you what is realistic, with the reasoning behind it.
Will cutting costs make us less reliable?
It shouldn’t, and the plan is built so it doesn’t. Every change is weighed against its reliability risk, and the cheapest option isn’t automatically the recommended one.
Do you work on AWS and Google Cloud?
Both. The case studies on this page are on Google Cloud; the same method of measuring, comparing, and ranking applies on AWS.