Cloud: What Gets Cheaper, What Gets More Expensive

The cloud pitch is that you stop buying servers and start renting capability, paying only for what you use. That is true, and it is incomplete.

What actually happens is that cost moves from a large predictable capital purchase to a variable operating expense that grows quietly unless someone watches it. Whether that is better depends entirely on your workload — and on whether anyone is watching.

Where the economics genuinely work#

Variable or unpredictable load. If demand triples for two weeks a year, renting beats buying capacity that idles for the other fifty.

Things you would not build yourself. Managed databases, content delivery, object storage at extreme durability. Reproducing these in-house is expensive and usually worse.

Starting something new. No capital, no procurement cycle, no data-centre commitment. Being wrong costs a month rather than three years.

Global reach. Serving users on another continent becomes a configuration change rather than a project.

Disaster recovery. A standby environment you pay for only when testing or using it is dramatically cheaper than a second physical site.

Where it does not#

Steady, predictable, always-on load. This is the honest one. A workload running at constant utilisation year-round is frequently more expensive rented than owned. The cloud's pricing advantage comes from elasticity, and a workload that never flexes captures none of it.

Large data egress. Moving data out is charged per gigabyte by every major provider. Workloads serving large files can find transfer dominating the bill.

Lift-and-shift with no redesign. Moving virtual machines unchanged captures almost none of the benefit and adds the rental margin. This is the most common way cloud migrations disappoint.

Anywhere nobody owns the bill. Cloud spend grows by default. Without a named owner and a monthly review, most organisations accumulate 20–30% waste.

The costs that surprise people#

Consistent across providers:

• Data transfer out, and between availability zones
• Idle resources — stopped machines still bill for storage; unattached addresses bill; load balancers with no traffic bill
• Non-production running overnight and at weekends. Roughly two-thirds of the hours in a week are outside working time. Switching development environments off is usually the single largest saving available.
• Storage nobody deletes — snapshots, old backups, logs with no retention policy
• Managed-service premiums on workloads that did not need managing

What to keep portable#

Complete portability is a fantasy that costs more than the lock-in it avoids. Complete dependence is a negotiating position you will regret. A workable middle:

Keep portable: your data, and a tested ability to export it. Container images. Infrastructure as code, even if provider-specific — at least the intent is documented. Standard database engines where the difference is small.

Accept dependence on: identity, networking, managed databases and the operational services that genuinely save you work. That is where the productivity is, and rebuilding them to stay portable is usually a bad trade.

The question to ask of any proprietary service: if this vanished, how long to replace it? Weeks is acceptable. A year means it is a strategic dependency and should be a conscious decision.

Multi-cloud, honestly#

Running across two providers to avoid lock-in is usually a mistake below very large scale. You get the complexity of both, the volume discounts of neither, and a team that knows each half as well.

Legitimate reasons: a regulator requires it, an acquisition brought a second estate, or a service you need exists on only one. "Negotiating advantage" rarely survives contact with the engineering cost.

Repatriation#

Moving workloads back on-premises has become a real pattern, and it is not an admission of failure. It makes sense for steady, high-volume, predictable workloads — particularly storage-heavy or compute-heavy ones with stable demand.

The mature position is that cloud is a tool, not an identity. Steady workloads on owned hardware and variable or new workloads in the cloud is a coherent architecture, not a compromise.

What makes repatriation possible is the portability decisions above. What makes it impossible is building everything on proprietary services without noticing.

Controlling spend#

Practical and mostly unglamorous:

1. Budget alerts on day one, before the first workload
2. Mandatory tags — owner, environment, cost centre. Untagged resources are never deleted because nobody dares
3. Turn off non-production outside working hours — automate it
4. Retention policies on logs, snapshots and backups
5. Right-size against measured usage, not the specification someone guessed
6. Commit only to your provable baseline with reserved capacity, never to hoped-for growth
7. Review the top ten line items monthly with someone who can explain each

The first three typically recover more than the rest combined.

FAQ#

Is the cloud cheaper than our own servers?#

For variable load, new projects and services you would not build yourself — usually yes. For steady always-on workloads — frequently no. An honest answer requires comparing your actual utilisation profile, including the staff time each option needs.

Which provider should we choose?#

For most workloads the technical differences matter less than existing commitments, your team's skills, and where data must reside. Pick one and go deep; spreading thin costs more than it saves for all but the largest organisations.

Is our data secure in the cloud?#

Provider infrastructure security is almost certainly better than what you would run yourself. The shared responsibility model means they secure the platform and you secure your configuration — and essentially all publicised cloud breaches have been customer misconfiguration, most commonly a storage bucket left publicly readable.

What about data residency?#

Every major provider offers regional deployment, and this is a decision to make deliberately at the start — moving data later is a project. Note that support access and backup replication can cross regions even when your primary data does not; check both.

How long does a migration take?#

Lift-and-shift of a simple application: weeks. Re-architecting to actually benefit: months. Whole estates: years, and typically longer than planned because undocumented dependencies surface. Migrate one workload end to end first — you learn more from that than from any assessment exercise.

What is the most common expensive mistake?#

Nobody owning the bill. Cloud spend is thousands of small decisions made by people who cannot see the cost of theirs. A named owner and a monthly review catches more than any optimisation tool.

Should we go serverless?#

For event-driven work with spiky load it is often excellent and genuinely cheap. For steady high-volume workloads it can cost more than a server that is simply always on. It also constrains runtime and execution duration — check those limits against your workload before committing.

What else is coming for Cloud