By What sovereignty options does AWS offer in Europe?
AWS offers four distinct arrangements in Europe, and they answer different controls rather than forming tiers of the same product. Treating them as a price ladder is what produces procurement exercises where the options being compared do not satisfy the same requirement.
| Arrangement | The control it answers | What it does not answer |
|---|---|---|
| Standard European regions | Data resides and is processed in Europe, with the full service portfolio | Which jurisdiction governs the operating entity |
| AWS European Sovereign Cloud | Operation and governance under a separate European structure, independent of other regions | Physical placement at a location you choose |
| Dedicated Local Zones | Who may operate the infrastructure, and where it physically sits | Independence of the wider operating entity |
| AI Factories | Dedicated AI infrastructure in a facility you provide and power | General purpose workloads |
Two of these are frequently proposed for requirements that a standard region already satisfies. That is the expensive mistake in this area, and it is made during requirement drafting rather than during architecture.
Is a standard AWS region in Europe enough?
For most requirements, a standard region is sufficient, and establishing that early is worth more than any subsequent negotiation. AWS operates eight regions in Europe, in Ireland, Frankfurt, London, Paris, Stockholm, Milan, Zurich and Spain, and six of those sit in EU member states.
If the obligation is that data must be stored and processed within the EU, a region in an EU member state satisfies it, with the full service portfolio and no architectural compromise.
Operator access is worth separating from location, because it is often the unstated concern behind a location requirement. AWS states that the Nitro System underpinning its modern EC2 instances provides a physical and logical boundary such that no operator, including those with the highest privileges, can reach customer data, and that this holds even in fulfilment of a law enforcement request. NCC Group independently reviewed that design and published a report on 3 May 2023 concluding it found no gaps that would compromise the claims.
That control therefore exists in every region. A requirement about operator access does not on its own justify moving to a dedicated arrangement, and knowing that removes one of the more common reasons a sovereignty programme becomes larger than it needed to be.
What does the AWS European Sovereign Cloud actually change?
The European Sovereign Cloud changes who operates the cloud and under which jurisdiction the operating entity sits, which is a different control from where the data is.
The published position, as of the January 2026 launch of its first region in Brandenburg, Germany, has four parts.
- Separation. It is physically and logically separate from every other AWS region, rather than a configuration applied to an existing one.
- Personnel. AWS states it is operated exclusively by EU residents, with "zero operational control outside of EU borders".
- Governance. A dedicated European parent company with three subsidiaries incorporated in Germany, leadership comprising EU citizens bound by European law, and a five-member advisory board of European citizens and residents, three of them Amazon employees and two independent.
- Continuity. AWS states the infrastructure can "continue operations indefinitely, even in the event of a communications disruption with the rest of the world", with authorised EU-resident employees holding independent access to source code replicas.
AWS announced the programme in October 2023, following its Digital Sovereignty Pledge of November 2022, and states an investment of more than 7.8 billion euro in Germany.
It launched with more than 90 services, in AWS's own words, across categories including artificial intelligence, compute, containers, database, networking, security and storage. That figure is the single most useful number in this article, and its implications are covered below.
The relevant question for a buyer is narrower than the announcement. Contracts, data processing agreements and datacentre locations are contractual instruments. The jurisdiction of the entity that operates the infrastructure is structural. For most data categories that distinction is academic and a standard region is the right answer. For a small number, typically those carrying obligations that survive any commercial agreement, it is the whole decision.
When do Dedicated Local Zones fit better?
Dedicated Local Zones fit where the requirement is about who may operate the infrastructure and where it physically sits, rather than about the jurisdiction of the operating entity.
AWS describes them as fully managed by AWS, built for the exclusive use of one customer or community, placed in a customer-specified location, and offering options to enforce security clearance or other criteria on the AWS personnel who operate them.
That last clause is the reason they exist. It answers a requirement that no region can satisfy however favourably located: that the individuals with operational access hold a specific clearance. Defence, intelligence and certain critical infrastructure requirements are written that way, and when they are, a sovereign region is not a substitute.
AI Factories follow the same logic for accelerated workloads, with the customer providing the facility and power and AWS deploying and managing the infrastructure. The control being purchased is exclusivity and placement rather than residency.
Does a sovereign region have fewer services?
AWS states parity as an explicit design goal, writing that customers should not have to choose between the full power of AWS and a feature-limited sovereign solution. That is a clear statement of intent and worth taking at face value as one.
The launch position is a separate question, and AWS has published the answer to it. The European Sovereign Cloud opened with more than 90 services. A mature AWS region carries substantially more, so at launch this is a subset rather than a copy, and that is a normal property of a new region rather than a criticism of one.
Both things are therefore true at once, and a buyer needs both. The commitment describes the destination. The service count describes the position on the day you sign, and the correct answer changes as the catalogue fills out. A commitment about the destination says nothing about whether the twelve services your workload happens to need are among the first ninety.
No vendor publishes a gap list for its own newest region, and no partner page is going to do it either. So the verification is yours, and the method is short.
- List every service the workload depends on, including the ones nobody remembers: certificate management, secrets storage, the specific managed database engine and version, the instance families your licensing assumes, and any service your infrastructure as code already references.
- Check each against the AWS regional services list for the target region, on the day you are deciding.
- For anything missing, decide explicitly whether you self-manage it, change the design, or place that component elsewhere.
- Repeat the check before contract signature, because both the catalogue and your dependency list will have moved.
Doing this before the architecture is fixed is the entire value. A missing managed service discovered afterwards means either running it yourself or redesigning, and both are considerably cheaper to find in a spreadsheet than in a migration.
How should a sovereignty requirement be written?
A sovereignty requirement should specify the control, not the product, and the difference is usually the difference between a viable budget and an abandoned programme.
A requirement naming a specific sovereign offering has already taken an architectural decision on the bidder's behalf. It also removes the bidder's ability to point out that a cheaper arrangement satisfies the actual obligation, which is information the buyer wanted.
Four questions produce a requirement that can be answered honestly.
- Where may the data reside, at rest and in processing, and does that extend to backups, logs and telemetry.
- Which jurisdiction may compel the operator, and does the obligation survive a change in commercial relationship.
- Who may hold operational access, and is a specific clearance or nationality requirement attached.
- What must continue working if a supplier relationship ends, and over what period.
Answer those and the correct arrangement usually identifies itself, frequently as the least expensive option on the list. Leave them unanswered and the exercise becomes a comparison of vendor terminology, which is where most of them currently end.
Where do sovereignty decisions usually go wrong?
They go wrong during requirement drafting rather than during implementation, and four patterns recur.
The strictest requirement present anywhere in the organisation is applied to everything. One data category with an unusual obligation sets the architecture for workloads that never needed it, multiplying cost without improving the position on the category that mattered.
Location is used as a proxy for control. A requirement is written about datacentre geography when the underlying concern is operator access or jurisdiction, both of which are addressed by different mechanisms, one of which is already present in every region.
Service availability is assumed from a commitment rather than checked against a date. The architecture is designed, then a dependency turns out to be unavailable, and the redesign consumes the contingency.
Terminology is compared instead of controls. Sovereignty is not one property, and a page listing six dimensions of it is not an answer to which dimension a specific obligation invokes. The commercial structure that sits underneath these decisions is covered in how a European mid-market company should buy AWS, and the commitment mechanics in the AWS private pricing agreement guide.
One caveat on scope. Everything above concerns AWS arrangements, and for AI workloads specifically the prior question is whether a hyperscaler is involved at all. Models can run on an organisation's own hardware in its own facility with no external provider at any layer, and the decision about which requests need that placement is a different exercise from choosing between AWS options. That question, including why restricting AI use tends to relocate it rather than reduce it, is covered in does restricting AI use actually reduce risk.
Every figure and product claim above is dated because this area moves quickly. Verify each against AWS's own current documentation before relying on it in a submission.
