Cloud costs: where they come from and when an exit pays off

Why the invoice grows faster than the load

Public cloud pricing is built for elasticity: if you need resources only by the hour, you pay only by the hour. The reverse does not follow. If you need resources permanently, you pay the elasticity premium permanently, and that is exactly where the bulk of enterprise workloads sits.

Four drivers turn up in almost every cloud bill that has grown over time:

• Data transfer. Compute and storage are predictable, data leaving the platform is not. It grows with the success of the application, not with the capacity you planned.
• Reserved headroom. Instances are sized for the peak and then run around the clock. Test and staging environments run through nights and weekends as well.
• Side items. Premium support tiers, control plane fees for managed services, snapshots, load balancers, cross-zone traffic. Small individually, a cost block in total.
• Discount models nobody maintains. Reservations and committed-use agreements give up to 72 to 75 per cent off depending on provider and term. Flexera found in 2026 that fewer than half of organisations use a commitment model with any given provider at all.

How quickly this tips shows up in practice at two positions above all: data transfer and storage grow with every new service, without anyone having taken that decision consciously. Read the invoice only as a total and you notice it once it has multiplied. That matches what McKinsey observed in 2024 across around 450 CIOs: organisations spend on average 14 per cent more on cloud transformations than planned, and only around 10 per cent of those programmes deliver their value case in full.

The TCO calculation tips on the items nobody enters

TCO stands for total cost of ownership, meaning the full cost across the life cycle rather than the invoice for the current month. The term is used as an argument far more often than it is used as a calculation. A comparison that holds up puts public cloud, private cloud and your own data centre side by side across nine positions:

1. Compute
2. Storage
3. Data egress
4. Staff for operations and on-call cover
5. Hardware depreciation
6. Power
7. Colocation or data centre rent
8. Hardware lifecycle management
9. Control plane and administration fees

Two positions decide the comparison almost every time. The first is staff. Running your own infrastructure means real on-call cover, and no single person can carry that. Calculations that set owned hardware against a cloud invoice and leave the operations team out are incomplete. Given the 109,000 unfilled IT positions in Germany that Bitkom recorded in 2025, the question is not only what staff cost but whether they are available at all.

The second is the administration premium on managed services. A managed Kubernetes service costs around 0.10 US dollars per hour and cluster regardless of utilisation, roughly 73 US dollars a month. With one cluster that is a footnote. With forty clusters it is a line item.

How large the gap turns out to be depends on the profile. An even baseline load with a lot of storage and data transfer almost always favours owned or dedicated infrastructure in a comparison; sharply fluctuating load with short peaks speaks for the public cloud. The statement only becomes reliable with your own figures, which is why every project starts with a survey of actual usage.

FinOps means attribute first, then reduce

The most common mistake in saving money is the order of operations. Instance sizes get adjusted before anyone knows which team, which product and which environment causes which share of the invoice. FinOps describes exactly that discipline: cloud costs are attributed to an originator, made visible, and only then steered.

In practice it consists of three steps. First, consistent tagging of every resource by team, product and environment, because without clean attribution every measure is guesswork. Second, a monthly cost model that splits the invoice by originator and shows the variance against the previous month. Third, a governance rule that settles who may create resources, who answers for their cost, and when unused things disappear automatically.

The effect is organisational rather than technical. As long as the cloud bill is a single number in an IT cost centre, nobody has a reason to change anything. Once it is attributed to a product, it becomes part of that product's economics. That the largest unused lever sits here is what the Flexera survey of 2026 shows: 29 per cent of spend on infrastructure and platform services counts as wasted, 17 per cent of organisations exceeded their cloud budget, and 85 per cent name cost management as their biggest challenge.

Most levers work without a single machine moving

Changing provider is the largest lever and also the slowest. Ahead of it sit measures that take effect within weeks and trigger no architecture project. This is what cloud cost optimisation looks like in practice:

• Right-size. Instances are almost always chosen for the peak and run at low utilisation in daily life. Measure, then shrink.
• Switch off what is not needed. Test and development environments rarely need 24 hours a day. A schedule saves here without risk.
• Sort storage classes. Old snapshots, logs and backups often sit on the most expensive class long after anyone last read them.
• Shorten data paths. Traffic between availability zones and regions is a cost item of its own. Services that talk constantly belong together.
• Maintain discount models. For the share of load that runs permanently anyway, reservations and commitment agreements are the most direct discount available. The term should be shorter than the half-life of the architecture.
• Review the support tier. Premium support is often switched on once and never questioned again.

The list is deliberately unspectacular. It is the reason an analysis comes first and a move second. Only once the invoice is clean can you judge whether the remaining amount is down to the platform or to how it is being used. These levers are set out in more detail in our articles on cost management in the cloud and on controlling your cloud costs.

An exit pays off for a stable baseline load, not everywhere

Once the invoice has been cleaned up, the real question remains: is this workload in the right place? It is answered per workload, not as a policy for the whole organisation. Four characteristics argue for a move into a private cloud or your own data centre:

• Stable baseline load. The application runs around the clock at a similar size. Elasticity is paid for but not used.
• Large volumes of data in motion. Egress is a noticeable share of the invoice.
• Long life expectancy. The application will still exist in five years, so an investment amortises.
• Regulatory requirements on location, access and evidence that have to be met in any case.

