Designing a system for Europe involves more than choosing where its data lives. You also need to decide who can sign in, where audit records go, and how applications reach production. Can an existing AWS foundation simply be extended to cover those needs?

The AWS landing zone architecture article published on September 16, 2026 approaches AWS European Sovereign Cloud, or EUSC, as an independent partition. That boundary determines how existing systems can connect to it.

A landing zone brings together foundations such as account governance, identity, and auditing. Following the path from sign-in to deployment helps distinguish reusable designs from operational resources that need to be established inside EUSC.

The IAM boundary limits extensions of an existing landing zone

Commercial AWS uses the aws partition; EUSC uses aws-eusc. Its first Region is eusc-de-east-1 in Brandenburg, Germany.

Each partition has independent IAM, so credentials from one cannot operate resources in another. Features such as S3 Cross-Region Replication also operate within a partition. The AWS partition documentation explains this boundary.

Consequently, a management role in commercial AWS cannot use AssumeRole to enter an EUSC role. An architecture that depends on that path needs a separate authentication path for EUSC.

Cross-account roles inside EUSC remain available. Centralized management is still possible when its scope stays within the partition.

Reuse account responsibilities and separate SSO assignments

Establish an independent AWS Organizations organization inside EUSC. The AWS Security Reference Architecture account structure provides a useful division of responsibilities.

These responsibilities can match the existing environment, while the organization and its accounts remain separate.

The same distinction applies to workforce access. One corporate IdP can connect to separate IAM Identity Center instances in commercial AWS and EUSC, but permission sets and account assignments are managed independently. The EUSC Identity Center guide documents its instance ARN, access portal, and domains required for portal access.

Authenticating the same employee through the same IdP does not imply identical permissions in both environments. Test access changes for transfers and departures against both sets of assignments.

Make IaC partition-aware and check feature availability separately

To reproduce the account design in code, first review hard-coded arn:aws: prefixes. CloudFormation provides the AWS::Partition pseudo parameter to reference the deployment partition.

For example, an S3 bucket ARN expression can look like this. It is an expression, not a complete template that creates a bucket or grants permissions.

# Supply the target bucket name through AuditBucketName.
!Sub "arn:$AWS::Partition:s3:::${AuditBucketName}"

In EUSC, the prefix becomes arn:aws-eusc:s3:::. Correct ARN construction does not establish feature parity, however. EUSC has no global STS endpoint and uses Regional STS endpoints, so authentication endpoints need review too.

Control Tower availability also differs from feature parity. Its release notes record EUSC support on January 13, 2026. However, the EUSC-specific guide, checked on September 17, 2026, lists Account Factory for Terraform (AFT) and landing zone integration with Identity Center as unavailable.

That conflicts with the September 16 blog recommendation to use AFT. Which document reflects the latest deployed behavior remains unverified, so establish availability in the target environment before making AFT a dependency. Identity Center availability and its integration with Control Tower are separate capabilities.

Keep audit collection and investigation inside the intended boundary

Once identity and governance have a defined boundary, operational records need to follow it. The AWS architecture article recommends collecting logs in an EUSC Log Archive account and administering detection through Security Tooling. Requirements for processing entirely within the EU also extend to SIEM ingestion and analysis.

Audit readiness requires being able to find relevant operations after storing their records. CloudTrail records API activity, but the EUSC CloudTrail guide lists CloudTrail Lake as unavailable as of September 17, 2026. Investigation procedures that depend on Lake therefore need a new search and analysis path alongside their storage design.

One proposed validation is to change a permission in a test environment, locate its record through Log Archive, and verify that the investigator can access it. This exercises collection, storage, and read permissions together; it is a suggested test, not a reported result.

Separate artifact entry into EUSC from deployment within it

The same boundary applies to application delivery. Moving container images from commercial AWS into EUSC requires an explicit push to the EUSC registry using EUSC credentials, rather than cross-partition ECR replication.

Separate artifact entry into EUSC from distribution to its workload accounts. This makes permissions easier to define: deployment after entry can use roles from Shared Services into Workload accounts within EUSC. For external connections, validate network reachability and EUSC authentication separately.

Inspection stages also have availability differences. The EUSC ECR guide lists enhanced scanning as unavailable as of September 17, 2026. If an existing pipeline gates releases on those results, determine where inspection will take place before or during distribution instead of assuming the same stage runs inside EUSC.

Account responsibilities, permission designs, and rules expressed as code can carry over from an existing AWS foundation. Deploy those designs inside EUSC and validate a small path through sign-in, auditing, and deployment to establish where reuse works and additional implementation is needed.

Making that operational path work within EUSC is the starting point for the European environment. Keep the design consistent while establishing independent governance and authentication resources: that is how the landing zone follows the partition boundary.

Source

• Title: Architecting a secure landing zone in the AWS European Sovereign Cloud
• URL: https://aws.amazon.com/blogs/security/architecting-a-secure-landing-zone-in-the-aws-european-sovereign-cloud/