Cloud cost optimization: where the money usually leaks

The cloud turns infrastructure into a monthly bill that anyone with the right permissions can increase. Without deliberate habits, that bill drifts upward and nobody can explain why.

Step one: make spend visible

You cannot reduce what you cannot attribute. Before changing anything:

• Tag or label every resource by team, environment and product. Make tagging a requirement in your provisioning, not a clean-up project.
• Use the provider's cost tools to break spend down by service, account and tag, and review it on a schedule.
• Set budgets and alerts so an unexpected jump is noticed in days, not at month end.

Often the first review alone reveals resources nobody remembers creating.

The usual leaks

Idle and orphaned resources. Stopped instances that still have attached storage, unattached volumes, old snapshots, unused load balancers and IP addresses, forgotten test environments. Schedule a regular sweep, and shut development environments down outside working hours.

Oversized compute. Instances are often chosen once, generously, and never revisited. Look at actual CPU and memory use over a few weeks and resize to what is needed with a sensible margin. Consider newer instance generations, which frequently offer better price-performance.

Always-on workloads that are not always busy. Autoscaling, scheduled scaling, and serverless options can match capacity to demand. They are not free of trade-offs — cold starts, concurrency limits and per-request pricing at scale — so measure before assuming a saving.

Storage that never gets cleaned. Logs, backups and uploads accumulate. Use lifecycle rules to move older data to cheaper storage classes and delete what has no retention requirement.

Data transfer. Traffic between regions, between availability zones, and out to the internet is billed and easy to overlook. Chatty architectures that send lots of data across zones can quietly become a major line item. Keep tightly coupled components together, and use a CDN for content served to users.

Managed services used at the wrong tier. Databases, queues and caches provisioned for peak load around the clock. Check utilisation and tier accordingly.

Commitments and discounts

If a baseline load is stable, providers offer lower prices in exchange for commitment, such as reserved capacity or savings plans, and spare-capacity options that can be interrupted at short notice. Commit only to the steady floor of usage you are confident about, and use interruptible capacity only for workloads that tolerate interruption, like batch jobs.

Do not optimise reliability away

Cost work has failure modes. Removing redundancy, shrinking too far, or deleting data that turns out to be needed can cause outages that cost more than the saving. Keep production safety margins, take backups before deleting, and change one thing at a time so you can attribute the effect.

Make it a habit, not a project

• Review cost in the same cadence as reliability and delivery.
• Show each team its own spend, since people reduce what they can see.
• Include cost as a consideration in architecture decisions, early.
• Define a few unit metrics — cost per customer, per transaction, per environment — so growth in spend can be judged against growth in value.

What to take away

Start with visibility and ownership, remove idle and oversized resources, manage storage and data transfer, and commit only to what you are sure you will use. Sustained savings come from habits, not a one-off clean-up.