The AWS European Sovereign Cloud: What It Is and How Much Sovereignty You Actually Get

The AWS European Sovereign Cloud runs a full Control Tower landing zone, an Organizations hierarchy and federated sign-in through IAM Identity Center. Nothing in that list would be remarkable in commercial AWS, which is rather the point: the ESC at launch is not a stripped-down evaluation environment but a working partition with over 90 services and governance tooling that most organisations will take years to exhaust. For most workloads it is better than good enough. The exception is the workloads where sovereignty is defined by regulation rather than by architecture. For those the question is not what AWS has built. It is who owns it.

This post is the first of three. It covers what the European Sovereign Cloud actually is, where it sits on the sovereignty scale and what governance and identity look like inside it, based on operating a real organisation in the partition rather than on reading the documentation. The second post covers AI services and the third covers serverless, containers and the CI/CD problem.

Everything is separate

Everything in the AWS European Sovereign Cloud is separate. Separate accounts that cannot be joined to an existing organisation, separate IAM with no way to assume a role across the boundary, a separate console, a separate DNS suffix and bills in euros from a separate contracting entity.

That is because the ESC is not another region alongside Frankfurt and Stockholm. It is a separate partition, aws-eusc, launched on 15 January 2026 with a single region, eusc-de-east-1 in Brandenburg, Germany. ARNs read arn:aws-eusc:..., service endpoints sit under amazonaws.eu rather than amazonaws.com, the console lives at console.amazonaws-eusc.eu and there is no shared network backbone with commercial AWS - no VPC peering, no Transit Gateway and no PrivateLink across the boundary.

The first practical consequence is the accounts. An existing AWS account cannot be used or migrated; sign-up starts again from scratch at aws.eu with its own root user, its own Organizations hierarchy and its own billing, denominated in euros and contracted through Amazon Web Services EMEA SARL. Existing Reserved Instances, Savings Plans and private pricing do not transfer.

The isolation is real at the IAM layer, not just the network layer. It is worth knowing how it fails. A trust policy naming a commercial account principal - arn:aws:iam::<account>:root - is rejected at role creation with MalformedPolicyDocument: Invalid principal in policy. A bare account ID from the commercial partition is rejected.

Partitions are an old mechanism, not an invention for Europe

The machine-readable list that ships inside every AWS SDK, partitions.json in botocore, names eight partitions: commercial aws with 35 regions, aws-cn operated in China by Sinnet and NWCD, aws-us-gov for the US government, three US classified partitions serving the Secret and Top Secret communities, a European classified partition whose cloud.adc-e.uk suffix speaks for itself and now aws-eusc.

The pattern behind them is consistent: whenever legal jurisdiction, operator nationality or security classification demands more isolation than a shared partition can provide, AWS builds a partition. The Chinese regions exist because Chinese law requires a licensed local operator, so accounts and credentials are separate from global AWS. GovCloud regions are administered exclusively by AWS personnel who are US citizens. The ESC combines both models - a local legal entity like China, personnel restrictions like GovCloud - and applies them to Europe. The mechanism is mature and well-trodden; only the partition is new.

Why the ESC exists

AWS’s stated model, set out in the Overview of the AWS European Sovereign Cloud whitepaper, is a German parent company, AWS European Sovereign Cloud GmbH, with three German subsidiaries; operations, technical support and customer service performed exclusively by EU-resident AWS employees with no operational access from outside the EU; independent access to source code for authorised EU-resident staff; an independent advisory board and a Sovereignty Reference Framework with third-party validated reports. These are AWS’s claims, stated here as AWS’s claims. The investment commitment is EUR 7.8bn in Germany, with Local Zones announced for Belgium, the Netherlands and Portugal.

The demand side is not hard to reconstruct. The Court of Justice of the EU invalidated the Privacy Shield transfer framework in 2020, putting the legal position of EU personal data under US jurisdiction in doubt. European public sector and regulated customers have been asking their providers questions about jurisdiction ever since. Meanwhile European providers and the sovereign offerings of the other US hyperscalers have made sovereignty a competitive category rather than a compliance footnote. My reading - and this is opinion rather than anything AWS has said - is that the ESC is AWS’s answer to the question “why should a European government buy American cloud at all” and the seriousness of the engineering suggests AWS is not treating it as rhetorical.

At launch the partition carries over 90 services against 240+ in the commercial EU regions (AWS’s launch services list). Some of the gaps and their consequences are the subject of the rest of this series; the short version is that the core is present and the edges are not - yet.

Sovereignty is a scale and the ESC stops one rung short

The one thing that is not separate is the shareholder. AWS European Sovereign Cloud GmbH is a German company and Amazon.com Inc is still its ultimate parent. Every other control in the model - the residency, the EU-resident staff, the legal entity, the assurance framework - is engineering and contract. Ownership is neither; no amount of operational isolation changes who owns the shares.

