Cloud billing is pay-as-you-go, which means a mistake costs money the moment it is made and keeps costing until someone notices. Most surprises are not clever: a forgotten test cluster, a disk that outlived its machine, a log that grew without limit. A handful of habits catches nearly all of them.
Make cost visible first
You cannot manage what nobody sees. In the first week:
- Turn on cost reports and alerts. A budget with alerts at 50, 80 and 100 percent means a problem shows up during the month, not on the invoice.
- Tag everything. An owner tag, a project tag and an environment tag are enough to start. Enforce them with policy, because untagged resources are the ones nobody claims.
- Read the bill by service and by tag. The first reading usually shows something nobody expected.
Remove waste
Waste is spending on things that deliver nothing. It is the easiest saving because nothing changes for users.
- Stopped virtual machines whose disks still bill.
- Volumes not attached to anything, and snapshots nobody will restore.
- Idle load balancers, IP addresses and databases.
- Development and test environments running at night and weekends.
- Oversized machines running at a few percent CPU.
Review these with the owner before deleting: the unattached volume may be the only copy of something. A good habit is to stop or snapshot first, wait a week, and delete only if nobody complains.
Right-size and use the right tier
Choose machine sizes from measurements, not guesses: a couple of weeks of CPU and memory usage will show what you really need. For storage, look at how often data is read. Rarely accessed data belongs in a cheaper class, and lifecycle rules can move or delete it automatically after a set time.
The costs people forget
- Data transfer. Traffic leaving the cloud or crossing regions or availability zones is charged. Architectures that move large data between services across regions can cost more in transfer than in compute.
- Logging and monitoring. Verbose logs are stored and indexed at a price. Set retention and sampling.
- Managed service tiers. A database sized for peak load that arrives once a year.
- Free tiers that end. Check what changes after a trial period.
Commitments, carefully
Providers discount in return for committing to a level of use for one or three years. These suit stable, long-running workloads. Commit only after months of data, start with part of your baseline, and keep room for change. A commitment on a workload you later retire is waste with a contract attached.
Build it into how you work
A one-off clean-up fades. What lasts is routine:
- A monthly review of the biggest items and changes, with a named owner for each action.
- Cost in design reviews: what it costs at the expected load, and at double.
- Guardrails: budgets, quotas and limited permissions, so one mistake cannot create an unbounded bill.
The aim is not the lowest possible bill. It is that every pound spent is on purpose, with someone who knows why.
Checklist
- Set a budget for each account or project, with alerts at several levels (for example 50, 80 and 100 percent of the forecast), sent to people who can act on them.
- Turn on the provider's cost reporting and anomaly detection, and look at the first bill line by line, not only the total.
- Tag every resource with an owner, a project and an environment, and enforce it. Cost you cannot attribute to someone is cost nobody will reduce.
- Find and remove idle resources: stopped machines that still have disks, unattached volumes, old snapshots, unused load balancers and IP addresses, forgotten test environments.
- Switch off non-production environments outside working hours where it is safe to do so.
- Match machine sizes to measured use. Check CPU and memory over a couple of weeks before resizing, and resize in steps.
- Use storage tiers: move rarely accessed data to cheaper classes, and set lifecycle rules that expire temporary files and old versions automatically.
- Watch data transfer. Moving data out of a cloud, between regions, or through NAT gateways can cost more than the storage itself, so keep chatty services in the same region.
- Consider committed-use or savings plans only for steady workloads you have measured for months, and start with a portion of the baseline, not all of it.
- Put cost in the design review. Ask what a new service costs per month at the expected load, and what happens to the bill if usage doubles.
- Hold a short monthly review: the top five cost items, the biggest changes since last month, and a named action for each.
- Protect against runaway costs: quotas and limits on accounts, restricted permissions to create expensive resources, and care with anything that scales automatically without a ceiling.
Frequently asked questions
What is FinOps?
A practice that brings engineering, finance and business teams together to manage cloud spending: making costs visible, assigning them to owners and optimising continuously.
Where does the money usually go?
Compute and storage lead, but data transfer, managed database tiers, logging volumes and forgotten resources are common surprises. Your own bill will tell you, so read it.
References
From Grokem: https://www.grokem.com/cloud/cloud-cost-management/finops/cloud-cost-control-checklist
