Is your cloud bill too high? Seven places spend leaks

A cloud bill is too high when it grows faster than the business it supports, or when nobody can say what a major line on it is for. Spend usually leaks in seven places: oversized servers, idle resources, forgotten storage, data transfer, always-on test environments, log retention and commitments that do not match real use. Each one can be checked in the billing console in an afternoon.

How do you tell if the bill is really too high?

Do not judge a bill by its total. Judge it by what it buys.

Pick one business measure: customers served, orders placed, active users, pages delivered. Divide monthly cloud spend by it. Track the result month by month. If cost per order is flat while orders double, the bill is healthy. If it climbs while usage stays steady, something is leaking.

Then check ownership. Every resource should have an owner and a purpose. If your account has dozens of servers and nobody can say what half of them do, the savings start there.

The FinOps Foundation, which publishes a framework for cloud financial management, describes the cycle as inform, optimise, operate. That order matters. You cannot optimise what you cannot see.

1. Are servers bigger than the work they do?

Oversizing is the most common leak. A team picks a large instance to be safe at launch and never revisits it. Look at CPU and memory use over two to four weeks. If a machine rarely passes a modest level, move down a size and watch for problems.

AWS Compute Optimizer, Google Cloud's recommender and Azure Advisor all produce right-sizing suggestions from real usage. Treat them as leads, not orders, and check traffic peaks before resizing a production database.

2. Is anything running that nobody uses?

Servers from a finished project, a proof of concept someone forgot, a load balancer in front of nothing, database instances for a client you no longer serve. Idle resources bill by the hour.

List everything running, group by owner and ask each owner one question: do you still need this? Stop the ones nobody claims, wait a week, and delete if nobody complains. Snapshot first if unsure.

3. Is old storage piling up?

Storage is cheap per gigabyte and expensive in aggregate. Common sources:

• Unattached disks left behind after servers were deleted.
• Old snapshots and backups that no policy removes.
• Object storage buckets full of logs, exports and uploads nobody reads.
• Data kept in the fastest storage class when it is rarely touched.

Set lifecycle rules that move old objects to cheaper classes and delete them after a defined time. Check with whoever owns compliance before you shorten retention, because some data must be kept.

4. Where does data transfer cost come from?

Data transfer is the line items people notice last. Traffic that leaves a cloud region, goes between regions or availability zones, or passes through a managed NAT gateway is billed. A server in one zone talking to a database in another can add a charge on every request.

Look at the transfer lines in the cost report. Common fixes: keep chatty services in the same zone, serve images and files through a CDN, use private endpoints for storage access so traffic skips the NAT gateway, and compress responses.

AWS has also charged for public IPv4 addresses since 1 February 2024, including idle ones. Release addresses you do not use.

5. Are test and staging environments running all night?

A staging copy of production that runs around the clock bills at production rates for work done in office hours. Schedule non-production environments to stop in the evening and at weekends, or build them from code so they can be created on demand and destroyed after use. Developer sandboxes deserve the same treatment.

The saving is real, and the trade-off is small: a few minutes of start-up time each morning.

6. Are logs and monitoring costing more than the systems?

Log ingestion and retention can quietly outgrow the application. Debug-level logs left on in production, metrics with very high cardinality, and logs kept for years in a premium tier all add up.

Decide what you need and for how long. If you serve Indian customers, remember that the CERT-In Directions of 28 April 2022 require logs to be kept for a rolling 180 days within Indian jurisdiction (see the CERT-In rule explained). That is a floor for security logs, not a reason to keep everything at full volume forever. This is not legal advice; partner counsel advises on what applies to you.

7. Do your commitments match what you actually use?

Savings Plans, Reserved Instances and committed use discounts lower the unit price in return for a one-year or three-year promise. They pay off when load is steady. They hurt when you commit to machines that you later resize or retire.

The order is: remove waste, right-size, then commit to the baseline you are confident will stay. Cover your steady minimum, leave the peaks on regular pricing, and review the commitment each quarter.

What does a simple review process look like?

1. Switch on cost allocation tags: owner, project, environment.
2. Set a budget with alerts at a few thresholds.
3. Open the cost explorer, group by service, then by tag, and list the top five lines.
4. For each, ask what it is for, who owns it and what it would take to halve it.
5. Fix the easy items first: idle resources, old storage, schedules.
6. Re-check next month. A one-off clean-up drifts back without a habit.

What are the trade-offs?

Cutting too far has a cost. Smaller servers can slow the product at peak. Aggressive deletion can remove data you needed. Multi-year commitments reduce flexibility. A review should lower the bill without lowering reliability, so make changes in small steps and watch the results.

Time is a trade-off too. A founder or developer who spends a day each quarter on this will usually do better than a heroic clean-up once every two years.

Where does TechSum fit?

We review cloud accounts, find the leaks, make the changes with you, and set up the budgets and alerts that keep them from returning. The Cloud Cost Review is a short fixed-scope starting point that ends with a written report. More detail is on the cloud cost optimisation page and under Digital Infrastructure. You can also run the free health check on the public side of your setup.