The cloud hosting bill is too high, and what is driving it

The conversation usually starts the same way. The bill was four hundred a month at launch, it is now fourteen hundred, traffic has roughly doubled, and nobody can explain the other half. Someone suggests moving providers.

Moving providers is the last move, not the first, and it is frequently the wrong one. A bill that grew without a matching change in usage is a bill with a shape, and the shape is legible once you stop looking at the total.

Read the bill by line item, not by total

Every major provider will break the bill down by service and by resource. Almost nobody looks, because the console defaults to a single number with a graph behind it, and that number is the least useful piece of information available.

Export one month of detailed billing and sort descending. In most small and mid-sized systems the top five lines are seventy to ninety percent of the bill, and at least one of them will be something nobody remembers creating. That is the whole diagnostic, and it takes about twenty minutes.

Do this before anyone proposes an architecture change. Optimising a service that is four percent of the bill is a way to spend a fortnight and save nothing.

Idle resources, which is almost always the first finding

• Staging and test environments running at production size, around the clock, for a team that works eight hours a day in one timezone.
• Database instances provisioned for a launch spike that never came and never got resized down.
• Load balancers and static IPs attached to nothing, which still bill.
• Snapshots and backups with no retention policy, accumulating since the first deploy.
• Log retention set to the default, holding verbose application logs for a year nobody will read.

None of this is incompetence. It is what happens when provisioning is fast and deprovisioning requires someone to be confident it is safe. The fix is unglamorous: an inventory, an owner per resource, and a scheduled shutdown for anything that is not production.

Non-production environments on a weekday schedule rather than running continuously is the single cheapest change available in most accounts, because it needs no code and carries no risk to live traffic.

Data transfer, the line that surprises people

Egress, meaning data leaving the provider's network, is the line item most teams never model. It is also the one where the providers differ most, and the differences are published rather than negotiated.

AWS documents on its EC2 on-demand pricing page that customers receive 100 GB of free data transfer out to the internet each month, aggregated across all AWS services and regions, excluding China and GovCloud. Past that allowance, outbound traffic is metered. The same page notes that customers moving all of their data off AWS can get free data transfer out for that migration, and that EU customers may request reduced rates for eligible use cases under the European Data Act.

Object storage is where the gap is widest. Cloudflare's R2 pricing documentation states that "There are no charges for egress bandwidth for any storage class", and prices standard storage at $0.015 per GB-month with Class A operations, meaning writes and listings, at $4.50 per million requests and Class B read operations at $0.36 per million. Its free tier is 10 GB-month of standard storage, one million Class A operations and ten million Class B.

If your system serves a lot of files, images, video, downloads, document archives, then egress may be a larger share of your bill than compute is, and the fix is to move that one workload rather than the whole system. A migration of an asset bucket is a weekend. A migration of an application is a quarter.

One caution on the free tiers above: they are per provider and they are small. A hundred gigabytes of egress is a modest amount of traffic for anything media-heavy, and ten gigabytes of object storage is a rounding error for an image library. Read them as a floor, not as a plan.

Storage that was never tiered

Storage grows monotonically and nobody notices, because each month's increase is small and the line never goes down. Two years in, it is a meaningful share of the bill.

Most providers offer cheaper classes for data you rarely read. Cloudflare's documentation prices its Infrequent Access class at $0.01 per GB-month against $0.015 for standard, with a $0.01 per GB retrieval fee and a 30-day minimum storage duration attached. That shape, lower storage price, retrieval charge, minimum duration, is common across providers, and it means tiering pays for archives and punishes you on anything read often.

The practical version: old backups, completed job artefacts and historical exports are good candidates. Anything a user might open is not.

The managed service premium, and when it is worth paying

Managed databases, managed queues, managed search. Each is more expensive than running the same software yourself, sometimes by a multiple, and for most teams each is still the right call. A managed database that costs three times a self-hosted one is cheap against one person spending a day a month on patching and backups, and far cheaper than the outage where the restore does not work.

So this is a line to examine, not a line to cut reflexively. The question is not whether the premium exists, it is whether you have more managed services than you have workloads, which happens when each was added for one feature and never reviewed. Consolidating three half-used managed services into one is a real saving. Self-hosting your production database to save money rarely is.

Commitments, and the conversation that gets you a discount

Once you know the steady-state floor of your usage, committed-use pricing is the lever with the largest single percentage attached. The trade is simple: you promise a baseline for one or three years, you pay less per unit.

Two rules keep this from becoming a trap. Commit to the floor you are confident of, not the average, because a commitment you undershoot is money spent on nothing. And do the cleanup first. Committing to a baseline that includes the idle staging cluster locks in the waste for three years.

Above a certain spend this stops being a console setting and becomes a negotiation with a salesperson, and it helps to understand how that side works. BDG Labs set out the levers that actually move in a procurement conversation in negotiating with procurement departments. It is written for the seller, which is exactly why it is useful to read before you sit on the other side of it.

The order of payoff

The last row is on the list because it is sometimes correct. It is last because teams reach for it first, and because a system rebuilt to save hosting costs usually spends more in engineering time than it will ever recover in invoices. The companion arithmetic is in what does a web app cost per month to run, which makes the same point from the other direction: hosting is rarely the number that decides the annual total.

What this does not cover

We have given no figure for how much a typical cleanup saves. We could quote one, and the numbers in circulation sit anywhere between ten and sixty percent, published mostly by companies selling cost-optimisation tooling, with no disclosed sample and no definition of a starting point. Our own experience is that a first pass on a neglected account finds a lot and a well-run account finds very little, which is not a percentage, it is a description.

The prices quoted above are from the providers' own published pages as they read today. They change, and they vary by region. Open the pricing page for your region before you build a comparison on them, and price your actual usage rather than the headline rate.

And one case where the answer is to do nothing. If the bill is a small fraction of revenue and the system is stable, the hours spent shaving it are hours not spent on the product. A thousand a month is worth a day of attention once. It is not worth a standing project. If the bill is genuinely large relative to the business, that is a different conversation and it usually starts with the cost of change rather than the cost of servers, which is the subject of software maintenance cost after launch.

If the system under the bill is an internal tool that grew out of a spreadsheet, the scoping question may matter more than the hosting one, and that is covered in internal tools for a small business.