Sovereign, in this context, has a definable meaning: the degree to which a service and the data inside it answer to European law and European control alone - who can be compelled, under which jurisdiction, to disclose data or to change or withdraw the service. Measured that way, sovereignty is not a property a cloud has or lacks. It is a scale - the EU’s own proposed legislation grades it into assurance levels, as we shall see - and it pays to be precise about the rungs:

Any commercial EU region of a US hyperscaler gives you the first rung, data residency. The ESC adds the second and third: EU operations and an EU legal entity. The fourth rung, EU ownership, is the one the ESC structurally cannot reach and the rung a genuinely European-owned provider starts from. Scaleway, to take a worked example, is a subsidiary of the iliad Group, which Xavier Niel controls through his wholly owned iliad holding, so the ownership chain terminates in Europe. For a provider like that the question “what happens if the parent is compelled by a foreign government” does not need a framework to answer. It does not arise.

Where this stops being philosophy and becomes procurement is certification. France’s SecNumCloud qualification, version 3.2 of the ANSSI referentiel, devotes section 19.6 to protection from extra-European law. The decisive criteria are about ownership, not operations: the provider’s registered office, central administration and principal establishment must be in the EU; entities based outside the EU must not hold, directly or indirectly, more than 24% individually and 39% collectively of the provider’s capital and voting rights; nor may they hold a veto or the power to appoint the majority of the board. However well the ESC is engineered, this is a test it structurally cannot pass.

At EU level the direction of travel is the same. The Commission’s proposed Cloud and AI Development Act of June 2026 carries a sovereignty framework that grades cloud services into four assurance levels, of which the third requires providers “owned and controlled from the EU”. France wrote ownership into SecNumCloud in 2022; the Commission is now proposing to write it into EU law.

The counterweight deserves one point of reflection, because it is real. The ESC brings things no European provider currently offers in one place: 90+ managed services at launch, the multi-account governance tier this post walks through below and compatibility with the APIs, IaC and skills market of the largest cloud in the world. For most workloads that trade is worth making. But it is a trade; the side of it described above is the side that tends to get glossed over.

The judgement each organisation still has to make

The reach of US law over a US parent is not hypothetical in form, only in exercise. The primary texts are short enough to read. The CLOUD Act, 18 U.S.C. § 2713, obliges a US provider to disclose data “within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States”. The section is a single sentence and does not need a second.

The second text, FISA Section 702, authorised the targeting of persons outside the United States for foreign intelligence collection. It lapsed in June 2026 when its extension ran out, with existing authorisations continuing during the transition and reinstatement bills pending, so today it matters mainly as the statute Schrems II turned on: the Court of Justice found that surveillance programmes based on it “cannot be regarded as limited to what is strictly necessary” and leave data subjects “no right to an effective remedy”, so the Privacy Shield adequacy decision was ruled invalid. Its successor, the EU-US Data Privacy Framework of 2023, survived its first annulment challenge in September 2025 and the appeal is pending before the Court of Justice. Two transfer frameworks have fallen to this line of argument already; the third is under appeal. That history, more than any single statute, is what keeps European legal teams cautious.

The counter-argument is just as real and should be stated just as fairly. EU-only operations, no operational access from outside the EU, source code access for EU-resident staff and independently validated assurance reports are substantially more than data residency alone and more than most European organisations’ current providers give them. Whether the residual risk - a US parent under a legal compulsion its German subsidiary cannot see or resist - is acceptable is a judgement for each organisation’s legal and compliance function against its own regulatory obligations.

A blog post does not settle it and I won’t try. What a blog post can do is make the scale explicit, so the judgement is made about the right rung. “Is the ESC sovereign?” is not a well-formed question. “Is EU ownership a requirement we are subject to or is EU operation sufficient?” is - and it has the useful property that legal and compliance can actually answer it.

If your organisation is asking this question seriously - public sector, defence-adjacent, healthcare, anywhere regulated data makes jurisdiction a procurement criterion rather than a philosophy - and the judgement comes out in the partition’s favour, the next question is what you find when you arrive. That question has concrete answers; not all of them are the ones you would expect.

Governance: the baseline is yours to enable, not yours to build

Control Tower has been available in the partition since launch. The entire landing zone deploys from CloudFormation: AWS::Organizations::Organization, the OUs, the shared accounts, the Control Tower service roles and AWS::ControlTower::LandingZone itself, landing zone version 4.0, with auto-enrolment accepted. Account vending works the same way - an AWS::Organizations::Account created inside a registered OU is governed automatically on creation. There is no Account Factory, no AFT and no CfCT in the partition (ESC user guide).

What that landing zone deploys per default is deliberately lean. The design deserves credit rather than suspicion. The Config integration deploys recorders in every enrolled account, a delivery channel and an organisation aggregator in the Audit account - and no Config rules. The rules exist, disabled: the partition’s control catalogue holds 451 controls - 235 proactive, 160 detective and 56 preventive - and the detective ones are implemented as 89 Config rules and 71 Security Hub controls, none enabled per default. That is a reasonable default, because a Config rule is detective only: it flags non-compliant resources for audit and can help drive automated remediation, but it never blocks anything - and every rule evaluates at a cost. Landing zone 4.0 dropped the last mandatory detective controls, so Control Tower no longer imposes any rule-evaluation charge and the customer decides which detective controls earn their keep. That is more cost control than earlier landing zone versions gave, not less governance.

