Guided journey

Find the Money in Your Cloud Bill

A beginner journey: read an itemised bill, find idle resources, right-size the workload, fix egress, and verify the saving against the next invoice.

Beginner1 day9 milestones13 min read
You walk away with

A smaller bill you can prove: the biggest line items identified, idle resources removed, the workload right-sized, and a before-and-after figure from two real invoices.

Assume you have

At least two months of billing history, and the ability to change instance sizes and delete resources.

Stack used

Any cloud provider. The method is the same whether you deploy on a VPS, a PaaS, or a managed platform.

The project

Take the cloud bill you have been quietly avoiding and turn it into a list of decisions. You will find the largest line items, delete what nothing uses, size the workload to what it actually consumes, fix the traffic that leaves the network, and then check the next invoice to prove it worked.

By the end you will have: a ranked list of cost line items, idle resources removed, the machine right-sized against measured utilisation, egress reduced, and a before-and-after comparison from two real invoices.

Before you start

Milestone — Get the itemised bill, not the total

Build: a ranked list of the top five cost line items with their amounts.

A total tells you that you are spending money. The itemised bill tells you where, and the answer is usually one or two lines that dominate everything else.

Do it

  1. Export the last full month’s cost breakdown by service and by resource.
  2. Sort by amount and write down the top five, with the resource name against each.
  3. Mark each one as compute, storage, network, or a managed service.

Done when you can name the single largest item and say what it is. If the answer is “compute, in general”, go one level deeper until it is a specific resource.

Milestone — Find what nothing is using

Build: a list of resources with no traffic, no connections, or no writes in thirty days.

Idle resources are the cheapest thing to delete and the most common reason a bill is higher than the workload deserves. Nobody notices them because nothing breaks.

Do it

  1. List unattached storage volumes, old snapshots, and stopped-but-not-deleted instances.
  2. List development or staging environments that are running continuously and used occasionally.
  3. For each, check the metrics: if network and disk activity are flat at zero for a month, it is a candidate.
  4. Delete what you can prove is unused, and note what you kept and why.

Done when the idle list is empty or every remaining entry has a written reason to exist. How to Set Up Automated Database Backups covers snapshot retention, which is where old copies accumulate.

Milestone — See what the machine is actually doing

Build: a utilisation figure for every running instance, over the last month.

Right-sizing without measurement is guessing. You need one number per instance: how much of the CPU and memory it actually used at its busiest, not on average.

Do it

  1. Pull CPU and memory over the last thirty days for each instance.
  2. Record the peak, not just the mean — the peak is what determines the size you need.
  3. Flag anything whose peak is below about half its provisioned capacity as a right-sizing candidate.

Done when every instance has a peak utilisation figure attached to it. How Much RAM Does a Web App Actually Need? is the sizing method if you have never worked it out.

Milestone — Right-size, one instance at a time

Build: smaller instances where the measurement says they fit, changed in a window you can roll back.

Change one thing, watch it through a traffic peak, then change the next. Resizing several machines at once makes a failure unattributable.

Do it

  1. Pick the most under-used instance and choose a smaller size with headroom above its peak.
  2. Change it during a quiet period and confirm the app stays healthy.
  3. Watch memory and CPU through the next busy period before moving to the next instance.
  4. For a task that is not latency-sensitive, consider a cheaper class or a spot-style option instead of a smaller one.

Done when each instance has been resized from evidence, or has a note explaining why it is deliberately oversized. How to Choose a VPS Size for an AI-Built App and What Is a vCPU (and Why Isn’t It a Real Core)? cover the sizes; PC vs Data Center Server: Why a Server Looks Slower and Costs More explains why the bigger machine was not buying what you assumed.

Milestone — Look at what leaves the network

Build: a measured egress figure and at least one change that reduces it.

Traffic leaving the provider is priced far more aggressively than traffic arriving, and it scales with users. For anything that serves files or images, it is often a top-three line.

Do it

  1. Find the egress volume and its main sources in the bill.
  2. Put a CDN in front of the largest consumer so the origin sends each object far less often.
  3. Compress responses and serve media at the size it is displayed.
  4. Recheck the egress figure the following month.

Done when the egress amount has fallen and users still get what they asked for. What Is Egress Bandwidth (and Why It Shows Up on the Bill)? explains the destination pricing; What Is a CDN and Do You Need One? is the standard fix.

