How to build a secure landing zone in the AWS European Sovereign Cloud

# What the European Sovereign Cloud is

# Why the partition boundary matters

If your architecture spans both commercial AWS and EUSC, you cannot centralize certain controls across partitions. Consolidated billing, a single organization, centralized identity, or direct cross-account roles only work inside the same partition. When you need to bridge clouds, do it at network or API layers and use separate credentials per partition.

# Foundations for a secure landing zone in EUSC

Start by treating EUSC as an independent landing zone that mirrors your existing commercial operating model. Map your design to the AWS Security Reference Architecture and the AWS Well-Architected Framework. If you need compliance alignment, use the provided C5:2020 independent assessment report and compliance workbook available in AWS Artifact.

# Partition-aware infrastructure as code

Write IaC that detects the partition at deploy time instead of hard-coding arn:aws. Example patterns in Terraform and CloudFormation derive the partition so the same modules deploy unchanged across aws and aws-eusc. That prevents broken ARNs and keeps deployments consistent when you run identical modules in commercial Regions and inside the sovereign partition.

# Account structure and governance

# Identity and access management

EUSC provides a separate IAM and Identity Center instance. Manage identity as infrastructure as code so you can replicate role definitions, policies, and SSO configurations between partitions while retaining separate credentials and trust boundaries.

# Centralized logging and monitoring

# Data protection and networking

Keep data residency and sovereignty controls by operating storage, keys, and backups inside the partition. Cross-Region features and some network peering functions work only inside a partition. Design network and perimeter components with the constraint that Transit Gateway peering, VPC peering, and AWS RAM won't cross aws and aws-eusc.

# Secure CI/CD, artifacts, and distribution

When CI/CD runs in commercial Regions but deploys to EUSC, use API- or network-level integrations and separate credentials for each partition. Make artifact distribution partition-aware and ensure artifact registries, signing, and deployment pipelines reference the correct partition endpoints.

# Incident response

Build incident response runbooks and tooling that operate within the partition. Use EUSC-local logging, identity, and operational controls for containment and investigation. If escalation or coordination with your commercial environment is necessary, plan for out-of-band processes that use separate identities and secure transfer mechanisms.

# Practical next steps

1) Inventory which workloads must live inside EUSC for sovereignty and which can stay in commercial Regions. 2) Adapt IaC to detect partition at runtime. 3) Deploy a mirrored landing zone inside aws-eusc with its own Organization, identities, and logging. 4) Update CI/CD and artifact flows to use partition-specific credentials and endpoints.

Treat the European Sovereign Cloud as an independent cloud to keep architecture predictable, auditable, and aligned with European digital-sovereignty requirements.