What is enabled per default is preventive: the AWS-GR_* SCP family protecting Control Tower’s own recorders, roles, topics and buckets. The governance baseline beyond that is yours to enable, not yours to build, which is a materially smaller task than writing controls from scratch - but it is a task: mapping the controls your organisation already owes - internal policy, certification obligations, regulator expectations - onto the catalogue and enabling what carries them. The catalogue is structured for exactly that exercise: above the 451 implementations sit 222 common controls grouped into 54 objectives across 13 domains, so the mapping starts from control intent rather than from rule names alone.

The enforcement machinery underneath is fully present. All three CloudFormation Hook types are registered in the partition - the Guard hook running cfn-guard, the Lambda hook and the Control Tower hook that implements proactive controls. Anyone building deploy-time guardrails in the ESC builds them on Hooks, SCPs and pipeline gates.

Two omissions deserve a flag on the way past. Security Hub CSPM is present, with 73 controls documented as available against nearly 600 commercially - though its own API cheerfully returns the full commercial catalogue, including controls for services the partition does not have, so the documentation and the API disagree and the documentation is the safer guide. And a fair slice of the security and governance portfolio is absent outright: AWS Audit Manager, Amazon Inspector, Amazon Macie, Amazon Detective, Amazon Security Lake, AWS Firewall Manager and Shield Advanced. What their absence means in practice - no automated compliance evidence collection, no managed vulnerability scanning, no sensitive-data discovery - deserves a future post of its own; the short observation here is that the detection and audit tier is the thinnest part of an offering aimed at regulated customers.

Identity: account trust stops at the boundary, federation does not

IAM in the ESC is entirely separate; as shown above, cross-partition sts:AssumeRole does not exist and cannot be configured. AWS states the rule plainly: IAM roles and resource-based policies delegate access across accounts only within a single partition. That kills the classic third-party access pattern - a vendor role in the vendor’s own account, trusted with an ExternalId - for every security scanner, FinOps platform and managed service provider whose integration assumes it.

What crosses the boundary instead is federation. The trust anchor moves from “an AWS account in another partition” to “an identity provider”. Everything terminates in an ESC account issuing the credentials:

• IAM Identity Center arrived in the partition on 31 March 2026 as an organisation instance. External identity providers work: Entra ID federates via SAML and provisions users via SCIM against the ESC’s own endpoints, verified end to end
• IAM’s SAML and OIDC providers work for workloads. The partition validates GitHub-signed OIDC tokens, which is how CI/CD gets in - more below
• IAM Roles Anywhere is present for X.509-based workload access with no AWS account on the third party’s side at all

Two sharp edges. There is no STS global endpoint in the partition, only regional ones (ESC user guide), so any tool that hardcodes sts.amazonaws.com - the historic default in older SDKs and countless scripts - fails outright. And Identity Center publishes two access portal URLs of which the dual-stack one trips a defect in the AWS CLI’s own domain allow-list; the IPv4 portal URL works. That defect is a story for another day.

For a consultancy or vendor the consequence is clear: you operate in a client’s ESC by federating your own IdP or receiving users in their Identity Center, without an ESC account of your own. What you cannot do is share anything into the partition from outside, so a vendor who needs their own sovereign environment - customer roles, demos, tooling, intellectual property - signs up like everyone else.

There is no CI/CD in the partition

Of AWS’s own CI/CD family, only CodeDeploy exists in the ESC. CodeCommit, CodeBuild, CodePipeline, CodeArtifact - none of them resolve; CloudFormation Git Sync is documented as unavailable. There is a managed deployment agent and nothing to drive it: no managed build service, no pipeline orchestrator, no source hosting, no artefact repository.

The irony is hard to miss: choosing the sovereign cloud currently means losing AWS’s EU-operated managed CI/CD, so your deployment tooling almost certainly sits outside the partition - and, unless deliberate choices are made, outside Europe. The good news is that the door is open: GitHub Actions deploys into the ESC via OIDC federation alone - no long-lived keys, no cross-partition trust. The bad news is that the EU-hosted pickings beyond that are slim. That problem deserves more than a paragraph and gets a full post.

What comes next

The second post in this series looks at AI in the partition, where the finding is easy to state and the implications are not: Bedrock offers exactly two foundation models; the accelerated compute is one GPU family. The third covers serverless and containers - where the platform is more complete than the AI story but the absence of CloudFront cascades further than expected - together with the CI/CD and observability problem in depth.

The partition is real, the engineering is serious and most of what an AWS organisation needs day to day is present and works. How much sovereignty you actually get depends on which rung you need. That question is not AWS’s to answer. The most useful thing to take from this post is that it is now precise enough to ask.

If you are evaluating the AWS European Sovereign Cloud for your organisation, Virtuability can help - or email team@virtuability.com.