AWS European Sovereign Cloud: How to Build a Secure Landing Zone

AWS has published an architectural guide for building secure landing zones in the AWS European Sovereign Cloud (EUSC), its independent cloud environment for Europe.

The European Sovereign Cloud is physically and logically separated from existing AWS commercial Regions and operates within the European Union. AWS describes it as a distinct AWS partition called aws-eusc, with its own control plane, IAM environment, billing, console, and service endpoints.

That partition boundary is the central architectural consideration.

Organizations cannot treat EUSC as simply another AWS Region inside the standard commercial aws partition. Cross-partition IAM credentials, role assumption, VPC peering, Transit Gateway connectivity, AWS RAM, and services such as Amazon S3 replication do not operate across the boundary.

Instead, AWS recommends building an independent landing zone inside EUSC while connecting commercial AWS environments to it through controlled network or API integrations when required.

The AWS guidance covers account structure, governance, infrastructure as code, identity, centralized logging, security monitoring, network controls, encryption, CI/CD, artifact distribution, billing, and incident response.

It also maps the architecture to the AWS Security Reference Architecture and the AWS Well-Architected Framework.

The Key Concept: EUSC Is a Separate AWS Partition

AWS organizes Regions into partitions. Commercial AWS Regions operate in the aws partition, China Regions use aws-cn, and GovCloud uses aws-us-gov.

The European Sovereign Cloud operates in aws-eusc, with its first Region in Brandenburg, Germany, identified as eusc-de-east-1.

This creates several practical differences for architects.

Cross-Region capabilities such as S3 replication and Transit Gateway inter-Region peering work within a partition, but not across different partitions.

This means organizations need to think about EUSC as a separate AWS environment rather than simply adding another Region to an existing commercial deployment.

For example, a company operating a standard CI/CD environment in commercial AWS can still deploy into EUSC, but the integration must use separate credentials and operate through a network or API-level connection.

Building Partition-Aware Infrastructure as Code

One of AWS's first recommendations is to make infrastructure code aware of the partition in which it is running.

Hardcoding arn:aws: into Terraform or CloudFormation templates can create problems when the same infrastructure modules need to operate in EUSC.

AWS demonstrates using Terraform's partition data source to determine whether the deployment is running in aws, aws-eusc, or another AWS partition.

The same principle applies to CloudFormation, where the AWS::Partition pseudo parameter can be used when constructing ARNs.

The objective is straightforward: infrastructure code should derive the correct partition rather than assuming that every AWS resource uses the commercial aws partition.

This allows common infrastructure modules to be reused across supported AWS environments while preserving the correct ARN structure.

One important exception highlighted by AWS is IAM service principals. These continue to use the amazonaws.com form rather than being constructed from AWS::URLSuffix.

Account Structure and Governance

AWS recommends using the AWS Security Reference Architecture's multi-account model for EUSC deployments.

AWS Control Tower can be used to establish and govern the multi-account environment, working with services including AWS Organizations, AWS Service Catalog, and IAM Identity Center.

The management account should be reserved for governance rather than normal workload operations.

AWS recommends applying security controls through mechanisms such as:

• Service control policies

• Resource control policies

• AWS service deployments

• AWS CloudTrail

• Service-level restrictions

• Network perimeter controls

• Encryption and key-management requirements

Region-deny policies commonly used in commercial AWS environments are not currently required in EUSC because of the partition's physical and logical separation.

AWS notes that this could become relevant if additional EUSC Regions or Local Zones become available and organizations need to restrict workloads to a specific subset.

Identity: Manage IAM Access as Infrastructure

IAM Identity Center is available as an independent instance within EUSC.

Organizations can connect the EUSC instance to an existing external identity provider using SAML and SCIM. AWS gives Microsoft Entra ID and Okta as examples of identity providers that can be used for this model.

An organization can therefore use the same corporate identity provider for commercial AWS and EUSC while maintaining separate IAM Identity Center configurations in each partition.

Permission sets, groups, and account assignments remain independently managed.

AWS's example uses Terraform to define:

• An IAM Identity Center permission set

• AWS managed policies

• An inline least-privilege policy

• A group for analytics operators

• An account assignment connecting the group to a workload account

The broader architectural principle is to manage access configuration as code rather than relying on manual configuration.

Group membership can continue to be managed by the corporate identity provider through SCIM.

AWS also recommends avoiding direct human access to the management account. Instead, users should access workload accounts through IAM Identity Center permission sets.

Cross-Account Roles Stay Inside the Partition

Cross-account IAM roles continue to work normally within EUSC.

This allows security, logging, governance, and tooling accounts to collect information from workload accounts.

