On 15 January 2026, AWS opened the European Sovereign Cloud: a physically and logically separate partition, first region in Brandenburg, Germany, with everything - data, metadata, IAM, billing, operational staff - kept inside the EU. The expansion plan runs through sovereign Local Zones in Belgium, the Netherlands and Portugal. The UK is not on the map, and AWS has said nothing to suggest it will be.
Within a fortnight of the launch I'd heard the same question from two different regulated-sector programmes: "should we be waiting for the UK version?" It's the wrong question, and it's worth spending a thousand words on why - because the confusion behind it is currently stalling real migrations.
What the European Sovereign Cloud actually is
The ESC is not a compliance feature bolted onto existing regions. It's a separate partition in the same sense that AWS GovCloud (US) and the China regions are separate partitions: its own account structure, its own IAM identity store, its own console endpoints, its own billing pipeline. Nothing federates across the boundary by default. Operations are run by EU-resident personnel under an EU-incorporated entity, which is the point: the design target is insulation from non-EU legal process, aimed squarely at customers whose regulators read the US CLOUD Act debate and concluded that contractual assurances weren't enough.
That last clause matters. The ESC exists to answer a jurisdiction question, not a location question. AWS has offered UK data residency since eu-west-2 opened in London in 2016. If your requirement is "data stays in the UK", you have had the answer for a decade.
Residency and sovereignty are not the same requirement
The NCSC's Cloud Security Principles put it plainly in Principle 2: you should know where your data is stored, processed and managed, and who can access it. Note what that principle does not say. It doesn't say data must be immune to foreign legal process. It doesn't mandate a sovereign partition. For data at OFFICIAL - which is the overwhelming majority of UK public sector workloads, including OFFICIAL-SENSITIVE - government guidance places the decision with the information owner, who weighs jurisdiction as one risk among several.
Sovereignty, properly stated, is a requirement that your data and the operation of the service sit exclusively under one legal jurisdiction. Almost no UK workload has that requirement written down. Plenty of programmes behave as if they do.
The failure mode: programmes stall on a requirement nobody wrote down
Here's the pattern as it actually plays out. A migration is six weeks from its first production cutover. Someone in the security workstream reads a headline about sovereign cloud, raises a risk - "have we assessed data sovereignty?" - and because nobody can point to a document that says the requirement doesn't exist, the risk can't be closed. It escalates. Legal gets involved. The DPIA gets reopened. Three months later the programme is still running its legacy estate, paying for both sides of a migration that has stopped moving, and the risk register entry still says "open" because you cannot evidence the absence of a requirement.
The ESC launch has made this worse, not better, for UK teams - because now the sovereign option visibly exists and visibly excludes the UK. "AWS built one for the EU and not for us" reads, to a nervous risk owner, like a gap. It isn't. It's a signal that AWS sized the UK demand for a separate partition and found it didn't justify one - because UK regulators, unlike some EU counterparts, have not pushed workloads towards jurisdictional isolation. The FCA's operational resilience rules, the NCSC principles and the government cyber security policy handbook all point at knowing and evidencing your controls, not at partition-level separation.
What to build in eu-west-2 instead of waiting
If you run regulated workloads in the London region, the controls that actually close the residency and access questions are specific and buildable now:
- Pin the regions. A service control policy denying actions where
aws:RequestedRegionis outside eu-west-2 (plus us-east-1 for the handful of global control-plane services) turns "our data stays in the UK" from a policy statement into an enforced invariant. Deploy it at the organisation root, not per-account. - Own the key question honestly. KMS keys with a tight key policy answer most access concerns. If a regulator or contract genuinely requires that AWS cannot produce your plaintext under any legal process, that's what the KMS External Key Store is for - keys held in your own HSM, on your premises, under UK jurisdiction. XKS is operationally expensive; use it because a written requirement says so, not because it feels safer.
- Evidence operator access, don't speculate about it. The Nitro System has no mechanism for AWS operators to access instance memory or EBS data, and AWS publishes third-party audits saying so. Pair that with CloudTrail organisation trails and AWS Config conformance packs, and your assurance case is made of logs rather than assertions.
- Write the requirement down either way. A one-page data residency and jurisdiction statement, signed by the SIRO or information owner, kills the recurring risk-register zombie. It either states the sovereignty requirement - in which case you design for it - or states there isn't one, in which case the next headline can't reopen the question.
One procurement note worth having on your radar: G-Cloud 15 lands in autumn 2026 with Cyber Essentials Plus mandatory for all suppliers. If you're buying delivery partners for regulated work, that's the floor, not the ceiling - ask how they'd evidence the four controls above, and walk away from anyone who answers with a whitepaper about sovereignty.
How Kineticor Can Help
Kineticor builds and assures AWS platforms for regulated UK organisations - financial services, public sector, healthcare - and most of that work starts exactly here: turning a vague sovereignty anxiety into a written requirement, then into SCPs, key management and audit evidence that a regulator will actually accept. If a residency question is holding up your migration, or you want the four controls above implemented and evidenced in your landing zone, get in touch.
— Danish
Danish Muhammad
Founder, Kineticor
I help businesses achieve their vision by making the cloud work for them — efficiently, securely, and at scale. Beyond technical solutions, I focus on solving real-world challenges, aligning cloud strategy with business goals, and building high-performing teams. My background is technical delivery; my passion is solving people problems. Connect on LinkedIn.