Cloud Cost Optimisation: The 8 Levers That Actually Move the Number

Every cloud cost review we run starts the same way: the client has already bought Reserved Instances or Savings Plans, and the bill is still climbing. RIs are a discount on waste you have already committed to — they do not find the waste. Here are the eight levers, in the order we actually pull them, that consistently deliver 30–50% reductions.

1. Right-Size Before You Commit to Anything

The single biggest lever, and the one everyone skips because it requires actually looking at utilisation data. Most production fleets we audit are running instances sized for peak load 24/7, when peak load happens for a few hours a week. Pull CPU, memory, and network utilisation over 30 days before committing to any instance family or size — not the "recommended" size from the console, the size your workload actually uses.

2. Auto-Scaling for Genuinely Variable Workloads

If your traffic has a real daily or weekly pattern — most commerce, SaaS, and internal-tooling workloads do — auto-scaling based on that pattern (not just CPU threshold reaction) removes the need to provision for peak at all. Scheduled scaling for predictable patterns (scale down every night, every weekend) is the fastest win here and takes a day to implement.

3. Turn Off Non-Production Environments

Staging, QA, and development environments running 24/7 are pure waste outside working hours. A scheduled stop/start policy on non-production environments alone typically cuts 60–70% off their running cost, since most teams only need them awake 10–12 hours a day, 5 days a week.

4. Storage Lifecycle Policies

Object storage left on the default tier accumulates cost quietly for years. Lifecycle policies that move infrequently-accessed data to cheaper tiers (and eventually to archive or deletion) after a defined age are a one-time configuration that keeps paying off. Orphaned snapshots and unattached volumes are the other silent cost — we routinely find these worth 5–10% of total storage spend on accounts that have never been audited.

5. Reserved Instances and Savings Plans — After Right-Sizing, Not Instead Of It

Once your fleet is right-sized and your scaling policy reflects real demand, committing to 1- or 3-year Reserved Instances or Savings Plans on the stable baseline (not the peak) locks in 30–60% discounts on workloads you know will run continuously. Committing before right-sizing just locks in the waste at a discount.

6. Architecture-Level Waste

Idle load balancers, unused Elastic IPs, NAT gateways processing near-zero traffic, and forgotten proof-of-concept resources are common in accounts that have grown organically over years. None of these show up as an obvious line item — they show up as a slowly rising bill nobody can explain. A quarterly resource audit against a tagging policy catches these before they compound.

7. Data Transfer Costs

Cross-region and cross-AZ data transfer is one of the least visible cost centres because it is billed in small increments that add up. Co-locating services that talk to each other frequently in the same region and AZ, and using a CDN for anything served repeatedly to end users, removes a cost that most teams never think to look for.

8. Committed Use on Managed Services, Not Just Compute

Managed database instances (RDS, Cosmos DB, Cloud SQL) often run at a similar or higher cost than the compute fleet, yet get excluded from cost optimisation because "it is just the database." The same right-sizing and reservation logic applies — most managed database instances we review are similarly over-provisioned.

• Right-size before committing to anything — this is the lever most guides skip
• Auto-scale and schedule for real demand patterns, not peak-always
• Turn off non-production environments outside working hours
• Apply storage lifecycle policies and clear orphaned resources
• Commit to Reserved Instances/Savings Plans only after right-sizing
• Audit for architecture-level waste — idle load balancers, unused IPs, forgotten resources
• Review data transfer patterns for co-location and CDN opportunities
• Apply the same discipline to managed databases, not just compute

Cloud cost optimisation is not a one-time project — it is a discipline that needs a quarterly review cadence, because workloads and usage patterns drift. Clients who treat it as ongoing governance rather than a single clean-up consistently keep their spend flat even as usage grows.