However, AWS emphasizes that a role in the commercial aws partition cannot assume a role in aws-eusc, and the reverse is also true.

Organizations therefore need separate credentials and trust relationships for each partition.

Centralized Logging and Security Monitoring

AWS recommends centralizing security telemetry within the EUSC partition.

The architecture has three core elements:

1. A centralized and immutable location for audit and operational logs

2. A central security account for detective controls and security findings

3. An in-partition path for sending telemetry to a SIEM

The Log Archive account provides the centralized location for organization-level logs.

AWS notes that global service events are handled within the independent EUSC control plane rather than being routed through the commercial AWS environment.

GuardDuty and Security Hub are also available in EUSC.

However, AWS notes that organization-wide automatic enablement and some newer features may differ from commercial AWS capabilities at a given point in time.

Where organization-level automation is not available, AWS recommends enabling services on individual accounts through infrastructure as code, including CloudFormation StackSets where appropriate.

AWS says the EUSC service and feature list should be treated as the source of truth when designing optional security capabilities.

Network Security and Perimeter Design

Network architecture is another area where the EUSC partition boundary has direct consequences.

AWS recommends terminating Direct Connect connectivity in a dedicated Network account and using Transit Gateway to share connectivity with workload VPCs.

Commercial AWS Direct Connect infrastructure cannot simply be extended into the EUSC partition.

Organizations that need Direct Connect connectivity into EUSC must provision connectivity for the EUSC environment.

AWS describes a perimeter design based on centralized egress and inspection.

Workload VPCs can remain private while outbound traffic is routed through an inspection VPC. Organizations can use a gateway load balancer with their preferred firewall or AWS Network Firewall.

For private AWS service access, AWS recommends VPC interface endpoints so service traffic remains within the AWS network and partition.

VPC endpoints do not cross partitions.

If an EUSC workload needs access to a service hosted in the commercial partition, AWS recommends exposing that service through a controlled network connection and an in-EUSC load balancer rather than expecting the VPC endpoint itself to cross the partition.

DNS also requires partition-aware planning.

EUSC has its own Amazon Route 53 environment. Organizations that need name resolution between clouds can use mechanisms such as subdomain delegation or Resolver forwarding over a Direct Connect or VPN connection.

Data Protection and Key Management

AWS recommends customer managed KMS keys for sensitive data stores and enforcing encryption requirements through SCPs and key policies.

For organizations with requirements around external control of key material, AWS also describes using AWS KMS External Key Store (XKS).

With XKS, AWS KMS connects to an external key manager through an XKS proxy. The external key manager can be backed by an EU-based hardware security module or an EU trust service provider.

AWS notes that this approach introduces trade-offs, including additional latency, reduced availability SLA, and increased operational responsibility.

The source recommends reserving XKS for workloads where regulatory or contractual requirements specifically call for that model.

AWS also states that the EUSC Region has achieved SOC 2 and BSI C5 Type 1 attestation, along with seven ISO certifications. These include ISO 27001, ISO 27017, ISO 27018, and ISO 27701.

Secure CI/CD and Artifact Distribution

Cross-partition supply-chain operations require a different approach because commercial AWS and EUSC cannot directly replicate several types of resources across the boundary.

AWS specifically identifies limitations around:

• Amazon ECR cross-partition replication

• AMI cross-partition copying

• Amazon S3 cross-partition replication

Instead, AWS recommends treating EUSC as an independent supply-chain destination.

For container images, organizations can build or re-tag and re-sign images and push them into an EUSC Amazon ECR registry.

ECR replication can then operate between Regions within the EUSC partition when additional EUSC Regions or Local Zones become available.

For AMIs and other machine images, AWS recommends rebuilding golden images inside EUSC using EC2 Image Builder or importing virtual machine images through EUSC-based S3 workflows.

For binaries and other artifacts, organizations can stage packages in an EUSC artifact bucket and move them across the boundary using controlled mechanisms such as aws s3 sync, AWS DataSync, or controlled export.

Once inside EUSC, artifacts can be distributed using services available within the partition.

Replicating Deployment Pipelines

AWS recommends running a native deployment plane inside EUSC when possible.

Organizations can use services such as AWS CodePipeline, CodeBuild, and CodeDeploy within the partition, or operate another deployment system inside EUSC.

The Shared Services account can host the deployment infrastructure, with cross-account deployment roles used to reach workload accounts.

If a commercial AWS CI system must deploy into EUSC, AWS recommends separate credentials for each partition.

The source describes OIDC federation with separate trust configurations as one approach.

This reflects the larger principle running throughout the architecture: integration between partitions is possible, but it should not be treated as cross-partition IAM trust.

