Cloud bills grow in one direction without active management. The pattern is consistent: a migration or scaling event increases spend, the new baseline is accepted, and three years later the bill has tripled while the workload has grown by 50%.
Most of that gap is waste. Industry benchmarks show that organisations without active cost management are wasting 30–40% of their cloud spend on oversized instances, idle resources, and unoptimised storage. This guide gives you the complete playbook to find it, eliminate it, and keep it eliminated.
Why Cloud Bills Are Higher Than They Should Be
The structural cause of cloud waste is the mismatch between how cloud resources are provisioned and how they are actually used.
Provisioning for peaks that never materialise. Engineers provision instances based on estimated peak load with a safety buffer. Actual peak load is often 40–60% of the provisioned capacity. The rest runs idle 24 hours a day.
On-demand pricing as the default. On-demand is the most expensive pricing model, designed for variable or short-lived workloads. Baseline workloads that run continuously should be on reserved capacity at a 30–60% discount. The default — on-demand — is rarely revisited.
Invisible accumulation. Stopped instances still pay for storage. Unattached disks accumulate cost. Old snapshots multiply quietly. Development environments run over weekends. None of this is intentional; it is just never cleaned up.
Lack of ownership. When cloud costs are not allocated to specific teams, nobody is accountable for specific spending decisions. Without accountability, costs drift upward permanently.
The FinOps Model
FinOps (Financial Operations) is the framework most mature cloud organisations use to structure cost management. It has three phases:
| Phase | Goal | Key activities |
|---|---|---|
| Inform | Visibility | Tagging, cost allocation, dashboards, anomaly detection |
| Optimise | Reduction | Right-sizing, reserved capacity, waste elimination, spot adoption |
| Operate | Governance | Budget ownership, monthly reviews, IaC cost gates, team accountability |
Most organisations skip Inform and go straight to Optimise — then find the savings evaporate within a quarter because there is no accountability model to sustain them.
1. Cost Visibility: The Foundation
You cannot optimise what you cannot see. Before any other step, establish:
Resource tagging. Define a mandatory tag schema — minimum: environment, team, application, owner. Apply it to all existing resources. Enforce it on new resources via policy. Without tags, cost data cannot be allocated to teams, which means no accountability and no sustainable savings.
Cost allocation views. Configure cost allocation reports in your cloud provider's native tool (AWS Cost Explorer, Azure Cost Management, GCP Cost Dashboard) broken down by tag — so you can see cost by team, by application, and by environment.
Anomaly detection. Enable AWS Cost Anomaly Detection, Azure Cost Alerts, or GCP Budget Alerts. Set thresholds at 20% above your rolling 30-day average per service. The goal is to catch cost spikes within hours, not at month-end.
2. Right-Sizing: The Highest-Leverage Action
Right-sizing is consistently the largest single source of savings. The mechanism is simple: instances are overprovisioned, and the provider's own recommendation tooling tells you exactly which ones.
How to approach it:
-
Run AWS Compute Optimizer, Azure Advisor, or GCP Recommender. Each analyses 14–30 days of actual utilisation data and generates specific downsizing recommendations with estimated monthly savings.
-
Filter to instances with average CPU utilisation below 20% and average memory utilisation below 40%. These are reliably over-provisioned.
-
Prioritise by savings impact, not count. A single
m5.8xlargerunning at 10% CPU saves more than twentyt3.microinstances. -
Test the recommended size in a staging environment before applying to production. For databases, test under representative load before resizing.
Savings range: 15–25% of total compute spend, typically achievable within 30 days.
3. Waste Elimination: Find the Idle Resources
Every cloud account accumulates idle resources over time. A structured audit finds them:
| Resource type | How to identify | Action |
|---|---|---|
| Stopped instances | Console / Cost Explorer filter | Terminate if unused > 7 days; snapshot first if unsure |
| Unattached volumes/disks | CLI: aws ec2 describe-volumes --filters Name=status,Values=available |
Delete after confirming not needed |
| Unused load balancers | LBs with 0 healthy targets for > 7 days | Delete |
| Unused static IPs / Elastic IPs | Not associated with a running instance | Release |
| Old snapshots | Beyond defined retention (e.g. > 90 days) | Delete |
| Dev environments on 24/7 | Non-production instances running weekends and overnight | Schedule stop/start |
Scheduling non-production environments is one of the fastest wins. A development environment that runs 9am–7pm weekdays instead of 24/7 runs for 50 hours per week instead of 168 — a 70% reduction in running time for those instances.
4. Reserved Capacity: The Structural Saving
On-demand pricing is appropriate for variable and short-lived workloads. For baseline, continuous workloads — production web servers, databases, Kubernetes nodes — reserved capacity is 30–60% cheaper.
Commitment options by provider:
| Provider | Product | Discount vs on-demand | Flexibility |
|---|---|---|---|
| AWS | Reserved Instances (Standard) | Up to 72% (3-year) | Instance family fixed |
| AWS | Reserved Instances (Convertible) | Up to 66% (3-year) | Can exchange instance family |
| AWS | Compute Savings Plans | Up to 66% | Any instance type/family/region |
| Azure | Reserved VM Instances | Up to 72% (3-year) | Instance series fixed |
| GCP | Committed Use Discounts | Up to 57% (3-year) | Machine type fixed |
| GCP | Committed Use (flexible) | Up to 70% | Any machine type in family |
The critical rule: right-size before you commit. Locking in a commitment on an oversized instance saves less than committing on the correctly-sized one.
What to commit: workloads that have run continuously for > 3 months and show stable utilisation patterns. Start with 1-year commitments for new workloads; add 3-year for proven baseline workloads.
5. Spot and Preemptible Instances: The Aggressive Save
Spot/preemptible instances offer 60–90% discounts in exchange for the possibility of interruption. The discount is large enough to warrant building interruption-tolerance into eligible workloads.
Workloads well-suited to spot:
- CI/CD build runners (jobs can restart)
- ML training (checkpointing handles interruption)
- Batch data processing (idempotent pipelines)
- Kubernetes worker nodes for stateless workloads (pods reschedule on other nodes)
- Video encoding and media processing
Workloads not suited to spot:
- Production databases (interruption causes downtime)
- Single-instance stateful services
- Workloads without graceful shutdown handling
Best practice: Use a diversified spot fleet across multiple instance types and availability zones. The probability of all capacity types being reclaimed simultaneously is very low — diversification is the primary reliability mechanism.
6. Storage Optimisation
Storage costs are lower per unit than compute, but they grow silently and compound over years.
Tiers to use:
| Use case | AWS | Azure | GCP |
|---|---|---|---|
| Frequently accessed | S3 Standard | Hot Blob | Standard |
| Unknown/variable access | S3 Intelligent-Tiering | — | — |
| Infrequent access (> 30 days) | S3 Standard-IA | Cool Blob | Nearline |
| Archive (> 90 days) | S3 Glacier | Archive Blob | Coldline |
| Long-term archive (> 180 days) | S3 Glacier Deep Archive | — | Archive |
Enable S3 Intelligent-Tiering (or equivalent) for buckets where access patterns are unpredictable — it automatically moves objects between tiers based on access frequency with no performance impact.
Set lifecycle policies to transition objects to lower tiers after a defined period and delete them after your retention requirement expires. Unmanaged buckets grow indefinitely.
7. Governance: Keeping the Savings
Cost savings without governance revert. The structure that makes savings permanent:
- Monthly cost reviews per team against allocated budget. The team cost owner presents variance and remediation plan.
- Budget alerts at 80% and 100% of monthly targets, routing to the team Slack channel and cost owner.
- Infracost in pull requests for Infrastructure as Code — every PR that changes infrastructure shows the estimated monthly cost impact before merge.
- Quarterly right-sizing sweep — workload utilisation patterns change; re-run the right-sizing analysis every quarter and adjust.
- Tagging compliance gate — block untagged resource creation via cloud policy. A resource that cannot be attributed to a team cannot be governed.
If your team is ready to run a structured cloud cost reduction engagement — from audit to committed savings — get in touch. We typically identify 30–40% savings opportunities within the first two weeks of an engagement and deliver a prioritised remediation plan with implementation support.
See our Cloud Engineering capabilities for how we approach cloud cost and architecture work.