Cloud Repatriation: Leaving AWS and Azure for a UK Sovereign Cloud

Cloud repatriation means moving workloads out of a public cloud such as AWS or Microsoft Azure and onto infrastructure dedicated to you: your own servers, colocation or a managed private cloud. Common reasons are predictable costs, control over data and less lock-in. Leaving also costs less than it did: AWS and Microsoft now waive exit data transfer fees for UK customers who apply.

Organisations rarely move everything. Many start with steady, sensitive workloads, putting them on a UK sovereign cloud or a managed private cloud, and keep the rest where it works best. This guide covers the forms repatriation takes, why organisations do it, what the UK competition regulator has changed, what leaving costs, which workloads to move and how to plan the exit.

What is cloud repatriation?

Cloud repatriation is the move of workloads from a hyperscaler’s public cloud to infrastructure that is dedicated to you. A hyperscaler is a provider that runs very large, global cloud platforms, such as AWS or Microsoft Azure. The destination can be your own data centre, servers you place in a colocation facility or a private cloud that a provider runs for you in its data centres.

The term covers a full exit and a partial one. A partial move leaves you with a hybrid cloud: some workloads on private infrastructure, some still on public cloud.

It is not a rejection of the cloud. A managed private cloud still gives you virtual servers without owning hardware. What changes is who runs it, where it runs and how you pay for it. Moving from one hyperscaler to another is usually called switching rather than repatriation, although the same exit terms apply to both.

Why do organisations move workloads off AWS and Azure?

The common reasons fall into five groups: cost predictability, sovereignty, performance, lock-in and control. It is a decision about where each workload fits best, not a retreat from cloud. UK customers spent £10.5 billion on cloud services in 2024, according to the CMA, and that spending grew by nearly 30% a year from 2020.

Cost predictability. Public cloud is priced by the hour and the gigabyte, which suits workloads that rise and fall. Many business systems run at the same size all month, and for those, a fixed monthly price is easier to budget. Public cloud prices can also change under you: Microsoft has told customers that prices for many virtual machine series and storage services in seven regions, including Dublin and Amsterdam, rise on 1 February 2027. No UK region is on the list. Our article on the 2027 Azure price increase has the detail.

Sovereignty. AWS, Microsoft and Google are US companies. A UK region keeps your stored data in the UK, but the parent company remains subject to US law, including the CLOUD Act. For organisations whose clients, contracts or regulators ask who could be compelled to hand data over, a UK-owned provider answers the question more simply.

Performance and data gravity. Some systems run better close to their users, to equipment on site or to the large databases they read all day. Data gravity is the pull a large data set exerts on the applications around it: the bigger it grows, the slower and costlier it is to move, so applications tend to follow the data. If your core data needs to sit on UK infrastructure you control, the systems that use it most may belong next to it.

Lock-in. The CMA found that egress fees and technical barriers lock customers into their first choice of provider, and that Microsoft’s software licensing practices reduce competition from other clouds. The next section covers what has changed since.

Control. Some teams simply want a named engineer who knows their environment, and a platform that does not change on someone else’s roadmap.

What did the CMA cloud market investigation find, and what has changed?

The CMA’s cloud market investigation concluded on 31 July 2025 that competition in UK cloud services is not working well. It found that AWS and Microsoft hold significant market power. Egress fees, technical barriers and Microsoft’s licensing make it harder to switch or use more than one cloud. Since then, both providers have improved their exit terms for UK customers, and the CMA is tracking their progress.

The figures behind that finding are stark. In 2024, AWS and Microsoft each held 30% to 40% of infrastructure as a service across the UK and EEA, the market the CMA examined. Fewer than 1% of customers switched provider each year. The CMA also found that egress fees weigh most on smaller customers and on those with large amounts of stored data, because for them the fees are highest relative to total cloud spending.

In March 2026 the CMA held off formal strategic market status (SMS) investigations into the two firms’ cloud services, keeping the option open. Instead it is holding both to steps they announced on egress fees and interoperability. It also decided to open an SMS investigation into Microsoft’s business software, which began in May 2026.

The CMA’s update of 16 October 2026 reported that:

• AWS and Microsoft have written free data transfer for switching into their UK customer contracts, making it a contractual right.
• The window to finish a move is now 180 days for UK customers of both (for Microsoft, when the data is in UK data centres).
• Microsoft now treats leaving a single Azure service as switching, for UK customers using UK data centres.
• Both have cut charges to cost for UK customers who use another provider alongside them.
• Uptake of these schemes has been “limited so far”, and the CMA expects both firms to promote them more.

