Cloud bills do not usually explode because of one bad decision. They grow through dozens of small ones: a test instance left running, a snapshot kept forever, a log bucket with no expiry, a database sized for a launch that never came. By the time the invoice is uncomfortable, the cause is spread across a dozen services and nobody owns the total.
Cost control is not a finance project bolted onto engineering. It is a set of habits that make spending visible and reversible. The good news is that the first pass is cheap: most teams find their biggest savings in a single afternoon of looking.
Read the bill before you optimize
Start with the invoice grouped by service, then by resource. Do not begin with a spreadsheet of every line item; begin with the ten services that account for most of the spend. In most small accounts, compute, storage, database and network make up the bulk, and the long tail is noise until the top is under control.
Compare this month with the same month last year and with last month. A steady rise is easier to fix than a spike, because the cause is usually a new workload or a forgotten environment rather than a single runaway process. Write down the three biggest changes and who owns each one.
Find idle and orphaned resources
Idle resources are the easiest win. Look for instances with low CPU and no network traffic, unattached block storage, old snapshots, unused load balancers and development environments that run overnight. A staging environment that nobody uses after six o'clock is a subscription to nothing.
Orphaned resources are harder to spot because they are not attached to anything obvious: a floating IP, a database read replica with no readers, a queue with no consumers. Tagging helps, but a simple inventory export and a conversation with the team will find most of them faster than any tool.
Right-size compute without breaking latency
Most instances are bought for a peak that happens a few times a month. Check the actual utilisation over thirty days, not the last hour. If CPU sits under twenty percent and memory has headroom, a smaller instance or a burstable tier may carry the same load for less money.
Right-sizing is not only about shrinking. A workload that swaps memory or throttles under load can cost more in latency and support time than the larger instance would. Change one service at a time, watch the error rate and the response time, and keep a rollback path. The goal is the smallest shape that meets the requirement, not the smallest shape that fits on a slide.
The cheapest instance is the one you do not need. The second cheapest is the one sized for the load you actually have.
Storage, snapshots and egress
Storage looks cheap per gigabyte and becomes expensive through accumulation. Set a lifecycle rule for logs, old backups and temporary uploads. Review snapshots by age and keep only the ones that support a real recovery point. A backup you will never restore is just a bill with a reassuring name.
Egress is the line that surprises teams. Serving large files, syncing between regions or pulling data out of a managed service can cost more than the compute that produced it. Put a CDN in front of static assets, keep chatty services in the same region and check the pricing page before you design a cross-region pipeline.
Commitments and the discount trap
Reserved capacity and savings plans can cut a bill substantially, but only for workloads that will still exist when the term ends. A one-year commitment on a service the team is about to replace turns a saving into a stranded cost. Commit to the baseline you are confident about, not the peak you hope for.
Start with the steadiest workloads: the database, the core API, the storage that holds production data. Leave experiments and new products on demand pricing until their usage is predictable. A discount is only a discount if the thing you prepaid for is still useful in month twelve.
Tagging, budgets and alerts
A budget without tags is a guess. Tag every resource with an owner, an environment and a project, and enforce the tags at creation time where the platform allows it. Then build budgets per project and per environment, with alerts at fifty, eighty and one hundred percent. An alert that arrives after the spend is a notification, not a control.
Keep the tag schema small. Owner, environment and project cover most small teams; adding fifteen optional tags produces a spreadsheet nobody maintains. The point is to answer one question quickly: which team created this cost, and is it still needed?
- Group the bill by service, then by resource, before optimizing anything.
- Delete unattached storage, old snapshots and unused environments.
- Right-size one service at a time and watch latency and errors.
- Set lifecycle rules for logs and backups.
- Commit only to the baseline you expect to keep for the full term.
- Tag by owner, environment and project, with budget alerts.
A monthly cost review that takes an hour
Once a month, open the bill with the owner of each major service. Review the top ten lines, the new resources created since the last review, and the alerts that fired. Ask three questions: what grew, why, and what will we do about it. Record the answers in one place so the next review starts with context instead of a blank page.
For the architecture decision behind the bill, read our guide to serverless versus containers. For the tools that run on top of the infrastructure, see our Web Tools section.
