Where your cloud bill leaks money, and how to fix it

Cloud platforms make it easy to start something and easy to forget it is running. Over a year or two, many companies find their bill has grown far faster than their traffic. Usually the cause is not the application itself, but everything around it: test servers left on, databases sized for a launch that never needed them, logs nobody reads, and data quietly moving between services.

This guide covers the most common leaks and how to fix them, whichever provider you use.

1. Idle and oversized compute

Servers are frequently provisioned generously at launch and never revisited. Check average and peak CPU and memory usage over the last month. A machine that rarely exceeds a small fraction of its capacity can usually move to a smaller size, or to a burstable instance type designed for spiky, mostly idle workloads.

Look for compute with no meaningful traffic at all: old feature branches, proof-of-concept environments and servers from a migration that finished months ago.

2. Non-production environments running all the time

Development, testing and staging environments are often the same size as production and run 24 hours a day, seven days a week. Your team uses them for perhaps 50 hours of a 168-hour week. Scheduling them to switch off in the evenings and at weekends can cut their running cost by roughly two thirds.

3. Data transfer and network charges

Sending data into a cloud provider is usually free. Sending it out to the internet, between regions and sometimes between availability zones is not. Several patterns cause surprising bills:

• Serving images, videos and downloads directly from servers or storage instead of through a CDN.
• Managed NAT gateways, which charge for each gigabyte processed as well as by the hour, used by private servers to download updates or call external APIs.
• Services in different regions or zones talking to each other constantly.
• Backups and replicas copied across regions more often than needed.

Put a CDN in front of public assets, keep chatty services in the same region and zone where resilience allows, and use private endpoints for cloud services so traffic does not need to pass through a NAT gateway. Some object storage providers, such as Cloudflare R2, do not charge for egress at all, which can matter a great deal for media-heavy sites.

4. Databases sized for the worst day

Managed databases are among the most expensive line items. Check whether provisioned capacity, storage performance (IOPS) and the number of read replicas match real usage. Many applications are better served by a smaller instance plus caching and better indexes. Slow queries are often fixed with an index rather than a bigger machine.

5. Storage that only grows

• Unattached disks left behind when servers were deleted.
• Snapshots and backups kept forever with no retention policy.
• Old log files, build artefacts and uploads that nobody needs in hot storage.
• Container images piling up in registries.

Set lifecycle rules that move older objects to cheaper storage classes and delete what you no longer need. Define backup retention deliberately, for example daily for a month and monthly for a year, rather than keeping everything forever.

6. Logs and monitoring

Observability tools often charge by the volume of logs ingested and stored. Verbose debug logging left on in production can cost more than the servers producing it. Reduce log levels, sample high-volume logs, drop noisy health-check entries and set sensible retention periods.

7. Paying on-demand prices for steady workloads

If a workload runs all the time and will continue to, commitment-based pricing such as AWS Savings Plans or Reserved Instances, Google Cloud committed use discounts and Azure reservations offer substantial discounts compared with on-demand rates. Commit only to the baseline you are confident about, and only after right-sizing, otherwise you lock in waste.

The common leaks at a glance

Make costs visible and owned

1. Tag every resource with project, environment and owner so you can see who is spending what.
2. Set budgets and alerts in your provider’s billing tools so surprises arrive as an email, not an invoice.
3. Review costs monthly with the people who can change them, not just finance.
4. Track one unit metric, such as cost per active customer or cost per thousand page views, to see whether efficiency is improving as you grow.

A realistic first month

You do not need a dedicated cost team to make progress. In week one, turn on cost allocation tags and budget alerts and export last month’s bill by service. In week two, delete obviously unused resources and schedule non-production environments. In week three, right-size the largest servers and databases based on real usage, and put a CDN in front of public assets. In week four, review logging volume and retention, and decide whether a commitment-based discount makes sense for the steady baseline that remains.

If your cloud bill has outgrown your business, we can review your setup, find the leaks and implement the fixes, usually starting with changes that pay for themselves within the first month.