Every IT leader I talk to has the same complaint about cloud costs: they’re higher than expected, they keep growing, and nobody can fully explain why.

This isn’t a failure of cloud technology. Cloud infrastructure genuinely offers advantages over on-premises data centres for most workloads. But the pricing models are complex, the defaults are expensive, and most organisations migrated to cloud with a “lift and shift” approach that replicated on-premises architecture in a pay-per-use model — which is the most expensive way to run cloud.

I’ve spent the past six months helping three organisations reduce their cloud spend by meaningful amounts — between 25% and 40% — without reducing capability. Here’s where the real savings were hiding.

The Easy Wins (That Most People Have Already Done)

Let me get the obvious stuff out of the way. If you haven’t done these, do them first. They’re well-documented and straightforward.

Reserved instances and savings plans. If you have predictable baseline workloads running 24/7, you should be on reserved pricing. The AWS Cost Optimisation Hub and equivalent tools in Azure and GCP will identify these opportunities. Typical savings: 30-50% on compute for committed workloads.

Right-sizing. Most cloud instances are over-provisioned because someone chose a size during migration and never revisited it. A server that peaks at 20% CPU utilisation is two sizes too large. Use cloud provider tools to identify right-sizing opportunities and implement them. Typical savings: 15-25% on compute.

Shutting down non-production environments overnight. Development, staging, and testing environments that run 24/7 but are only used during business hours are wasting 65% of their compute cost. Schedule them to stop at 7 PM and start at 7 AM. Typical savings: 60-65% on non-production compute.

These are real savings and worth pursuing. But they’re also the first chapter of every cloud cost optimisation guide ever written. The bigger opportunities are elsewhere.

Where the Real Money Goes

Data Transfer and Egress

Cloud providers charge for data that moves between regions, between services, and especially for data that leaves the cloud entirely. These charges are buried in line items that most people don’t scrutinise, but they can represent 10-15% of total cloud spend.

One organisation I worked with was paying $14,000 per month in data transfer charges because their application architecture routed data through three availability zones for every API call. The redundancy was unnecessary. Simplifying the data path to single-AZ for non-critical operations cut data transfer costs by 70%.

Another common pattern: backing up cloud data to an on-premises location. Every byte transferred out incurs egress charges. Consider keeping backups within the cloud provider’s ecosystem rather than egressing to on-premises.

Storage Sprawl

Cloud storage is cheap per gigabyte. This is precisely why it becomes expensive in aggregate — because nobody deletes anything.

In every engagement I’ve done, storage costs were 20-40% higher than necessary because of orphaned data. Snapshots of instances that no longer exist. Logs that nobody reads, retained at full-performance storage tiers. Database backups from three years ago, sitting in standard S3 rather than Glacier.

The fix isn’t complicated. Implement lifecycle policies that automatically transition old data to cheaper storage tiers and delete it after retention periods expire. Review snapshot policies — most organisations take daily snapshots and retain them indefinitely, when weekly snapshots retained for ninety days would provide adequate protection.

Services Nobody Uses

This is the most frustrating cost category because it represents pure waste.

Every organisation I’ve audited has cloud services running that nobody uses, nobody owns, and nobody remembers deploying. Load balancers pointing to decommissioned instances. Databases provisioned for a proof-of-concept that ended two years ago. Elasticsearch clusters that were set up for a logging initiative that was abandoned. Lambda functions triggered by events that no longer occur.

These services individually cost $50-$200 per month, which is below the threshold of anyone’s attention. But an organisation with fifty orphaned services is paying $5,000-$10,000 per month for nothing. The solution is tagging discipline and regular audits — every resource tagged with an owner, a project, and an expiry date.

Building a Cost-Conscious Culture

The technical optimisations matter, but the cultural shift matters more.

Engineering teams need visibility into cost. When a developer deploys a service, they should know what it costs per hour and per month. Cloud cost should be a metric on engineering dashboards alongside performance, availability, and error rates.

Firms that provide AI strategy support have started incorporating cost modelling into their technical architecture work, which is the right approach. It’s much cheaper to design a cost-efficient architecture than to optimise an expensive one after deployment.

Finance teams need to work with engineering on cloud budgets. The traditional model of annual IT budgets doesn’t work well with cloud’s variable-cost model. Monthly budget reviews with engineering teams present — looking at actual spend against forecasts, identifying anomalies, and adjusting plans — keep costs visible and accountable.

Cloud cost optimisation isn’t a one-time project. It’s an ongoing discipline. The organisations that manage cloud costs effectively are the ones that treat it as a continuous practice, not an annual review.