The CMA’s next focus is two technical barriers: differences in identity and access management (IAM) between clouds, and Kubernetes deployments that depend on one provider’s services. Its Board will review progress in spring 2027. On the same day, the CMA proposed designating Microsoft with SMS in business software. That would let it look at whether customers can freely choose which cloud to run their Microsoft licences on.

One practical point for Microsoft customers: according to the CMA, Microsoft’s UK contract addendum is included by default for new UK Enterprise Agreement customers and for new and existing UK Microsoft Customer Agreement customers. Existing Enterprise Agreement customers have to ask for it.

How much are AWS egress fees and Azure egress charges?

Egress fees are charges for data sent out of a cloud provider’s network; AWS calls them data transfer out. In normal use, both AWS and Azure give the first 100 GB a month free, then charge per gigabyte in falling tiers. On the prices we checked on 19 October 2026, the first paid tier was $0.09 per GB from AWS London and $0.087 per GB from Azure in Europe.

The sources are AWS’s Amazon EC2 on-demand pricing, with its published price list, and Microsoft’s Azure bandwidth pricing.

A worked example shows the scale. Sending 10,000 GB (about 10 TB) out in one month, with the free allowance unused, would cost about $891 from AWS London (9,900 GB at $0.09). From Azure over Microsoft’s network it would cost about $861 (9,900 GB at $0.087). Both figures are before VAT. Egress is only one exit cost, alongside items such as running two platforms side by side, so cost every item.

Egress matters more as data grows. AWS said in March 2024 that over 90% of its customers already paid nothing for data transfer out, thanks to the free allowance. An organisation moving hundreds of terabytes is in a different position, and that is where the free exit terms count.

How do you leave AWS or Azure without paying egress fees?

Apply first, then move. AWS and Microsoft both waive data transfer charges for customers moving data out to another provider or to their own infrastructure, but only on request and on conditions. For UK customers, the terms have improved during 2026, as the CMA’s update confirms.

The sources are AWS’s UK Customer Switching and Portability Addendum and Microsoft’s guide to cancelling an Azure subscription, both checked on 19 October 2026.

Some details are easy to miss. If you migrate from AWS to another provider’s cloud service or to infrastructure you own or rent, the addendum covers either, whether you run the new platform yourself or a third party runs it for you. You can authorise a migration partner to do the work through your AWS account, but you stay responsible under the terms. You can ask once, in writing before the 180 days end, for an extension. When you finish, you send AWS a completion notice through AWS Customer Support.

The AWS request asks for your account IDs, your start and finish dates, whether the data is going to another cloud or to your own infrastructure, and how many gigabytes you expect to move. The CMA’s update also records that, since October 2025, AWS customers can request credits for data sent to the new provider while both platforms run side by side during the switch.

What other costs come with leaving?

Egress is only one line in an exit budget. The others are running two platforms in parallel, commitments you cannot cancel, licences, the migration work itself, any rebuilding and new skills. Cost each one before you commit, because together they decide whether a move pays back.

Licences and commitments deserve early attention. Microsoft’s licence terms do not treat every cloud the same way, which is one reason the CMA examined its licensing practices. Ask each shortlisted provider whether Windows Server and SQL Server come licensed through the provider or whether you bring your own. The CMA also found committed spend agreements widespread, so plan for the largest workloads to leave as their commitments end, not halfway through.

Which workloads should move, and which should stay?

Move the workloads that run steadily and hold data you need to control. Keep the ones that depend on services only a hyperscaler offers, or that swing sharply in demand. The test for each workload is simple: does it rely on something only that hyperscaler provides? If not, it can usually move as a virtual machine with its data.

Check dependencies as well as the workload itself. An application and the database it queries constantly should move together. Splitting them sends every query across a network link and, from a hyperscaler, through its egress meter.

Which cloud migration strategy fits each workload?

Use the strategies you would use for any cloud migration, applied in reverse. AWS’s own migration guidance lists seven, known as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor. For a move off a hyperscaler, start by sorting every workload into retire, retain, rehost or refactor, then use the others where they fit.

