What the Cloud Bill Does Not Tell You About the Hardware You Need

Written and maintained by Haink's infrastructure team · Updated 29 August 2026 · authorized-channel sourcing, export-screened, serial-verified

There are two cloud exits and they are not the same project. One is about AI and GPUs, where the driver is usually that renting accelerators has become more expensive than owning them; we cover that in cloud-exit AI infrastructure. The other is the ordinary one — virtual machines, databases, file shares, the things that were lifted and shifted years ago and never got cheaper — and it is far more common.

This page is about the second. The arithmetic is different, the biggest mistakes are different, and the single most consequential one happens in the first ten minutes: reading the cloud bill as if it described hardware.

A cloud vCPU is not a core

On most general-purpose instance families a vCPU is a hardware thread, not a physical core. Two vCPU therefore map to roughly one physical core, not two. An estate reporting 1,200 vCPU is in the region of 600 physical cores of demand, not 1,200 — and sizing hardware from the vCPU figure buys roughly twice the compute required, at roughly twice the licence cost, forever.

Check the instance families you actually run, because the ratio is not universal — some instance types expose physical cores, and some workloads were sized for burst behaviour they will not have on dedicated hardware. But start from the assumption that the vCPU number in your bill is not a core count, and confirm it before anything downstream depends on it.

Three more translation errors in the same family:

• Provisioned is not consumed. Cloud instances are sized for peak and often for a peak that never arrived. Size the replacement from sustained utilisation metrics, not from the instance catalogue — the same discipline that governs HCI cluster sizing.
• Provisioned IOPS is a purchase, not a requirement. Storage tiers were frequently chosen once and never revisited. Measure what the workload actually demands before specifying flash.
• Multi-AZ resilience is not free on-premises. What the cloud absorbed as a checkbox becomes a second site, a second set of hardware, or an explicit decision to accept lower availability. That decision belongs in the business case, not in the deployment.

The egress question changed, and most plans have not caught up

For years the standing objection to repatriation was that moving the data out would cost more than the move saved. That changed in early 2024, when all three major providers introduced free-egress-on-exit programmes — Google Cloud in January, AWS and Microsoft in March — under regulatory and competitive pressure. The UK's Competition and Markets Authority examined these free-switching programmes as part of its cloud market work.

What has not changed is that the programmes carry conditions: application processes, requirements about the scope of what you are moving, and time limits. Do not budget egress at list rate, and do not budget it at zero. Confirm in writing whether your specific case — including a destination that is your own data centre rather than another provider — qualifies under the programme, and on what timetable. Both of the lazy assumptions are wrong often enough to matter on a six-figure programme, and the answer takes one support ticket to obtain.

What comes back, and what has to be rebuilt

The compute and storage lines on a cloud bill map reasonably cleanly onto hardware. The rest does not, and the rest is where repatriation business cases fail.

The managed-services row deserves emphasis. A managed database instance bundles the engine licence, patching, backup, failover and monitoring into one hourly rate. On-premises those are five separate things, at least one of which is a licence and at least two of which are people. Repatriating a database estate without pricing that bundle is the most reliable way to produce a business case that looks excellent and delivers nothing.

Building the comparison honestly

1. Take twelve months of billing, not one. Seasonality, reserved-instance expiry and committed-use discounts all distort a single month. Annualise, and note where discounts run out.
2. Translate the estate to physical demand. vCPU to cores at the correct ratio, provisioned capacity to consumed capacity, provisioned IOPS to measured IOPS.
3. Size the hardware from that — then add resiliency overhead and the platform's own floor. If the destination is hyperconverged, the raw-capacity factors are in sizing an HCI cluster.
4. Price the software separately. Hypervisor, operating systems, database engines and management tooling, all on the licensing units that now apply — which for virtualization means physical cores. This line is frequently larger than the hardware.
5. Add the rebuilt services — backup, monitoring, load balancing, DR — as real line items with real products behind them.
6. Add facilities — space, power at your tariff, cooling, and any per-rack power work the new density requires.
7. Add the migration itself — the move, parallel running while both sides are live, and the people doing it.
8. Compare over three to five years, not one, because hardware is capital and cloud is operating expenditure and a one-year comparison always flatters the cloud.

Where the destination hardware is a meaningful part of the estate, the procurement mechanics at that scale are in buying twenty to sixty servers as one project, and the platform choice underneath it in Lenovo vs Dell vs HPE.

What to bring home first

Repatriation works best as a sequence rather than a single event, and the ordering is not arbitrary. The workloads that pay best are the ones the cloud pricing model suits least:

