The cloud is cheaper is not automatically true

Moving your servers to the cloud exactly as they are, and paying list prices for them, will usually cost more than running them did. That is not a failure of the cloud, and it is not a scandal. It is the arithmetic, and it is the part of the pitch that gets compressed into a footnote.

So the answer to whether the cloud is cheaper than on premise is that it depends entirely on what you change. If you have already moved and the bill went up, you are not an outlier and nobody deceived you. You bought a change of location when the savings were in a change of design, and those are different projects with different costs.

The case for the cloud, put properly

The argument is strong and it is worth stating properly before disagreeing with the cheap version of it. You stop buying hardware three years ahead of needing it. You stop having capital tied up in machines that depreciate. You get capacity in minutes rather than in a purchasing cycle. You get resilience across locations that would be genuinely expensive to build yourself. You stop paying people to replace failed drives at ten at night. And you can try something, find it does not work, and switch it off having spent very little.

All of that is real, and for a business that is growing or uncertain it is worth a premium. The problem is not the cloud. It is the word cheaper, doing a job it cannot do without a great many conditions attached.

Is the cloud cheaper than on premise? Not by default

The comparison people run is the monthly cloud bill against the monthly cost of the servers. That comparison is wrong in both directions, and it flatters the wrong option depending on which side you were already on.

A server you own is bought once and then runs at close to nothing for four or five years, at whatever capacity you bought, whether you use it or not. That is inefficient, and it is also very cheap per hour once the money is spent. The equivalent rented machine is priced to include the hardware, the building, the power, the cooling, the network, the replacement cycle and a margin. Hour for hour it costs several times as much.

So if you rent the same shape of machine, keep it switched on constantly, and pay the standard rate, the number goes up. Nothing has gone wrong. You have converted a large one-off purchase into a permanent rental at retail, and rentals at retail are more expensive than owning. Everyone knows this about cars. It is somehow surprising about servers.

Where the savings actually come from

The savings are genuine, and every one of them requires changing how something runs rather than where it runs. That is the sentence the pitch tends to leave out.

• Switching things off. You are billed by the hour, so anything not needed overnight or at weekends should be off. Test and staging environments alone are a large saving for almost no risk, and this is the change with the best ratio of benefit to effort by a wide margin.
• Sizing to reality rather than to the peak. Owning a machine encourages buying for the worst hour of the year. Renting rewards buying for the normal hour and expanding for the bad one, and that only pays if something actually expands and contracts.
• Committing where the load is genuinely steady. Providers discount heavily for a commitment of a year or more. This is often the single biggest lever and it requires nothing technical, only the confidence to predict your own baseline.
• Using managed services instead of running your own. A managed database costs more per hour than a database you install on a rented machine, and less than the same thing plus the person maintaining it. The saving is in the salary, not the invoice, which is why it never shows up in a spreadsheet comparison.
• Deleting what nobody needs. Storage with no expiry, snapshots going back years, environments nobody has opened. Free to fix and immediately visible.
• Paying for actual use. Work that runs occasionally can be billed by the second rather than by having a machine waiting for it all month.

Notice that the first, second, fifth and sixth are all versions of one idea: you now pay for what you use, so using less costs less. If nothing about your usage changed when you moved, nothing about your cost was going to either.

The two surprises on every first bill

Two charges catch almost everyone, because neither is something you provisioned and so neither is something you thought to estimate.

The first is data leaving. Moving data out, and often between regions or zones, is charged, and it does not appear on any list of resources. In your own building, data moving between two machines was free and invisible. The same conversation between the same two services now has a price per gigabyte, and an application that chats constantly across a boundary can generate a startling line item without anyone doing anything wrong.

The second is the overlap. During a migration you run both estates at once, sometimes for months. The old hardware is still there, still depreciating, possibly still under support contract, while the new bill has already started. Every migration has this bulge and remarkably few budgets include it, which is why so many projects appear to overrun when they are in fact running exactly as planned. If your bill has jumped for a reason you cannot pin down, why did our cloud bill double works through the usual suspects in triage order.

When staying put is right

There is a real case for not moving, and it is not nostalgia.

• A steady, predictable workload on hardware you already own. No growth, no spikes, paid for. Renting the same thing at retail will cost more, and there is no lever available to close the gap.
• Heavy data movement in and out. Some workloads shift enormous volumes, and the transfer charges alone can outweigh everything else.
• Nobody to run it. The cloud does not remove the need for skill, it changes which skills. A team who knows your servers and does not know cloud operations is a real constraint, and pretending otherwise is how you end up with an expensive estate nobody has configured well.
• A genuine requirement about where data physically sits, which can be satisfied in the cloud but not always simply or cheaply.

If any of those describe you, staying is a legitimate engineering decision rather than a failure to modernise, and anyone who tells you otherwise is not doing arithmetic.

What to do if you already moved

1. Switch off what is not needed out of hours. Start with non-production. Largest saving, lowest risk, can be done this week.
2. Look at a month of real utilisation and resize what is obviously oversized, one thing at a time, checking peaks rather than averages.
3. Commit on the steady baseline. Whatever runs constantly should not be paid for at the standard rate. This is money for a decision, not for engineering work.
4. Set retention on storage and logs, so the line that only ever grows starts falling.
5. Find the transfer charges and work out what is talking to what across a boundary. Often one component explains most of it.
6. Then, and only then, consider redesigning something. Rebuilding a workload to suit the pricing model can pay well, and it is real engineering. Do the free things first.

The first five are usually enough to bring a badly-landed migration back in line, and none of them require rebuilding anything. That is the work in cloud cost optimisation, and if you are still planning the move rather than recovering from it, our migration work builds these decisions in rather than deferring them.

Not for you if

What to do differently: stop asking whether the cloud is cheaper, because the answer is that it depends entirely on what you change, and start asking what would have to change about how we run this for it to be cheaper. A supplier who answers that clearly is worth listening to. One who answers the first question with a yes is selling.