Picture a team of six running a booking platform. Two years ago they moved off a single rented server onto a major cloud provider. The first bills were modest and everyone was pleased. Now the monthly invoice is several times what it was, traffic has grown only a little, and when the founder asks what changed, nobody can answer with confidence. The engineers are busy shipping features; the bill arrives as one number in the finance inbox.
This is the normal path for small teams, not a sign of carelessness. Cloud platforms make it very easy to create resources and say almost nothing when those resources stop being useful. In this story we go through the places where money most often leaks on AWS, Google Cloud or Azure, roughly in the order we check them, and what to do about each.
1. Environments that never sleep
Most teams have a staging environment, sometimes a separate demo environment for sales, and occasionally a copy someone spun up to test a migration. Each of these usually mirrors production: an application server, a database, a cache, a load balancer. They run all night and all weekend, while being used a few hours a week.
Start by listing every environment and asking who uses it and when. Staging can often be scheduled to stop outside working hours, or scaled down to the smallest machine that still behaves like production. Temporary copies should get an owner and an end date the day they are created. If an environment has no owner, that is usually the clearest sign it can go.
2. Machines sized for a launch day that never came
When a system is first deployed, the safe choice is a generous machine. Then the launch happens, traffic settles, and the size stays. The provider's monitoring will often show CPU sitting low for weeks and memory far below its limit.
Look at real usage over at least two or three weeks, including your busiest days, then step down one size at a time and watch. If the application runs on several instances, check that autoscaling actually scales down at night and not only up. Once usage has been stable for a while, commitment plans such as reserved instances or savings plans can lower the price of the capacity you know you will keep; they make sense only after the sizing is right, not before.
3. Managed database tiers
Managed databases are worth paying for: backups, patching and failover are handled for you. But they are also where the largest single line item often hides. A high-availability setup with a standby replica doubles the cost of the instance, and that is the right call for production but rarely for staging. Provisioned storage and guaranteed disk throughput are sometimes set far above what the workload needs.
Check each database for three things: whether its tier matches the environment it serves, whether its storage and throughput settings match actual use, and whether old read replicas are still connected to anything. Slow queries matter here too. A missing index can make a database look like it needs a bigger machine, when the real fix is in the query.
4. Data leaving the cloud
Data going into a cloud provider is usually free; data coming out usually is not. Traffic between regions or availability zones can also be billed. Teams are often surprised to find that a meaningful share of the invoice is network transfer, especially when images and files are served straight from storage or when services that talk constantly sit in different regions.
Serving static files and images through a CDN reduces both cost and load times. Keeping services that exchange a lot of data in the same region helps as well. If you use a NAT gateway so private servers can reach the internet, look at how much traffic goes through it; package downloads and calls to external APIs add up there, and some of that traffic can be routed more cheaply.
5. Logs nobody reads
Central logging is important, and we recommend it. But logs are billed by volume ingested and by how long they are kept. A debug-level log left on after an investigation, a health check that writes a line every few seconds, or a retention period of "forever" can turn logging into a surprisingly large bill.
Agree on a log level for production, set retention to what you actually need for troubleshooting and any legal requirements, and move older logs to cheaper archive storage if you must keep them. Metrics and alerts usually tell you more than raw log lines, at a fraction of the volume.
6. Storage that only grows
Snapshots of disks that no longer exist, unattached volumes left behind when a server was deleted, old container images in the registry, build artifacts from every pipeline run, and buckets of files from a feature that was removed: storage is cheap per gigabyte, which is exactly why it piles up quietly.
Most providers let you set lifecycle rules that delete or archive objects after a set time. Apply them to build artifacts, container images and backup snapshots. Keep the backups you need, but keep them on purpose, with a retention period someone chose.
7. Nobody owns the bill
The underlying problem behind all of the above is usually the same: the people who create resources never see what they cost, and the person who sees the cost cannot tell what each resource is for.
Two simple habits change this. First, tag every resource with at least the project, the environment and an owner, so the bill can be broken down in a way people recognise. Second, set budget alerts in the provider's console, so a sudden jump is noticed in days, not at the end of the month. A short monthly review, half an hour with the bill broken down by tag, is often enough to keep costs in line with what the business actually uses.
In short
A small team's cloud bill grows through leftovers: environments that run around the clock, machines sized for a busier day, database tiers set higher than needed, data transfer nobody planned for, logs kept forever and storage nobody cleans up. Each one is easy to fix once it is visible. Tag resources, set budget alerts, review the bill monthly, and resize before you commit to long-term discounts.
In our cloud and DevOps work, cost control sits next to monitoring and backups: we review usage, shut down what is not needed, resize the rest and keep the accounts in the client's own name.
Planning a project like this?
Plan it in 10 steps