Milestone — Stop storing what you will never read

Build: a retention policy for logs, snapshots, and backups.

Storage costs grow slowly and never shrink on their own. Retention is the setting nobody changes, so the bill reflects data from a year ago that no one will ever open.

Do it

  1. Check log retention and whether logs are shipped somewhere that charges per gigabyte — What Is Log Rotation (and Why Do Your Logs Keep Disappearing)?.
  2. Set snapshot and backup retention to a deliberate window rather than the default.
  3. Move anything rarely accessed to a cheaper storage class, and confirm it can still be restored.

Done when every storage category has a stated retention period and the ones you set are shorter than the defaults.

Milestone — Now, and only now, consider a commitment

Build: a reservation or savings plan, if and only if the usage is stable.

Discounts are how a bill drops by a large percentage at once — and how you trap yourself paying for capacity you no longer need.

Do it

  1. Confirm the usage is stable for at least two months and unlikely to change.
  2. Commit to the smaller, right-sized footprint, not the old one.
  3. Prefer the shortest term that gives most of the discount.

Done when the commitment is smaller than the capacity you had before right-sizing, or you have decided against one and written down why. What Is FinOps? is the discipline this step belongs to.

Milestone — Prove the saving against the next invoice

Build: a before-and-after comparison of two complete billing periods.

A dashboard estimate is not evidence. The invoice is. Wait for a full period that includes your changes and compare it with the one before.

Do it

  1. Take the last complete bill before your changes and the next complete one after.
  2. Compare the same line items, not just the total, so a fall in one and a rise in another is visible.
  3. Confirm performance and uptime did not regress — a saving that costs availability is not a saving.
  4. Write the comparison into NOTES.md with the figures.

Done when the total is lower, the itemised changes explain why, and you have checked that nothing got slower. What Is Uptime Monitoring? is how you check the second half of that.

Milestone — Keep it from coming back

Build: a budget alert and a tagging rule.

Costs creep back through new resources, longer retention, and bigger instances added “just to be safe”. A review cadence and an alert keep the number visible.

Do it

  1. Set a budget alert below the level you would be unhappy to discover.
  2. Require a tag on every new resource that says who owns it and what it is for, so the next bill is attributable.
  3. Book a recurring fifteen minutes to read the bill, so the next leak is found early rather than annually.

Done when you would know within a week if the bill started rising again.

Ship checklist

  • Top five line items identified and ranked by amount.
  • Idle resources deleted; kept resources have a written reason.
  • Peak utilisation recorded for every instance.
  • Instances right-sized from measurement, one at a time.
  • Egress measured, CDN in place, payload compressed.
  • Retention set for logs, snapshots, and backups.
  • Commitment discounts applied only after right-sizing.
  • Two invoices compared line by line; performance unchanged.
  • Budget alert and ownership tags in place.

Where this journey goes wrong

  • Buying reserved capacity before right-sizing. You lock in the over-provisioning.
  • Resizing everything at once. You lose the ability to attribute a failure.
  • Deleting a resource nobody owns. Confirm it is unused rather than merely unlabelled.
  • Chasing the smallest instance. Spot and bursty instances can end up slower for less saving than expected.
  • Ignoring egress. For media-heavy apps it can be the largest single item.
  • Trusting an estimate over an invoice. The bill is the evidence.
  • Cutting cost and quietly cutting reliability. Measure both.

FAQ

Should I buy a commitment discount first?

No. Reserved capacity and savings plans lock in a machine size you have not yet validated. Right-size and remove idle resources first, then commit to the smaller footprint, or you will pay for the over-provisioning at a discount for a year. The discount multiplies whatever you had, which is good news only if what you had was right.

How do I prove the saving is real?

Compare two complete invoices, before and after, line by line, rather than trusting a dashboard’s estimate. A saving is only proven when the charged amount falls for a full billing period while performance and uptime stayed the same. Write the numbers down; the next time someone adds “just one more instance”, that table is the argument.

What is usually the biggest surprise on the bill?

Egress, followed by idle resources. Compute is what people watch, but data leaving the network is priced aggressively and scales with users, and unattached volumes and old snapshots accumulate without anyone noticing. For a media-heavy product, egress can exceed the compute cost outright.

Share: