Why your cloud bill keeps growing and how to cut it without breaking anything
The five reasons a server bill grows on its own month after month, how to find them without being an expert and what can be cut the same day without touching what is in production.
· Cloud architecture
The cloud bill has an uncomfortable property: it never goes down on its own. It starts at a reasonable figure, somebody switches on a machine for a test, somebody else uploads a few files, and eighteen months later you are paying three times as much without the business having grown threefold.
What follows are the five causes that turn up practically every time.
1. What was switched on for a test and is still switched on
It is number one by a distance. A server raised to try something out, a test environment for a project that finished long ago, a database duplicated «just in case». Nobody switches them off because nobody knows whose they are.
How to find them: look at CPU use over the last month. Anything that has spent thirty days below 5 % either does nothing or is oversized. Both cost money.
2. Disks and backups nobody deletes
When a server is deleted, its disk often survives and keeps being billed. The same happens with automatic snapshots: if nobody set a retention policy, copies pile up from every day since the beginning of time.
An important caveat here: before deleting a backup you need to know what retention obligation you have. In accounting and tax matters there are legal periods for keeping documentation, and saving twenty euros a month by destroying what has to be kept is a bad deal.
3. Storage in the wrong class
Providers offer several storage classes: the expensive, fast one for what is read daily, and the cheap ones for what is hardly ever touched. Almost everybody leaves everything in the expensive one.
Moving historical files to a cold class — invoices from three years ago, old backups, material only looked at if there is an inspection — usually cuts a noticeable slice of the bill with no operational consequence at all.
4. Outbound traffic
The cost nobody sees coming: taking data out of the provider is charged for. Putting it in, usually not. If your application serves images or heavy downloads straight from the server, money leaks out of there every day.
The usual fix is to put a content delivery network in front, so the file is served from cache instead of leaving the origin every time.
5. Paying by the hour for what runs all year
The default price is pay-as-you-go, which is the most expensive per hour. For whatever you know will stay switched on twelve months in a row, providers offer one- or three-year commitments with considerable discounts.
The prudent rule: commit only the stable part of your consumption — the part you have been paying for a year whatever happens — and leave the rest flexible. Over-committing is swapping one problem for another.
How to do it without breaking production
- Tag everything by project and owner. Without tags, the bill is a list of anonymous resources and nothing can be decided.
- Switch off before deleting. You switch it off, wait a week, and if nobody has complained, you remove it. It is slow and it is the difference between saving money and causing an outage.
- One change at a time, with a day in between. If something fails, you know what it was.
- Set a spend alert before touching anything. If next month the bill goes up again, you want to know on the 5th, not on the 30th.
And the awkward question: do you need the cloud?
For many small businesses, the honest answer is not entirely. A corporate website and email do not need elastic infrastructure: they need decent hosting. The cloud pays off when the load varies a lot, when you have to scale fast or when the service cannot go down.
If your bill comes from having built with large-enterprise architecture something that serves two hundred visits a day, the saving is not in optimising: it is in simplifying.
If this sounds like you
We go through the bill with you and come out with a concrete list of what gets switched off, what gets moved and what gets committed, ordered by what it saves: we review your cloud bill. If what lies behind it is an architecture that has to be rethought, that is cloud architecture. And if you are worried that cutting backups will leave you without what the law requires you to keep, that goes into the review too: which retention period applies to each kind of record before any backup is touched.
We are Mindset & Code: automation, data and development for small businesses. We look at the cloud bill alongside what has to be kept by law, which is exactly what gets forgotten when only usage is looked at. You can see what we do and what it costs.
General guidance. Prices, storage classes and commitment discounts are set by each provider and should be checked against their current rates before deciding.