Landing Zone Automation With AFT and LZA

AWS recommends Account Factory for Terraform (AFT) as one option for account vending and landing-zone-as-code.

AFT can be deployed within EUSC to create accounts through Control Tower, apply baseline guardrails, bootstrap partition-aware infrastructure modules, and manage organizational units.

Terraform state should remain within the relevant partition. AWS recommends using an in-EUSC S3 backend and DynamoDB lock table rather than sharing state between commercial AWS and EUSC.

Another option is the Landing Zone Accelerator on AWS (LZA).

AWS says LZA provides a baseline security architecture and supports partition-specific configuration.

The source also references a configuration baseline for European Sovereign Cloud and an accompanying LZA Compliance Workbook that maps European security standards and international frameworks to security settings deployed by LZA.

Supported Capabilities vs. By-Design Boundaries

AWS distinguishes between capabilities that are supported within EUSC, configuration choices, and restrictions that exist because of the partition architecture.

The distinction is important because not every limitation represents a missing feature.

Some boundaries are part of the architecture itself.

Billing and Cost Governance

Billing is also partition-specific.

AWS recommends consolidating billing within the EUSC organization rather than attempting to roll costs into a commercial AWS payer.

AWS Data Exports can be delivered to an S3 bucket in a dedicated finance or governance account.

Workload teams can then receive access to curated cost data without direct access to management or payer accounts.

The EUSC environment has a separate payer and billing system, with billing in EUR through the EU contracting entity.

What This Architecture Means for Cloud Teams

Original analysis

The AWS guidance highlights a broader architectural shift for organizations operating workloads under regional sovereignty requirements.

The primary consideration is not simply where an application is hosted. It is how identity, governance, logging, networking, software supply chains, encryption, billing, and operational tooling behave around the sovereign boundary.

For teams already operating commercial AWS environments, this can mean maintaining two related but independently governed operating models.

Infrastructure as code becomes particularly important because partition-aware modules can reduce configuration differences between environments while still respecting the boundaries between them.

The source also shows why sovereignty requirements can affect DevOps processes as much as application infrastructure. Container images, AMIs, artifacts, credentials, deployment pipelines, and Terraform state all need an explicit strategy for entering and operating inside EUSC.

The announcement highlights a broader industry shift toward cloud architectures where data residency and operational autonomy influence the design of the entire platform rather than a single storage or compute layer.

A Practical Architecture Pattern for EUSC

Taken together, AWS's recommendations describe a landing zone with several distinct layers:

Governance

AWS Control Tower, Organizations, SCPs and RCPs

Identity

IAM Identity Center, corporate IdP, SCIM and permission sets managed as code

Security

Central Log Archive, GuardDuty, Security Hub and SIEM integration

Network

Dedicated Network account, Direct Connect, Transit Gateway, inspection VPCs and private endpoints

Data Protection

Customer managed KMS keys, key policies and XKS where specific requirements justify it

Software Supply Chain

EUSC-native ECR, image signing, artifact storage and deployment infrastructure

Operations

AFT or LZA, partition-aware Terraform modules, centralized governance and in-partition billing

The common thread is that centralization remains possible, but the centralization happens inside the EUSC partition.

Why the Partition Boundary Matters

The most important architectural point in AWS's guidance is that European Sovereign Cloud is not simply another Region in the standard AWS environment.

It is a separate partition with independent identity, organization, billing, endpoints and control-plane boundaries.

That affects seemingly routine cloud operations such as assuming a role, copying an AMI, replicating an S3 bucket, distributing container images, connecting networks, managing billing, and operating deployment pipelines.

For organizations evaluating EUSC, these boundaries need to be considered during landing-zone design rather than treated as exceptions after workloads are deployed.

AWS's recommended approach is to build the EUSC environment as an independent landing zone, automate its configuration, and integrate it with commercial AWS only through explicitly designed network and API paths.

Conclusion

AWS's secure landing-zone guidance for the European Sovereign Cloud centers on one architectural principle: treat EUSC as an independent AWS partition.

Governance, identity, logging, security monitoring, networking, billing, CI/CD and infrastructure automation can all be centralized, but the central operating model needs to exist within the EUSC boundary.

For organizations deploying across commercial AWS and EUSC, partition-aware infrastructure code and separate credentials are central to the operating model. Services that work across Regions within a partition should not be assumed to work across partitions.

AWS also provides AFT, LZA and related configuration resources to help organizations automate the landing-zone build and align the architecture with security and compliance requirements.

The result is an architecture that preserves the independence of EUSC while allowing organizations to integrate it with existing cloud environments through controlled interfaces.