The source is AWS Prescriptive Guidance on migration strategies, checked on 19 October 2026. It warns against refactoring during a large migration, because it is the most complex option, and advises rehosting or replatforming first and modernising afterwards. The same logic works in reverse. Move each workload as it is where you can, and change one thing at a time.

Where can repatriated workloads go?

There are four main destinations, and they differ in who owns the hardware, who runs it and how you pay. The old on-premise vs cloud question now has more than two answers. Colocation and managed private cloud sit between your own server room and a hyperscaler.

The choice between colocation and a managed private cloud usually comes down to skills. Colocation keeps the hardware and its upkeep with you. A managed private cloud hands both to the provider while keeping the platform dedicated to you.

Should you go hybrid or multi-cloud instead of leaving completely?

For many organisations, yes. A hybrid cloud keeps the workloads that need a hyperscaler where they are and moves the steady, sensitive ones to private infrastructure. Multi-cloud is different: it means using more than one public cloud provider, such as AWS and Azure together. An organisation can run both models at once.

The CMA found multi-cloud still uncommon among small and medium-sized customers. Larger customers that use it generally keep most of their spending with one main provider. Hybrid works well when you plan three things from the start.

First, the connection between the two platforms: a site-to-site VPN or a private connection, sized for the traffic that will cross it. Second, identity: one way for staff to sign in to both, usually your existing Microsoft Entra ID or Active Directory. Third, the cost of data crossing between them. Data sent out of a hyperscaler is still charged in normal use, so keep chatty systems, such as an application and its database, on the same side.

Both providers now offer UK customers reduced, at-cost data transfer when they use another provider alongside them. AWS applies rates not exceeding its own costs to data sent to the other provider for your own use, but not to your end users. You ask AWS Customer Support before you start. Microsoft asks for an Azure Support request with your subscription ID, the autonomous system number (ASN) of the network outside Azure and an estimate of the share of data involved, as its page on Azure data transfer fees explains. At cost is lower, but it is still a charge.

Can public sector organisations repatriate under Cloud First?

Yes, but they need to show why. The government’s Cloud First policy says public sector organisations should default to public cloud, using other options only where that is not possible. It is mandatory for central government and strongly recommended for the wider public sector. Organisations that do not deploy in public cloud should be able to evidence the decision, business case and value for money.

The policy accepts community, hybrid and private deployment models in specific circumstances. Its cloud principles add that a private cloud must still provide the five essential cloud characteristics, such as on-demand access and rapid elasticity. It also asks organisations using incumbent vendors to manage vendor lock-in actively. Value for money is judged over the whole life of the service, including exit costs, so a costed exit plan helps whichever way the decision goes. Our guide to G-Cloud 15 for public sector buyers explains how to buy through the framework.

Public buying may change too. The CMA’s October 2026 update says it is working with the government as it develops the National Cloud Infrastructure Programme, which will coordinate how the public sector buys cloud services.

What is a cloud exit strategy, and what goes in an exit plan?

A cloud exit strategy is your organisation’s decision on when and how it would leave a cloud provider. The cloud exit plan is the working document behind it: what would move, where to, in what order, at what cost and how long it would take. You need one even if you never intend to leave, because a provider can fail or change its prices and terms.

For banks, insurers and other firms regulated by the Prudential Regulation Authority (PRA), it is an expectation. Its supervisory statement SS2/21 on outsourcing expects firms to develop, maintain and test a documented exit strategy for each material outsourcing arrangement. It should cover a stressed exit, such as the provider’s failure, and a planned exit for commercial or strategic reasons.

Government guidance on managing technical lock-in in the cloud, last updated on 3 September 2026, makes a similar point for the public sector. Hosting plans and business cases should include the estimated cost and time to exit, after any negotiated discounts have lapsed.

Review the plan once a year, and whenever you adopt a new hyperscaler-only service. The GOV.UK guidance notes that some organisations re-estimate switching costs by rebuilding or testing critical components in another provider’s environment.

How do you plan a cloud migration off AWS or Azure?

A cloud migration plan for repatriation follows the same arc as any migration, with one extra constraint: the egress waiver timetable. On AWS you must ask at least two months before you start, then finish within 180 days. Build the plan backwards from those dates, so the waiver is approved before the first data moves.