The counter-picture argues against: sharply fluctuating or seasonal load, a short project life, heavy use of provider-specific services with no equivalent elsewhere, or a small team with no operations crew. Pull those workloads back and you trade a cost problem for an operating problem.

How large the effect can be in the favourable case is visible in one project from our own portfolio: a content provider with more than 50 self-built services in AWS reduced platform and service costs by 75 per cent after the exit, at unchanged availability. That is the highest figure we have documented, a single case and explicitly not a benchmark. The reliable statement is not the percentage but the method: calculate first, decide second.

Egress fees are the price of data becoming heavy

Egress describes data leaving a provider's cloud for the internet or for another provider. The way in is usually free, the way out is not. List prices sit at around 0.09 US dollars per gigabyte at AWS, around 0.087 at Azure and around 0.12 at Google Cloud, each for the first pricing tier. At a few terabytes a month that is a side item. At petabyte scale it becomes a five- or six-figure annual sum, and out of that sum comes the effect known as data gravity: the larger the estate, the more expensive every movement, and the less likely the switch.

The regulatory picture has changed. The EU Data Act entered into force on 11 January 2024 and has applied since 12 September 2025. It bans charges levied purely for switching provider entirely across the EU from 12 January 2027. AWS, Google and Microsoft dropped switching charges under conditions back in 2024.

The second part of lock-in is contractual and technical. BEREC and Beltug found usable exit clauses in fewer than 5 per cent of cloud contracts in their survey, and AWS names six dimensions of lock-in in a whitepaper of its own. How deep the binding goes depends less on the contract than on the architecture. Anyone using only virtual machines and object storage moves comparatively easily. Anyone who has built provider-specific databases, queues and function services deep into the application rebuilds parts of it when moving. There is more on this in our pillar on vendor lock-in.

An outage at the hyperscaler costs you, not them

Cost is only one half of the calculation. The other is the risk that comes with concentrating on a handful of providers. Three incidents of recent years show the order of magnitude. The outage in the AWS region US-EAST-1 in October 2025 lasted around 15 hours and affected more than 1,000 services worldwide. Google Cloud was down for over three hours in June 2025. The faulty CrowdStrike update in July 2024 disabled around 8.5 million Windows systems.

What matters is what happens contractually in such a case. The availability commitments of AWS, Google and Microsoft are written as the sole and exclusive remedy. Anyone affected receives a percentage credit against future invoices. No payout, no compensation for lost revenue, no liability for data loss or reputational damage. In economic terms: the outage costs the customer, and it costs more than the credit is worth.

Supervisors now take the same view. The Bank of England designated AWS, Microsoft, Google Cloud and Oracle as Critical Third Parties for the UK financial sector on 10 July 2026. For regulated organisations in the EU, NIS2 and DORA ask comparable questions about substitutability and recovery.

The practical consequence is rarely to pull everything out. It is the question of whether the services the business depends on have a recovery path that does not assume the same provider. That is the point at which a hybrid or multi-cloud strategy stops being a slogan and becomes an architecture decision with a price tag. Searches for an AWS outage or an Azure outage spike on the day; the architecture decision has to be made long before.

Cloud repatriation: what the numbers actually support

For some years the claim has circulated that organisations are leaving the public cloud in large numbers. The surveys contradict each other less than it appears, once you read what each of them counts.

The Barclays CIO survey arrives at 83 to 86 per cent of the CIOs polled planning some repatriation. What it counts is organisations, not workloads and not budgets: one service brought back is enough to land in that share. The trade publication Channelnomics therefore considers the figure misleading. IDC arrives at 8 to 9 per cent of organisations planning a complete move back. Gartner calls repatriation the exception rather than the rule and observes geopatriation instead, meaning a move into a particular legal jurisdiction rather than out of the cloud. A survey by OpenText in the Nutanix Enterprise Cloud Index names 67 per cent that have already brought individual workloads back and 87 per cent planning to do so within the next 12 to 24 months.

Taken together the picture is clear. Partial repatriation of individual workloads is widespread and growing. A complete withdrawal from the public cloud is rare and usually not the goal either. At the same time the public cloud market keeps growing at double-digit rates. Both are true, because they concern different workloads.

For your own decision that means market figures serve as context, not as justification. The question is not how many organisations are moving back, but which of your own workloads are in the wrong place once the calculation has been done honestly.

From assumption to calculation: an assessment before any migration

The route from "the invoice is too high" to a decision that holds up has four steps, and none of them is a move. Together they are what a cloud migration strategy actually consists of:

1. Take stock. Which workloads run, with which load profile, which data volume and which dependencies on provider-specific services. The basis is measurements, not the architecture documentation.
2. Attribute the costs. The invoice is broken down by originator, including the side items for data transfer, support and administration.
3. Calculate scenarios. For every relevant workload, public cloud, private cloud and your own data centre are compared across the nine cost positions, with staff effort and migration cost as their own lines.
4. Test exit readiness. What a switch costs technically and contractually: data volume and egress fees, provider-specific services, remaining terms, exit clauses.

What comes out at the end is not a policy but a list: which workload stays, which moves, which is only optimised first, and in what order. That is precisely the content of the cloud exit and TCO assessment that opens our cloud migration services, deliberately placed ahead of any move.

If the decision then falls in favour of a migration, it runs in five phases with a go/no-go decision at every transition: analysis, target picture, test environment, migration, operations. In the documented projects, between two and six months passed from breaking ground to the old environment being switched off, depending on the landscape, and the existing estate kept running throughout.