Architecting a secure landing zone in the AWS European Sovereign Cloud

What it is

A reference architecture for the AWS European Sovereign Cloud (EUSC, partition aws-eusc, first Region eusc-de-east-1), focused on the specific, enumerable technical boundaries that trip up teams porting a commercial AWS landing zone into it. The summary already covers the tool/service list; what it omits is the concrete list of what does and doesn't cross the partition boundary, plus the exact patterns to work around that.

How it works

EUSC is a hard partition like aws-cn or aws-us-gov: separate IAM, billing, control plane, endpoints, and ARNs (amazonaws.eu instead of amazonaws.com, except IAM service principals which stay amazonaws.com in every partition). No IAM credential, role assumption, cross-Region replication, or Direct Connect gateway extends across a partition boundary.

Concrete boundary effects stated in the page:

• No cross-partition ECR replication, AMI copy, or S3 replication — getting images into EUSC requires an explicit push with EUSC credentials, not a replicated pipeline.
• No cross-partition Direct Connect gateway — EUSC requires its own dedicated DX connection/VIF or separate site-to-site VPN into the EUSC Network account.
• VPC endpoints don't cross partitions — any commercial-partition service exposed to EUSC must go over DX/VPN plus an in-EUSC load balancer.
• Route 53 hosted zones aren't visible across partitions — cross-cloud name resolution needs subdomain delegation or Resolver forwarding over DX/VPN.
• Region-deny SCPs are not required in EUSC today (unlike commercial) because the partition itself is the isolation boundary — but become relevant once EUSC adds a second Region/Local Zone.
• Terraform state must be kept in a separate in-EUSC S3 backend + DynamoDB lock table per partition; state is never shared across partitions.
• No org-wide billing roll-up — EUSC has a fully separate payer, billed in EUR through an EU contracting entity.

Preconditions / Affected

Applies to any org already running AWS Control Tower/AFT, IAM Identity Center, CI/CD, or DX in the commercial aws partition that now needs a presence in eusc-de-east-1. Relevant the moment you write IaC with hardcoded arn:aws (breaks when applied against aws-eusc), or assume cross-account/cross-partition trust, replication, or billing consolidation will "just work."

What to do

• Derive the partition dynamically in Terraform/CloudFormation ARNs instead of hardcoding arn:aws, so the same modules deploy to both aws and aws-eusc.
• Run a second IAM Identity Center instance in EUSC, SAML/SCIM-federated to the same corporate IdP, with permission sets/assignments (aws_ssoadmin_account_assignment) managed separately per partition.
• For image/artifact delivery into EUSC: push container images directly to an in-partition ECR with EUSC credentials and a sovereign signing key; rebuild AMIs natively via EC2 Image Builder or aws ec2 import-image; stage binaries in an EUSC Shared Services bucket and move them via aws s3 sync or AWS DataSync over DX/VPN.
• For CI/CD crossing the boundary, use OIDC federation with two separate trust configurations (one per partition) rather than any shared role.
• Keep EUSC firewall/segmentation automation pulling current IP ranges from the partition's own published ip-ranges file.
• Use Account Factory for Terraform (AFT) deployed natively in EUSC for account vending; reference the LZA Universal Configuration for European Sovereign Cloud (GitHub) as a ready-to-deploy baseline, and the LZA Compliance Workbook/Independent Assessment Report (AWS Artifact) for C5:2020 mapping.

Caveats

The page notes GuardDuty/Security Hub org-wide auto-enable "might differ" from commercial feature parity at any given time — treat the EUSC service list as the current source of truth and gate unsupported features behind a flag, enabling per-account via StackSets if org-level auto-enable isn't yet available.