Summary

  • AWS separates its European sovereign cloud at five planes: legal entity, account and identity, networking, staffing, and contract. Each plane is documented, not implied.
  • The same six pages also disclose where separation is incomplete — internal system metrics, specialist consultation, support entities in Ireland and Luxembourg, a Luxembourg contracting party, and global routing for some messaging services.

Amazon Data Services European Sovereign Cloud GmbH is the entity that owns and operates the underlying infrastructure of the first AWS European Sovereign Cloud Region, in the State of Brandenburg, Germany. That much is stated flatly in AWS's own FAQ and repeated in the European Digital Sovereignty FAQ. The interesting part is what surrounds that sentence.

The separation is real, and it is specific

Start with the corporate stack, because it is the easiest thing to fake and the hardest thing to fake well. AWS describes a new parent company plus three German subsidiaries: AWS European Sovereign Cloud GmbH as the parent, Amazon Data Services European Sovereign Cloud GmbH owning and operating the underlying infrastructure, AWS European Sovereign Cloud Development Centre GmbH employing operating personnel, and Amazon European Sovereign Cloud Trust Services GmbH holding trust certificates. The governance page adds the structural claim that matters: a parent locally controlled in the EU, led by EU citizens and subject to local laws, with a dedicated Security Operations Centre.

Accounts are the second plane. AWS states that existing AWS accounts cannot be used for the sovereign cloud, that sovereign accounts are independent and not interoperable with other AWS Regions, and that the design whitepaper puts billing, account and identity on a dedicated sovereign stack with global AWS accounts unable to configure or access sovereign services. An operator who cannot log in from the parent cloud is a different kind of separation from a data-residency promise.

Networking is the third. The same whitepaper describes no critical dependencies on non-EU infrastructure, dedicated networking from European providers, sovereign Points of Presence through AWS Direct Connect, dedicated Route 53 routing and a dedicated European root Certificate Authority. The FAQ repeats the dedicated networking, the sovereign Points of Presence and the dedicated Route 53.

Staffing is the fourth, and it is where the language gets careful. Only personnel who are EU residents located in the EU control day-to-day operations, including data-centre access, technical support and customer service, according to the aws.eu FAQ. AWS describes a gradual transition toward exclusive EU-citizen operations — a transition, not a completed state.

The fifth plane is the contract, and it is the strongest instrument in the set. The AWS European Sovereign Cloud Addendum, last updated 14 May 2026, warrants that only AWS European Sovereign Cloud Staff operate sovereign-cloud services, provide AWS Support, operate the compute infrastructure and control the technical and operational systems containing customer content and customer-created metadata. It defines that staff as persons employed by an AWS entity registered in the EU who are EU residents or EU citizens and located in the EU when performing their role. It states that AWS personnel outside the EU do not have access to customer content or customer-created metadata and that AWS has no technical means available outside the EU to access them, subject to the addendum's stated exceptions. And it commits that the cloud is designed to operate independently and indefinitely, including independent of any connection to non-EU infrastructure.

That is not a marketing page. It is a document with remedies attached.

Then the same documents name the crossings

A wall that lists its doors is more trustworthy than a wall that claims to have none. Here are the doors AWS itself painted.

Operational telemetry. The design whitepaper states that some data which is neither customer content nor customer-created metadata — internal system metrics — may leave the EU to support capacity management, performance monitoring, security functions and assistance to sovereign-cloud staff. The contract's EU-only warranty covers content and metadata. The metrics are a different category, and AWS says so in writing.

Specialist consultation. The whitepaper restricts sovereign-cloud personnel, including support and data-centre operators, to qualified AWS European Sovereign Cloud Staff, while noting that global AWS technical teams may be consulted through controlled mechanisms. Consultation is not access. It is also not nothing.

Support entities outside Germany. The sub-processors page, in the state it was listed on 28 July 2026, names Amazon Development Centre Ireland Limited and Amazon Web Services EMEA SARL as AWS entities providing customer-initiated support, with the qualifier that they do not process customer data unless the customer agrees to share it during support. A support ticket is a decision point, not an automatic leak.

The contracting party. For accounts associated with an EU customer location, the contracting party is Amazon Web Services EMEA SARL, principal place of business Luxembourg. Operations sit in Brandenburg; the signature sits in Luxembourg.

Routing for messaging. The same sub-processors page names Key-Systems GmbH in Germany for Amazon Route 53 domain registration, and warns that for certain messaging services downstream providers may route and process data globally as necessary. That is a service-specific exception to a clean EU-only story, disclosed by the provider rather than discovered by a customer.

The exclusions. The addendum applies to AWS European Sovereign Cloud Accounts and expressly excludes AWS Training & Certification and AWS Professional Services. A sovereignty warranty scoped to a service boundary is honest; a buyer who assumes it covers the people doing the migration has made an inference, not read a term.

There is also version drift worth noting. The design whitepaper describes a four-member advisory board; the current governance page reports five. The whitepaper uses prospective language in places where the FAQ now uses present tense. Neither is a scandal. Both tell you the documents are living artifacts and that your diligence date matters.

What the contract cannot show you

The addendum is a private instrument between two parties. The public instrument of accountability for addressing is the registry record: which legal person holds the numbers, in which jurisdiction, and which autonomous system announces them. Those are auditable by anyone, not just by a customer with a legal team.

I tried to read that layer for this entity and could not: attempts to inspect Amazon's published IP-range data and the RIPE NCC database record returned no readable content. So this article makes no claim about the membership status, autonomous system numbers, announced prefixes or address-holding entity behind this region. The gap is a retrieval limit, not evidence of absence — and it is exactly the gap a buyer's own diligence has to close, because a warranty about EU-only staff is not a statement about who holds the serving addresses.

That distinction is the whole argument. A contract can promise that no one outside the EU touches your content. It cannot, by itself, tell you that the address space your workload depends on is held by the entity you think.

What a buyer should actually do with this

Read the addendum as a specification of scope, not as a certificate. Three consequences follow.

First, price the exclusions. Training and Professional Services sit outside the warranty, which means the advisory and migration work around a sovereign workload inherits a different access model than the workload itself. If your sovereignty case depends on who can see the data during the transition, the transition is not covered.

Second, read the sub-processor page on the day you sign, not the day you scoped the project. It carried a 28 July 2026 date. Support entries, registration agents and messaging exceptions change on the provider's schedule.

Third, separate the two questions you are really asking. "Who can access my data" is answered by the addendum, and answered well. "Who controls the continuity of the addresses and identity my workload depends on" is answered by registry records and routing, and answered publicly. AWS has documented the first question in unusual detail. The second question still belongs to the buyer — with a link, a date and a screening of the registry record — and no amount of contractual language substitutes for it.