European organizations with the highest sovereignty requirements have faced an impossible choice: accept limited capabilities in legacy on-premises systems, or move to hyperscale cloud and risk regulatory exposure.
AWS European Sovereign Cloud changes this equation. It's the first sovereign cloud that delivers the full AWS service portfolio with enhanced sovereignty controls, not a feature-limited compromise.
This guide explains exactly what AWS European Sovereign Cloud is, how it achieves sovereignty technically, and provides a decision framework to determine if your organization needs it. I'll cover the architecture, available services, compliance certifications, and practical getting-started steps.
What is AWS European Sovereign Cloud?
AWS European Sovereign Cloud is a physically and logically independent cloud infrastructure designed specifically for EU public sector organizations and highly regulated industries. It became generally available on January 14, 2026, representing a EUR 7.8 billion investment in European digital sovereignty.
Unlike traditional sovereign cloud offerings that force you to choose between sovereignty and capability, AWS European Sovereign Cloud delivers the same APIs, architecture, and features as commercial AWS, just with enhanced sovereignty controls.
Here's what makes it significant: the infrastructure, operations, and all customer data remain entirely within EU boundaries. This isn't just data residency (which standard AWS regions already provide). It's operational sovereignty with EU-resident personnel, independent legal entities under EU law, and technical controls that prevent any access from outside the EU.
The European Data Sovereignty Challenge
European organizations with the strictest sovereignty requirements often remain stuck in legacy on-premises environments. The reason is straightforward: existing sovereign cloud offerings typically force trade-offs between sovereignty and capability.
GDPR, national regulations, and sector-specific requirements like BSI C5 in Germany drive demand for infrastructure that keeps data within EU boundaries. But organizations also need modern cloud capabilities like AI/ML, serverless computing, and managed databases to remain competitive.
This creates tension. Public sector agencies want to modernize but can't accept the compliance risks of standard cloud deployments. Financial services need innovation velocity but face strict regulatory oversight. Healthcare organizations require advanced analytics capabilities but must protect sensitive patient data under EU jurisdiction.
AWS European Sovereign Cloud addresses this tension directly by providing full AWS capabilities within a sovereignty-first architecture.
AWS's Response: A Dedicated Sovereign Partition
AWS European Sovereign Cloud isn't just another region. It's an entirely separate partition (aws-eusc) with independent infrastructure, operations, and governance.
This separation means AWS European Sovereign Cloud has its own IAM system, billing infrastructure, DNS servers, and trust services. Resources in the aws-eusc partition cannot directly communicate with resources in the commercial aws partition. Cross-partition data transfer requires explicit customer action.
The first region launched in Brandenburg, Germany with the region code eusc-de-east-1. AWS plans to extend the footprint with Local Zones in Belgium, Netherlands, and Portugal, plus options for Dedicated Local Zones and AWS Outposts for on-premises deployments.
AWS announced the Digital Sovereignty Pledge in November 2022, committing to offer all AWS customers the most advanced set of sovereignty controls available in the cloud. The European Sovereign Cloud is the direct result of that commitment.
Key Facts at a Glance
| Attribute | Value |
|---|---|
| Partition | aws-eusc |
| First Region | eusc-de-east-1 (Brandenburg, Germany) |
| Console URL | https://console.amazonaws-eusc.eu/ |
| Signup URL | https://eusc-de-east-1.signin.amazonaws-eusc.eu/signup |
| Pricing Currency | EUR |
| Contracting Entity | Amazon Web Services EMEA SARL |
| General Availability | January 14, 2026 |
| Investment | EUR 7.8 billion |
| Projected Economic Impact | EUR 17.2 billion contribution to European economy through 2040 |
How AWS European Sovereign Cloud Works
Understanding how AWS European Sovereign Cloud achieves sovereignty requires looking at four layers: physical and logical separation, the Nitro System security foundation, operational control by EU residents, and the dedicated European Trust Service Provider. Together, these create a sovereign environment that goes beyond what standard AWS regions offer.
Physical and Logical Separation
All AWS European Sovereign Cloud infrastructure is physically located within EU boundaries. But physical location alone isn't sovereignty. The key is logical separation: the aws-eusc partition operates independently with no critical dependencies on non-EU infrastructure or personnel.
What this means technically:
- Independent IAM system: Identity and access management is completely separate from commercial AWS. You create new IAM identities and roles specific to the sovereign environment.
- Independent billing and usage metering: Financial systems operate within the EU with no dependencies on external infrastructure.
- Dedicated Route 53 name servers: DNS uses only European Top-Level Domains (TLDs).
- Technical controls preventing external access: Built-in controls prevent access to AWS European Sovereign Cloud infrastructure and data from outside the EU.
The infrastructure is designed for resilience. AWS built it to operate continuously even if connectivity with the rest of the world is interrupted. Multiple Availability Zones provide redundant power and networking within the Brandenburg region.
The AWS Nitro System: Security Foundation
Every modern Amazon EC2 instance in AWS European Sovereign Cloud runs on the AWS Nitro System, the same security foundation used across AWS globally.
Here's what makes Nitro critical for sovereignty: no operator access by design. There is no mechanism for anyone, including AWS employees, to access customer instance memory. This isn't a policy, it's a hardware-enforced boundary.
Nitro security characteristics:
- Hardware-enforced boundaries prevent unauthorized data access
- Cryptographically verified platform integrity
- Cannot access customer data stored on local encrypted instance storage or remote encrypted EBS volumes
- Administrative APIs are limited, authenticated, authorized, logged, and audited. None provide access to customer data.
NCC Group conducted an independent review of the Nitro System and affirmed these security claims, finding no gaps that would compromise the security assertions.
This is the foundation that makes sovereignty claims verifiable rather than just contractual promises.
Operational Control by EU Residents
Technical controls are necessary but not sufficient. Sovereignty also requires operational control by EU personnel under EU jurisdiction.
Current operational model:
- Day-to-day operations performed exclusively by EU residents located in the EU
- Technical support and customer service provided by EU-based teams
- Managed through dedicated European legal entities established under German law
Leadership structure:
- Two managing directors: Stephane Israel (appointed October 2025) and Stefan Hoechbauer (appointed January 2026), both EU citizens residing in the EU
- Independent advisory board comprised exclusively of EU citizens, including two independent third-party representatives
- The advisory board provides oversight and expertise on sovereignty matters
AWS is gradually transitioning operations to be performed exclusively by EU citizens located in the EU. During this transition period, a blended team of EU residents and EU citizens operates the infrastructure.
European Trust Service Provider (EU-TSP)
AWS established a dedicated European trust service provider to handle certificate authority operations within AWS European Sovereign Cloud. This is critical infrastructure that most competitors overlook in their sovereignty implementations.
What EU-TSP provides:
- Serves as the public root of trust for AWS European Sovereign Cloud
- Provides the default Certificate Authority (CA) used by AWS service endpoints
- Powers AWS Certificate Manager (ACM) and ACM-integrated services
- Maintains confidentiality and integrity of network communications
Operational characteristics:
- Operated exclusively by EU residents
- Independent EU-based auditors verify controls
- Completed cryptographic key signing ceremony
- Submitted for inclusion to popular web browsers
Without a dedicated trust service provider, certificate operations would depend on infrastructure outside the EU, undermining sovereignty claims.
Data Residency Guarantees
Data residency in AWS European Sovereign Cloud goes beyond what standard AWS regions offer.
Standard AWS regions provide:
- Customer content remains within the selected Region unless you explicitly choose otherwise
AWS European Sovereign Cloud adds:
- Customer-created metadata stays in EU: Roles, permissions, resource labels, configurations, and all operational metadata remain within EU boundaries
- All infrastructure components operate in EU: Billing systems, identity systems, control planes, and data planes are all EU-based
- Technical enforcement: No AWS operator outside the EU can access the systems or customer data
This distinction matters. In standard AWS regions, your data stays in the region you select, but metadata and operational information may be processed globally. In AWS European Sovereign Cloud, everything stays within EU boundaries.
Understanding the Sovereign Reference Framework (ESC-SRF)
The ESC-SRF is AWS's formal framework defining how sovereignty is implemented in the European Sovereign Cloud. It provides transparency and validation for customers and regulators who need to verify sovereignty claims, not just accept marketing statements.
This framework is available in AWS Artifact and forms the basis of a dedicated SOC 2 attestation, giving you third-party validated evidence to present to auditors and regulators.
The Four Sovereignty Domains
The ESC-SRF defines four sovereignty domains, each with specific control mappings:
-
Governance independence: Corporate structure under EU law with EU leadership. This covers the legal entity structure, managing directors, and advisory board composition.
-
Operational control: EU-resident personnel managing day-to-day operations. This includes technical support, customer service, and infrastructure management.
-
Data residency: All customer data and metadata remaining in the EU. This goes beyond content to include operational metadata, configurations, and audit logs.
-
Technical isolation: Physical and logical separation from other AWS infrastructure. This covers the partition separation, Nitro System controls, and EU-TSP operations.
The framework is industry and sector agnostic. AWS built it from customer feedback, EU regulatory requirements, and industry frameworks, making it adaptable to specific compliance needs.
How to Use ESC-SRF for Compliance
You can use ESC-SRF from two perspectives:
For assurance (proving compliance):
- Provides end-to-end visibility for each sovereignty criterion through to technical implementation
- Third-party validation available in the AWS European Sovereign Cloud SOC 2 report
- Reduces ad-hoc evidence requests from auditors and regulators
- Enables clear demonstration of sovereignty assurances to supervisory authorities
For design (building sovereign architectures):
- Reference framework for shaping organizational sovereignty architecture
- Guide for selecting configurations and defining internal controls
- Can be adapted to meet specific regulatory, contractual, and mission-specific requirements
- Organizations can create their own version, map to controls, and have them tested by third parties
The ESC-SRF framework is available for download in AWS Artifact (requires login). An independent third-party audit is scheduled for 2026.
Available Services at Launch
AWS European Sovereign Cloud launched with a comprehensive service portfolio across AI/ML, compute, containers, databases, storage, networking, and security. This isn't a limited feature set. You get the same APIs and architecture as commercial AWS.
Services added based on customer and partner demand follow AWS's deliberate approach: start with core services needed for critical workloads, then expand the catalog based on actual needs.
| Category | Service | Description |
|---|---|---|
| AI/ML | Amazon SageMaker | Full ML platform for building, training, and deploying models |
| Amazon Bedrock | Generative AI and foundation models | |
| Amazon Q | AI assistant for enterprise applications | |
| Compute | Amazon EC2 | All Nitro-based instances |
| AWS Lambda | Serverless compute | |
| Amazon EKS | Kubernetes orchestration | |
| Amazon ECS | Container orchestration | |
| Database | Amazon Aurora | MySQL and PostgreSQL compatible |
| Amazon RDS | Managed relational databases | |
| Amazon DynamoDB | NoSQL database | |
| Amazon Neptune | Graph database | |
| Storage | Amazon S3 | Object storage |
| Amazon EBS | Block storage | |
| Security | AWS KMS | Key Management Service with dedicated key infrastructure |
| AWS Private CA | Private Certificate Authority operations | |
| AWS IAM | Dedicated identity system for the partition | |
| AWS Shield Standard | DDoS protection |
These services work exactly as they do in commercial AWS. Your existing skills, Infrastructure as Code templates (Terraform, CloudFormation), and deployment patterns transfer directly. Note that IAM in AWS European Sovereign Cloud is a separate system—you create new identities and roles specific to this partition.
Service Roadmap
AWS has shared timeline expectations for additional services:
- Q1 2026: AWS IAM Identity Center expected
- End of 2026: Amazon CloudFront expected
Services removed from initial roadmap: AWS Shield Advanced, AWS Firewall Manager, and AWS Wickr were removed from the initial service list.
For current availability, check the AWS Capabilities by Region matrix. The initial services blog post is no longer being updated as of launch.
AWS European Sovereign Cloud vs. Standard Regions
AWS operates eight regions in Europe (six in EU Member States): Ireland, Frankfurt, London, Paris, Stockholm, Milan, Zurich, and Spain. You can already deploy data to any of these regions to keep it securely in Europe.
So when do you need the European Sovereign Cloud instead? The difference comes down to what stays in the EU and who operates the infrastructure.
Comparison Table
| Capability | Standard EU Regions | European Sovereign Cloud |
|---|---|---|
| Customer content location | Stays in selected region | Stays in selected region |
| Customer metadata location | May be processed globally | Stays in EU |
| Operational control | Global AWS operations | EU-resident operations only |
| Legal entity | Standard AWS entities | German legal entities under EU law |
| Service availability | Full portfolio | Initial portfolio, expanding |
| Partition | aws | aws-eusc |
| Account | Existing account works | Must create new account |
| Security foundation | Nitro System | Nitro System |
| Encryption | Full support | Full support |
| Compliance certifications | ISO, SOC, etc. | ISO, SOC, BSI C5, ESC-SRF SOC 2 |
Both options provide AWS Nitro System security, encryption, and compliance certifications. The difference is in operational control and metadata residency.
Decision Framework: Which One Do You Need?
Choose AWS European Sovereign Cloud when:
- You're a public sector organization with government data
- You're in a highly regulated industry with strict sovereignty mandates
- You require EU-resident-only operations and support
- You need independent EU legal entities managing infrastructure
- You require dedicated EU-based trust services
- Your compliance frameworks mandate that customer metadata (not just content) stays within EU
- Regulations require operational autonomy from non-EU entities
Choose standard European Regions when:
- Data residency in Europe is sufficient (content stays in chosen region)
- You don't require EU-resident-only operations
- You want access to the broadest global AWS ecosystem
- You need services not yet available in European Sovereign Cloud
- Your sovereignty requirements allow use of shared global infrastructure
Hybrid approach: Many organizations will use both. Workloads requiring highest sovereignty migrate to AWS European Sovereign Cloud. Other European workloads use standard EU regions for broader service availability. This hybrid model lets you match sovereignty controls to actual requirements rather than applying the strictest controls everywhere.
Who Should Use AWS European Sovereign Cloud?
AWS European Sovereign Cloud targets specific customer segments with specific sovereignty needs. Understanding whether you fit these profiles helps avoid over-engineering (using sovereign cloud when standard regions suffice) or under-engineering (using standard regions when sovereignty is actually required).
Public Sector Organizations
Government and public administration entities are primary targets:
- Government agencies at national, regional, and local levels
- Public administration entities managing citizen data
- Defense and national security organizations
- Law enforcement and public safety agencies
- Citizen services requiring highest sovereignty controls
Public sector organizations often face explicit requirements for operational sovereignty that go beyond data residency. The EU-resident operations and German legal entity structure directly address these requirements.
Highly Regulated Industries
Beyond public sector, several industries face sovereignty requirements:
- Financial services and banking: Subject to financial regulators who increasingly focus on cloud operational resilience
- Healthcare and life sciences: Patient data under strict EU regulations
- Telecommunications: Critical infrastructure with national security implications
- Energy and utilities: Including KRITIS (critical infrastructure) requirements in Germany
- Insurance: Financial regulation plus sensitive personal data
For these industries, the key driver is often demonstrating operational control to regulators. The ESC-SRF framework and dedicated SOC 2 attestation provide evidence that's often missing from standard cloud deployments.
When Standard EU Regions Are Sufficient
Not every European workload needs sovereign cloud. Standard EU regions are often the right choice when:
- Data residency in Europe is sufficient: Your compliance requirements focus on where data is stored, not who operates the infrastructure
- You don't require EU-resident-only operations: Your regulators or policies don't mandate EU operational control
- You need broadest global AWS ecosystem access: You want immediate access to all AWS services without waiting for sovereign cloud expansion
- Services you need aren't yet available: Your workload depends on services still on the roadmap
- Lower sovereignty requirements: Your risk assessment shows shared global infrastructure is acceptable
Be honest in this assessment. Over-engineering with sovereign cloud when it's not required adds complexity and cost. Under-engineering creates compliance risk. The decision framework above helps you make this assessment systematically.
Compliance and Certifications
AWS European Sovereign Cloud maintains the same core security capabilities and compliance programs as other AWS Regions, with additional sovereign-specific attestations that directly address EU regulatory requirements.
Available Certifications at Launch
The certification portfolio includes:
- ISO/IEC 27001:2013: International standard for information security management
- SOC 1, SOC 2, SOC 3: Service organization controls for security, availability, and confidentiality
- BSI C5: German Federal Office for Information Security cloud computing compliance criteria
- AWS Nitro System independent affirmation: NCC Group validation of security claims
Dedicated ESC-SRF SOC 2 Report: This is the critical addition for sovereignty validation. The ESC-SRF forms the basis of a dedicated AWS European Sovereign Cloud SOC 2 attestation, providing third-party validation of sovereignty controls. This report is available in AWS Artifact.
Access all compliance reports through AWS Artifact within your AWS European Sovereign Cloud account.
Building a Compliant Landing Zone
A proper landing zone is essential for achieving C5 compliance in AWS European Sovereign Cloud. Your landing zone establishes the foundation for governance, security controls, and compliance policies across your sovereign cloud environment.
Key requirements for a compliant landing zone:
- Preconfigured infrastructure templates and security baselines aligned with BSI C5
- Multi-account architecture using AWS Organizations for proper workload isolation
- Consistent data residency, access management, and compliance policies
- Automated security controls that map to EU regulatory frameworks
- Audit-ready configuration with proper logging and monitoring
We specialize in deploying AWS Landing Zones that meet BSI C5 and EU sovereignty requirements from day one. Our solution provides a production-ready foundation specifically designed for the European Sovereign Cloud environment.
Partner Ecosystem
AWS European Sovereign Cloud features a dedicated partner ecosystem with strict requirements ensuring all third-party solutions maintain sovereignty guarantees.
AWS Marketplace for European Sovereign Cloud
The Marketplace catalog for AWS European Sovereign Cloud is separate from commercial AWS Marketplace. This isn't just a filter. Products must meet specific sovereignty requirements.
Seller requirements for ESC Marketplace:
- Complete Know Your Customer (KYC) verification
- Provide EUR-compatible bank account
- Maintain two separate AWS accounts (one commercial, one ESC partition)
- Ensure products deploy exclusively on AWS infrastructure within ESC
- Products cannot have external dependencies, hybrid deployments, or on-premises components
- Third-party integrations must run entirely within AWS infrastructure and not transmit data outside ESC boundaries
All transactions are processed exclusively in Euros (EUR).
Partner Solutions by Category
Launch partners span critical enterprise categories:
Data and Analytics:
- ClickHouse, Cloudera, MongoDB, Reltio, Snowflake
- Enable data processing, storage, and analysis with EU-specific data governance
Security and Identity:
- CyberArk, Thales, WithSecure
- Workload protection with strict data residency requirements
AI and Machine Learning:
- Mistral AI
- AI models and applications with data sovereignty compliance
Enterprise Applications:
- SAP, Adobe Experience Manager, Cisco, GitLab, Mendix, Pega
- Business-critical applications meeting sovereignty requirements
Integration and DevOps:
- Boomi, Eficode, Trianz
- Secure software development and migration tools
For implementation support, AWS Digital Sovereignty Competency partners have advanced capabilities in digital sovereignty solutions tailored for European requirements.
Getting Started with AWS European Sovereign Cloud
Getting started requires understanding that AWS European Sovereign Cloud is a separate partition. You cannot use your existing commercial AWS account. This separation is intentional and provides the sovereignty guarantees that differentiate this offering.
Account Requirements
Create a new account:
- Navigate to https://eusc-de-east-1.signin.amazonaws-eusc.eu/signup
- Complete the account creation process
- This creates a new root account specific to the
aws-euscpartition - The new account is completely separate from any existing commercial AWS accounts
What this means practically:
- Create new IAM identities and roles for the sovereign environment
- Resources in
aws-eusccannot directly communicate with resources in commercialaws - Cross-partition data transfer requires explicit customer action
- Billing is separate from your commercial AWS accounts
Access Methods
AWS European Sovereign Cloud supports all standard access methods:
- AWS Management Console: https://console.amazonaws-eusc.eu/
- AWS SDKs: All languages supported with endpoint configuration
- AWS CLI: Configure with appropriate endpoint and region
- AWS APIs: Standard API access with
eusc-de-east-1region code
Infrastructure as Code compatibility: Terraform and CloudFormation work as expected. Your existing IaC patterns transfer directly. The main change is configuring the correct region and endpoints.
Existing AWS skills and architectural patterns apply. This is the same AWS, just in a sovereign partition.
Contracting and Billing
Legal entity: Services are contracted through Amazon Web Services EMEA SARL
Pricing: All pricing is in EUR (Euros). Eight billing currencies are supported (same as current AWS EMEA).
Sovereignty-specific contractual commitments: The AWS European Sovereign Cloud addendum contains additional contractual commitments specific to sovereignty requirements. Review this addendum to understand the specific commitments AWS makes for sovereign cloud operations.
What's Next
AWS European Sovereign Cloud represents a significant shift in what's possible for European organizations with strict sovereignty requirements. For the first time, you don't have to choose between cloud innovation and regulatory compliance.
Key takeaways:
- It's a separate partition (
aws-eusc) with full AWS capabilities and EU-only operations, not a feature-limited sovereign offering - Technical sovereignty is verifiable through the Nitro System, EU-TSP, and operational controls by EU residents, not just contractual promises
- Use ESC-SRF for compliance to demonstrate sovereignty to regulators and auditors with third-party validated evidence
- Not needed for all European workloads - use the decision framework to determine fit based on your actual requirements
- Available now with comprehensive service portfolio and partner ecosystem, with continued expansion based on customer demand
Recommended next step: Evaluate your current workloads against the decision framework in this guide. For workloads requiring highest sovereignty, create a new aws-eusc partition account and begin proof-of-concept testing with your most sensitive use cases. If you need help migrating to AWS European Sovereign Cloud, we can guide you through the entire process.
For organizations building landing zones in AWS European Sovereign Cloud, start with our guides on AWS Organizations, multi-account strategy, and multi-account best practices to establish the foundation before deploying workloads.
Need Help Migrating to AWS European Sovereign Cloud?
We specialize in migrating workloads to the AWS European Sovereign Cloud, setting up compliant multi-account architectures, and ensuring your infrastructure meets EU data sovereignty requirements from day one.
