The Cloud Bill Nobody Can Explain

TL;DR / Key Takeaways

• Cloud bills are often full of idle, oversized, or forgotten resources that nobody is actively using.
• The four biggest cost categories to understand are compute, storage, egress, and managed services.
• Most small business cloud waste comes from things that were set up once and never revisited.
• You do not need to be an engineer to ask the right questions about your cloud spending.
• A basic monthly review of your top line items can catch waste before it compounds.

---

The Cloud Bill Nobody Can Explain

You get an invoice from AWS, Google Cloud, or Azure every month. It might be a few hundred dollars. It might be several thousand. Either way, nobody on your team can tell you exactly what you are paying for or whether it is all actually necessary.

That is more common than you might think. And it is a real business problem.

Cloud infrastructure has a way of growing quietly. Someone sets something up, it runs, nobody turns it off. A new service gets added during a project and stays running after the project ends. A vendor recommends a configuration that is bigger than what you actually need. Over time, the bill reflects the history of every decision made, not a thoughtful picture of what your business actually uses today.

This post walks through the main categories you will see on a cloud bill and what to question in each one.

---

Why Cloud Bills Are Hard to Read

Cloud providers do not bill like a normal vendor. You do not get an invoice that says "website hosting: $300." You get dozens or hundreds of line items with names like EC2, S3, CloudFront, RDS, NAT Gateway, Lambda, and a string of regional identifiers.

Each of those represents a different type of resource, and each one is billed differently. Some are billed by the hour. Some by the gigabyte. Some by how many times they are called. Some are flat monthly fees for managed services.

The result is a bill that is technically detailed but practically unreadable unless you already know what you are looking at.

Here is what to focus on.

---

Compute: The Servers Running Your Stuff

Compute is usually the largest part of a cloud bill. This covers virtual machines, containers, and serverless functions. Basically, anything that runs code.

The most common waste I see here is oversizing. A server gets provisioned at a large size because someone wanted room to grow, and it never gets right-sized once the actual usage is known. You end up paying for capacity you are not using.

The second most common issue is idle servers. A development environment that runs around the clock even on weekends. A test server from a project that shipped six months ago. A demo environment someone built for a prospect and forgot to shut down.

What to ask:

• Which servers are running continuously and do they need to be?
• What is the actual CPU and memory usage on those servers?
• Are there any servers that were spun up for a specific project that has since ended?

---

Storage: More Than Just Files

Storage on a cloud bill covers several different things. Object storage like S3 is used for files, backups, logs, and data. Database storage covers the space your databases consume. Disk storage is attached to your servers.

Storage is cheap per gigabyte, but it adds up when things are never cleaned up.

Log files are a common culprit. Systems generate logs, logs pile up, nobody sets a retention policy, and suddenly you are storing years of log data you would never actually look at.

Backups are another one. Backups are important, but automated backup systems will keep creating new backups unless you configure them to expire old ones. Old snapshots and backup files accumulate quietly.

What to ask:

• Are there automated log retention policies in place?
• How far back do backups go, and do they need to go that far?
• Is there any storage that is clearly associated with old projects or environments?

---

Egress: Paying to Move Data Out

Egress is the cost of moving data out of the cloud. Cloud providers generally let you bring data in for free, but they charge you to take it back out or to send it somewhere else.

This surprises a lot of people. You can store data for pennies, but if your system is pulling large amounts of data out of cloud storage repeatedly, those costs add up.

Common causes of high egress costs include:

• Applications that pull large amounts of data from cloud storage on every request instead of caching results
• Data transfers between cloud regions that were not accounted for
• Backups being downloaded regularly for verification instead of tested in place
• High-traffic files like videos or large downloads served directly from cloud storage instead of a content delivery network

What to ask:

• Is your cloud bill showing significant data transfer costs?
• Are large files being served directly from storage, or through a CDN?
• Are there cross-region data transfers that could be reduced?

---

Managed Services: Convenient but Easy to Overpay For

Managed services are things like managed databases, managed Kubernetes, managed search, managed queues, and managed caching. You pay the cloud provider to run and maintain the service so your team does not have to.

These are often worth the cost. But they are also easy to over-provision or to keep running when no longer needed.

A managed database cluster might have been sized for a workload that turned out to be much smaller. A managed search service might have been added during a project and kept running even though search is handled differently now. A managed Redis cache might be sitting mostly idle.

What to ask:

• What managed services are you paying for, and are they all actively being used?
• Were they sized based on actual usage, or based on estimates that were never revisited?
• Are there any managed services tied to old features or projects?

---

Where to Start Without Being an Engineer

You do not need to audit every line item yourself. But you do need someone who can.

If you have a developer or a technical person who helps you, ask them to pull up your cloud billing dashboard and walk through the top ten most expensive line items with you. For each one, you should be able to get a plain English answer to: what is this, do we need it, and is it sized correctly?

Most cloud providers also offer cost explorer tools that let you see spending by service, by time period, and by resource. A quick look at the trend over the past six months will often tell you whether costs are growing and roughly when they started growing.

Tagging is another thing worth asking about. Cloud resources can be tagged with labels like project name, environment, or owner. If your resources are tagged, it is much easier to see what is costing what. If they are not tagged, that is worth fixing before the infrastructure gets any more complicated.

---

The Honest Reason This Happens

Cloud waste is almost never malicious. It is the result of infrastructure that was built incrementally, often under deadline pressure, by people who were focused on making things work and not on long-term cost hygiene.

The fix is also incremental. You do not need a full infrastructure overhaul. You need someone to spend a few hours going through the bill methodically, identifying what can be turned off or right-sized, and setting up some basic hygiene so the same waste does not rebuild itself over the next year.

Part of what I do when working with clients on cloud infrastructure is exactly this kind of audit. Not to sell a rebuild, but to make sure the monthly bill reflects what the business actually needs.

---

A Simple Starting Point

Pull up your cloud bill from last month. Sort by cost, highest to lowest. Pick the top five line items. For each one, ask: do I know what this is, do I know why it exists, and does it need to be running at this size?

That five-question exercise will often surface at least one thing worth investigating further.

Cloud spending is not inherently complicated. But it does require someone to look at it with fresh eyes every so often. A bill that nobody can explain is a bill that is probably higher than it needs to be.