The average organisation wastes 32% of its cloud spend. That's not a guess — it's the finding from the FinOps Foundation's State of FinOps 2026 report, covering thousands of companies across AWS, Azure, and GCP. On a £500k annual cloud bill, that's £160,000 going nowhere.
The waste isn't malicious. It's structural. Engineers provision for peak load and never scale back down. Projects end but infrastructure stays running. Snapshots accumulate. Dev environments run 24/7 when they're only used 8 hours a day. Nobody's tracking it because nobody owns it.
This article describes the 4-week sprint model we use to find and eliminate cloud waste. Not a 6-month transformation programme. Not a dashboard implementation. Four weeks of focused work that typically recovers 20–30% of monthly spend — and builds the system to keep it from coming back.
Where the waste actually hides
Before diving into the sprint, it helps to know what you're hunting. Cloud waste falls into five categories, and most organisations have all five:
| Category | What it looks like | Typical waste |
|---|---|---|
| Idle resources | Instances running at 2–5% CPU. Load balancers with no targets. Unattached EBS volumes. Elastic IPs not assigned to anything. | 5–10% |
| Oversized instances | A db.r5.4xlarge running at 12% utilisation because someone provisioned for "just in case." Kubernetes nodes at 15% CPU. | 8–15% |
| Missing commitments | Running on-demand pricing for stable, predictable workloads that should be on Reserved Instances or Savings Plans — losing 40–60% potential discount. | 10–20% |
| Storage bloat | Old snapshots nobody deletes. S3 buckets with no lifecycle policy. Logs retained forever. Data sitting in hot storage that should be in Glacier. | 3–8% |
| No governance | No tagging. No cost allocation. No budget alerts. No approval workflow for new resources. Every sprint adds infrastructure and the bill just climbs. | Compounds everything above |
The last category — no governance — is why the other four keep coming back. You can clean up idle resources in a day, but without governance, new ones appear the following week. The sprint model addresses all five, in the right order.
The 4-week sprint
You can't optimise what you can't see. Week 1 is a full-access, read-only audit of every cloud account. We map every resource, every cost line, every tag (or lack of one), and every utilisation metric.
The output is a resource inventory with cost allocation by team, project, and environment — often the first time anyone in the organisation has seen this view. We also identify the quick wins: resources that are clearly idle, obviously oversized, or running without any commitment discount.
What this typically reveals: 15–25% of compute instances running below 10% average CPU. Dev and staging environments running 24/7. Dozens of unattached EBS volumes. S3 buckets with terabytes of data and no lifecycle policy. Load balancers with zero registered targets.
We also build a tagging taxonomy in Week 1. Every resource needs to be tagged by environment (production, staging, dev), team, project, and cost centre. Without this, cost allocation is impossible and nobody owns their spend.
Week 2 is where the bill starts dropping. We work through the quick wins identified in Week 1:
Terminate idle resources. Every instance, volume, snapshot, and IP address that's not serving a purpose gets documented and terminated. This is the easiest money — you're paying for things that do nothing.
Rightsize oversized instances. We analyse 2–4 weeks of utilisation data and resize instances to match actual demand. A db.r5.4xlarge running at 12% becomes a db.r5.xlarge. An m5.2xlarge running a lightweight API becomes an m5.large. No performance impact — just less waste.
Schedule non-production environments. Dev and staging environments don't need to run at 3am on a Sunday. We implement automated start/stop schedules — typically 12 hours on weekdays only. That alone cuts non-production compute costs by 65%.
Clean up storage. Delete orphaned snapshots. Apply S3 lifecycle policies to move infrequently accessed data to cheaper storage tiers. Set log retention periods. Remove duplicate backups.
Typical Week 2 savings: 12–18% of monthly spend. These are immediate reductions — they show up on the next bill. On a £40k monthly bill, that's £5,000–£7,000 back every month.
With the waste gone and instances rightsized, your remaining workloads represent actual demand. Now you can commit to discounted pricing with confidence.
Reserved Instances and Savings Plans offer 30–60% discounts in exchange for a 1- or 3-year commitment. The mistake most teams make is buying commitments before rightsizing — locking in discounts on oversized instances just means you're paying less for waste. The correct sequence is: audit → rightsize → then commit.
We analyse your now-rightsized workload patterns and recommend the optimal mix of Reserved Instances (for stable, predictable workloads) and Savings Plans (for flexible compute). The goal is to cover 70–80% of your steady-state compute with commitment pricing and keep 20–30% on-demand for flexibility.
Spot instances are another lever for fault-tolerant, interruptible workloads — batch processing, CI/CD pipelines, data processing jobs. Spot pricing is typically 60–90% cheaper than on-demand. Not every workload is a candidate, but the ones that are can save dramatically.
The commitment decision framework: If a workload has run consistently for 3+ months and will continue for at least 12 more, it's a Reserved Instance candidate. If your compute mix changes frequently but total spend is stable, a Savings Plan gives you the discount with more flexibility. If the workload can tolerate interruption, use Spot.
This is the week that separates a one-time cleanup from a permanent reduction. Without governance, everything you fixed in Weeks 1–3 starts drifting back within 90 days.
Budget alerts. Set monthly budget thresholds per team and environment. When spend exceeds 80% of budget, the team lead gets notified. When it exceeds 100%, it escalates. This creates accountability without blocking anyone.
Tagging enforcement. Untagged resources get flagged automatically. After a grace period, untagged resources get terminated. This sounds aggressive, but it's the only way to maintain cost visibility at scale.
Cost allocation reports. Weekly automated reports showing spend by team, project, and environment. When teams can see what they're spending, they self-correct. The report does the work — no one needs to police it.
Approval workflows. New production resources above a certain threshold (say, anything over £500/month) require approval. This doesn't slow teams down — it makes them think before provisioning an m5.4xlarge when an m5.large would do.
Anomaly detection. Automated alerts for unexpected spend spikes — a sudden 40% increase in a specific service, an unusual data transfer charge, a new resource type appearing. You want to catch these in hours, not on next month's invoice.
The governance trap: Don't over-engineer this. You need five things: budget alerts, tagging enforcement, cost reports, an approval workflow, and anomaly detection. That's it. If you try to build a comprehensive FinOps programme in Week 4, you'll ship nothing. Start with these five, iterate later.
What this adds up to
On a typical £40,000/month cloud bill:
Week 2 (waste removal + rightsizing): £5,000–7,000/month saved
Week 3 (commitment discounts): £3,000–5,000/month saved
Week 4 (governance): prevents £2,000–4,000/month in drift
Total: £10,000–16,000/month — a 25–40% reduction.
The Week 2 and Week 3 savings are permanent and show up immediately. The Week 4 savings are preventative — they stop the waste from rebuilding. Without governance, you'll be back to the same spend within 3–6 months.
Why this doesn't happen on its own
If cloud cost optimisation were easy, every organisation would already be doing it. Three things get in the way:
Nobody owns it. Engineering owns performance. Finance owns the budget. Nobody owns the intersection. Cloud costs live in a gap between two departments, and neither has the tools, time, or incentive to fix it.
Fear of breaking things. Rightsizing means changing instance types. Scheduling means turning things off. Terminating idle resources means deleting things. Every one of these carries a risk of outage if done carelessly. Teams default to "leave it running" because it's safer than "turn it off and see what happens."
No baseline. If you don't know what you're spending or where the waste is, you can't build a case for action. The audit in Week 1 creates the baseline that makes everything else possible.
What happens after the sprint
The sprint gets you 25% savings and a governance framework. But it's the starting point, not the finish line. The organisations that sustain and extend their savings do three things:
Monthly cost reviews. A 30-minute meeting where each team reviews their spend against budget, identifies anomalies, and plans upcoming changes. This keeps cost awareness alive without making it burdensome.
Continuous rightsizing. Workloads change. What was perfectly sized six months ago might be oversized today. Quarterly rightsizing reviews ensure your infrastructure tracks actual demand, not historical demand.
Architecture optimisation. The sprint focuses on low-hanging fruit — things you can fix without changing code or architecture. The next level of savings comes from architectural changes: moving to serverless where appropriate, consolidating databases, redesigning data pipelines. These take longer but deliver compounding returns.
The bottom line
Cloud cost optimisation isn't a technology problem. It's a visibility and ownership problem. The technology to identify and fix waste already exists inside your cloud provider's own tooling. What's missing is someone with the time, access, and expertise to run the process.
Four weeks. Read-only access to your cloud accounts. No software to buy. No platform to learn. Just a clear audit, targeted fixes, commitment optimisation, and governance that sticks. That's the sprint.