AWS has introduced the European Sovereign Cloud as a separate partition (aws‑eusc) that runs its own IAM, Organizations, billing, console domain, and service endpoints, isolated from the commercial aws partition. Engineers who build, operate, or secure workloads must treat this partition as a hard boundary, because credentials, policies, and cross‑region features do not cross between partitions.
Partition Boundary Implications
The partition model changes three core identity and governance areas:
- IAM isolation: IAM identities and roles created in the commercial aws partition cannot be used to access resources in aws‑eusc. Practitioners need to provision separate users, groups, and roles within the sovereign partition.
- AWS Organizations: Each partition hosts its own organization hierarchy. A single payer account in aws does not aggregate costs or policies for aws‑eusc; a distinct payer in EUR is required.
- IAM Identity Center (SSO): The SSO service runs independently per partition, so single sign‑on configurations must be duplicated for the sovereign environment.
These facts affect how you design cross‑account roles, automate identity as code, and manage audit trails.
Network and Service Access Considerations
Service endpoints and networking constructs also respect the partition line. The console and API domain switches from amazonaws.com to amazonaws.eu, and any Direct Connect links must be provisioned against the sovereign endpoint. Cross‑Region capabilities such as S3 replication or Transit Gateway peering operate only between regions that share the same partition, so replication across a commercial region and a sovereign region is not possible.
Image distribution pipelines must target the sovereign registry endpoints, and any automation that assumes a single endpoint domain will fail when run against aws‑eusc.
Landing Zone Design Guidance
When constructing a landing zone in the European Sovereign Cloud, the following patterns align with the AWS Security Reference Architecture and the Well‑Architected Framework:
- Account structure: Create a dedicated root payer in the sovereign partition, then organize workload accounts under a separate organization hierarchy.
- Infrastructure as code for identity: Define IAM users, roles, and policies in version‑controlled templates that are applied only to the sovereign partition.
- Centralized logging: Forward logs from sovereign accounts to a SIEM that can ingest the
arn:aws-eusc:ARN format, ensuring correlation with commercial logs remains a manual process. - Data protection: Apply encryption and key management within the sovereign partition; keys do not migrate across partitions.
- CI/CD and artifact distribution: Configure pipelines to push build artifacts to the sovereign container and package registries, and to use the sovereign IAM role for deployment.
- Incident response: Prepare playbooks that reference sovereign‑specific console URLs and billing identifiers, and test role assumption within the partition.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Treat the European Sovereign Cloud as a separate AWS environment: duplicate identity, organization, and billing configurations; adjust automation to use the arn:aws-eusc: prefix and amazonaws.eu endpoints; and verify that any cross‑Region or cross‑partition services you rely on are supported within the sovereign partition. Review the companion C5:2020 assessment report if compliance with that standard is required, and incorporate its checklist into your landing‑zone build process.