• Steady-state, predictable compute. Anything running at a flat utilisation twenty-four hours a day is paying a premium for elasticity it never uses.
• Storage-heavy, access-light data. Large volumes that mostly sit there are the clearest arithmetic in the whole exercise.
• Egress-heavy workloads. Anything shipping large volumes out continuously — media, backups leaving the provider, data feeds to partners.
• Workloads with a residency or sovereignty requirement that the current region does not satisfy. Here cost is not the driver at all.

And what to leave, at least initially: genuinely spiky or seasonal workloads, anything that depends deeply on a managed service you would have to rebuild, development and test environments that benefit from being disposable, and anything already scheduled for replacement.

When the driver is residency rather than cost

A growing share of these projects are not cost exercises. The requirement is that specific data sits in a specific jurisdiction, under a specific legal framework, with demonstrable control — and no amount of cloud region selection satisfies an auditor who wants to know who could be compelled to hand it over.

When that is the driver, the arithmetic changes shape. "Slightly more expensive than the cloud" is an acceptable answer, because the alternative is not the cloud — it is not operating in that market. What still needs doing is the sizing, so that the compliance requirement is met at the right cost rather than at whatever the first quote said. Where sovereignty is the frame rather than residency alone, our sovereign stack work covers the wider decision.

When repatriation does not pay

• When the workload is genuinely elastic. If peak is many times average and the peak is unpredictable, you would be buying hardware for a peak that idles most of the year.
• When the estate depends on managed services you cannot economically rebuild. Price the rebuild before assuming it away.
• When you do not have the operations capability. Running infrastructure is a staffed function. If that team was disbanded during the migration to cloud, rebuilding it is part of the cost.
• When there is no facility. Colocation is a real answer, but it is a cost line and a contract, not an assumption.
• When the three-to-five-year comparison is close. A marginal saving is not worth a migration programme's risk. Repatriate when the number is clear, or when the driver is not cost at all.

Frequently asked questions

How do we convert cloud vCPU into physical cores?

On most general-purpose instance families a vCPU is a hardware thread, so two vCPU map to roughly one physical core. Verify against the instance types you actually run, because some expose physical cores instead. Sizing hardware directly from the vCPU count typically buys about twice the compute needed, and about twice the per-core licence with it.

Will egress fees make repatriation uneconomic?

Less likely than it used to be. Google Cloud, AWS and Microsoft all introduced free-egress-on-exit programmes in early 2024, and the UK Competition and Markets Authority examined these free-switching programmes in its cloud market work. The programmes carry conditions and timetables, so confirm in writing whether your specific move — including to your own data centre rather than another provider — qualifies, rather than budgeting at list rate or at zero.

What is the most under-estimated cost when leaving the cloud?

Managed services. A managed database rate bundles the engine licence, patching, backup, failover and monitoring into one hourly figure. On-premises those become separate licences, products and people. Repatriating a database estate without pricing that bundle is the most common way a business case looks excellent and delivers nothing.

Which workloads should we repatriate first?

Steady-state compute running flat around the clock, storage-heavy and access-light data, anything shipping large volumes of egress continuously, and anything with a residency requirement the current region cannot satisfy. Leave spiky or seasonal workloads, disposable development environments, and anything deeply dependent on a managed service you would have to rebuild.

How far ahead should the comparison run?

Three to five years. Hardware is capital with a service life; cloud is an operating cost that recurs. A one-year comparison structurally flatters the cloud and is the reason repatriation cases are sometimes dismissed before the arithmetic is finished.

What if the driver is data residency rather than cost?

Then the comparison is not against the cloud bill, it is against not operating in that market, and being slightly more expensive is an acceptable outcome. The sizing work still matters, so that the requirement is met at a defensible cost rather than at whatever the first quote proposed.

Do we need our own data centre?

No — colocation covers most cases and removes the facilities capital from the decision. But it is a contract and a cost line with its own power, space and cross-connect pricing, not a rounding error, and it belongs in the model from the start.

Related

• Cloud-exit AI infrastructure — the other repatriation, where the driver is GPU economics
• Sizing an HCI cluster — translating demand into nodes once the destination platform is chosen
• VMware exit — the hardware decision — frequently the same project, arriving from the licence side
• Lenovo vs Dell vs HPE — the platform choice for the destination hardware
• Buying 20–60 servers as one project — how hardware at this scale is actually purchased
• Cloud exit assessment · sovereign stack · infrastructure audit
• Sovereign cloud infrastructure — 40 nodes, 7,680 vCPUs, 96 TB NVMe, national data residency

Sources

• UK Competition and Markets Authority — Appendix N: egress fees and free switching programmes
• AWS follows Google Cloud in cancelling egress fees for customers leaving (March 2024) · Microsoft joins AWS and Google Cloud on free data egress
• Data Center Dynamics — AWS removes some data transfer fees for customers exiting (note the scope qualifier)
• Microsoft Learn — fault tolerance and storage efficiency (resiliency overhead used when sizing the destination)