CASE STUDY · FINOPS / CLOUD COST OPTIMIZATION
Cutting a client's cloud bill by 35% through FinOps.
- 35%Monthly cloud bill down 35% over 4 months
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Tagging, rightsizing, commitment planning and clean-up of idle resources, together with a way to keep the gains.
- 1Cloud spend was rising faster than usage.
- 2Customer numbers and traffic grew slowly, but the monthly bill climbed.
- 3Several teams had created their own accounts and environments over the years.
- 4Nobody knew which resources were in use, who owned them or why they were large.
- 5Finance asked for cuts.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01We stopped a set of instances that looked idle, with low CPU and no inbound traffic
One of them ran a quarterly reporting job. It failed the next time finance needed it. The stop step had a rollback, so service came back within the hour, but we had missed a signal.
- PROBLEM 02After that we added two rules
Anything with a schedule-like pattern in the past year was checked with its owner before action, and every stop went through a hold period with the resource tagged "pending removal" and an email to the listed owner. We also asked each team to list seasonal workloads up front.
- PROBLEM 03A second hurdle was commitments
An early draft bought capacity for the old, larger fleet. Because rightsizing was still in progress, we would have committed to instances the team planned to retire. We held back, finished the resizing, re-measured the steady base and bought commitments only for that.
- PROBLEM 04We kept a margin below the base and used shorter terms for the uncertain part
03 · THE PROCESS
How we ran it.
We ran it over four months in phases.
- 01Step 1
Month one: we got read-only access, built a baseline of spend by account and service and held interviews with each team lead.
- 02Step 2
Month two: we introduced a tagging standard and started on clean-up of items with clear evidence of no use.
- 03Step 3
Month three: we rightsized instances and databases with the owning teams, then moved storage to cheaper tiers using lifecycle rules.
- 04Step 4
Month four: we planned commitments on the reduced, stable base and set the monthly review.
We met the engineering leads weekly. Each change had a named owner and a rollback note. Finance joined a short monthly review.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Every resource has an owner, and untagged resources cannot be created.
- NOW 02
Teams see their own spend and are asked to explain changes in it.
- NOW 03
Non-production environments sleep by default.
- NOW 04
Engineering and finance review the bill together every month.
- 35%
Monthly cloud bill down 35% over 4 months
05 · WHAT WE BUILT
How it works.
- A tag policy covered owner, team, product and environment.Untagged resources were reported weekly, then blocked at creation in infrastructure code.
- Idle detection used a minimum observation window of utilisation, network and attachment data.Items were stopped before they were deleted, with a hold period for anyone to object.
- Rightsizing used CPU, memory and I/O percentiles over several weeks, not averages.Changes moved one size down at a time.
- Non-production environments were scheduled to switch off outside working hours.
- Storage lifecycle rules moved cold data to cheaper tiers and expired old snapshots and logs according to agreed retention.
- Commitments were bought only for the base load that had stayed steady after clean-up, with a mix of terms to keep flexibility.
- Controls
- Savings were reported net of anything that grew elsewhere, so moving cost from one line to another did not count as a win. A weekly report compared spend per unit of usage, such as per customer or per transaction, to the previous month, which separated real efficiency from a drop in traffic. Deletion of data always required an explicit sign-off from the data owner.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Cloud spend was rising faster than usage. Customer numbers and traffic grew slowly, but the monthly bill climbed. Several teams had created their own accounts and environments over the years. Nobody knew which resources were in use, who owned them or why they were large. Finance asked for cuts. Engineering feared that any cut would cause an outage.
- What did Brandsmashers build?
- Tagging, rightsizing, commitment planning and clean-up of idle resources, together with a way to keep the gains.
- How was the work run?
- We ran it over four months in phases.
- What were the results?
- Monthly cloud bill down 35% over 4 months.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