1. Inventory everything. List every account, subscription, server, database, storage bucket and the dependencies between them. Note which services only that hyperscaler offers.
2. Classify each workload. Retire, retain, rehost, relocate, replatform, repurchase or refactor, using the tables above.
3. Cost it both ways. Compare a year of your current bill with the target platform, including the end dates of reservations and savings plans.
4. Choose the target and check it. Ask which legal entity you would contract with, where the data and backups would sit and who could access them.
5. Design the landing zone. The landing zone is the base environment on the new platform: network, identity, firewalls, backup and disaster recovery, ready before the first workload arrives. Set recovery targets for each system first. Our guide to RTO vs RPO explains how.
6. Apply for the egress waiver. Contact AWS Customer Support at least two months before you start, or Azure Support before you start, with your plan and data volumes. If you buy Azure through a partner, ask the partner.
7. Migrate in waves. Start with a pilot, then move workloads in groups, testing each and running in parallel until users sign off.
8. Close the old estate. Delete the data from the services you have left within the waiver period, cancel subscriptions where the terms require it and keep a record of the deletion. On AWS, send the completion notice.

Here is how those steps might fall for an estate of around 50 virtual machines leaving AWS. The timings are an example only. Yours will depend on the number of systems, how tangled their dependencies are and how much you rebuild.

What should a cloud migration checklist include?

A cloud migration checklist confirms that each workload is ready before it moves, and that nothing is left behind afterwards. Run it for every wave, not just at the end. The checks below cover the points specific to leaving a hyperscaler as well as the usual ones.

• The workload has an owner and a recorded decision: move, stay or retire.
• Its dependencies are mapped, including identity, DNS, certificates, scheduled jobs and outside integrations.
• The AWS waiver is approved in writing, or the Azure Support request is logged with your start date and data volume, before any data moves.
• Licences for the target platform are confirmed.
• A fresh backup exists, and a test restore on the target platform has worked.
• Recovery targets are set, and backup and disaster recovery are running on the target.
• A rollback plan and a parallel-running period are agreed.
• Monitoring and alerting are live on the target.
• Users know the change window and who to contact.
• After cutover, the old resources are stopped, the data is deleted within the waiver period and the deletion is recorded.

How do you avoid vendor lock-in next time?

You cannot avoid lock-in entirely, so manage it deliberately. GOV.UK’s guidance describes lock-in as a state where switching technology or provider is difficult, slow and disproportionately expensive. It also accepts that some lock-in can be worth the value it brings. The aim is to choose it knowingly, and to know what leaving would cost.

• Prefer standard virtual machines, open data formats and open source where they do the job, over services only one provider offers.
• Use infrastructure as code that works across more than one platform. Infrastructure as code means describing servers, networks and settings in files a tool can apply, so you can rebuild an environment the same way elsewhere.
• Keep runbooks that another team could follow.
• Keep identity portable. The CMA’s October 2026 update names differences in identity and access management between clouds as one of the main barriers customers raise.
• Treat containers as portable only once you have checked. The CMA heard that Kubernetes deployments can rely on cloud-specific services, such as networking.
• Write an exit plan into the contract: how your data comes back, in what format, how fast, at what cost and with what help from the provider.
• Test a restore somewhere other than your primary platform at least once a year.

Can you cut cloud costs without moving?

Often, yes. Cloud cost reduction starts with what you already run: switch off what nobody uses, size the rest to its real load and commit only to steady demand. Do this before you write a repatriation business case, because it changes the comparison. Some workloads will look cheaper to keep. Others will still be better off moving.

• Find idle and orphaned resources: unattached disks, old snapshots and forgotten test environments.
• Resize virtual machines to the load they actually carry.
• Stop non-production machines outside working hours.
• Move rarely read data to cheaper storage tiers.
• Commit only to steady demand, and time commitments to end when you might move.

A costed exit plan also helps at renewal. The CMA expects some customers to benefit from the new switching terms even if they never switch, because a credible alternative strengthens their bargaining position.

How BlackBox Hosting can help

BlackBox Hosting runs managed private cloud and UK sovereign cloud in UK data centres, with static monthly billing and no consumption penalties. We are listed on G-Cloud 15 (Lot 1a). Our listing describes onboarding through structured implementation, documentation and guided setup by our engineers, and it sets out how we support exit: data extracted in standard formats and an agreed exit plan. Ask every provider you shortlist, including us, to show you its exit terms before you sign.

If you are weighing up a move off AWS or Azure, talk to an expert about which workloads to move first, or start a 30-day free trial to test one.

Frequently asked questions