Practical digital sovereignty: Building a sovereign landing zone on AWS

When a government organization deploys workloads across multiple Amazon Web Services (AWS) accounts without a consistent sovereignty baseline, the result is fragmented controls, scattered audit evidence, and compliance gaps that auditors quickly identify. A sovereign landing zone solves this. It transforms digital sovereignty from aspiration into operational reality by embedding control, continuity, and compliance into an automated, auditable, and enforceable multi-account foundation.

In the first post of this series, Practical digital sovereignty: Navigating the pillars of compliance, continuity, and control, we introduced digital sovereignty and its three foundational pillars of compliance, continuity, and control, which cover the five essential characteristics of a sovereign workloads: Locality, Access control, Continuity, Portability and Interoperability, and Transparency and Auditability. We outlined a three-step approach to achieving it. First is establishing foundational controls, then implementing specific security measures, and finally, maintaining continuous monitoring and auditing. We also emphasized the importance of understanding your sovereign requirements first—discovering, cataloguing, and establishing ownership of data and workloads before building any environment.

In this post, we translate those pillars into a deployable cloud foundation, focusing on the key postures of security (encryption, isolation, data protection), identity management (access control, authentication), governance (guardrails, policy enforcement), network design (segmentation, boundary protection), resilience (multi-AZ deployment, redundancy, failover), continuity (disaster recovery, backup, business survivability), auditability (logging and monitoring), and operational independence (data residency, granular access, jurisdictional control).

We outline what a sovereign landing zone is and how the Landing Zone Accelerator (LZA) on AWS Universal Configuration makes it achievable, deploying a comprehensive and Well-Architected environment, built to support today’s regulated and sovereign workloads and data and tomorrow’s generative AI and agentic AI solutions.

What is a landing zone

A landing zone (LZ) is a well-architected, multi-account environment that provides a secure, scalable foundation from which to deploy workloads and data—a security baseline applied to every account in the LZ before a single workload is deployed. It establishes an account structure with dedicated security functions and perimeter boundaries, consistent network connectivity patterns, centralized identity and access management, uniform security controls, and governance guardrails that prevent common misconfigurations.

AWS Landing Zone Accelerator (LZA) provides a multi-account AWS environment with automated setup and governance. The deployment process orchestrates infrastructure provisioning across a Management Account, Log Archive Account, and Audit Account. CloudFormation initiates the installer pipeline, which uses AWS CodePipeline and CodeBuild to pull configuration from GitHub and deploy resources. Once deployed, the system centralizes logging, encryption key management, and audit controls across accounts, enabling secure and compliant infrastructure at scale.

Figure 1: Diagram of an AWS accelerator deployment system showing 

Why it matters for sovereignty

Without a well-designed landing zone, sovereignty controls are applied inconsistently, manually, and likely reactively, creating gaps that undermine compliance efforts, introduce operational risk and hamper auditability. For example, individual teams might configure encryption differently, network boundaries might vary from account to account, and audit evidence might be scattered across dozens of disconnected logging configurations.

A landing zone addresses this by establishing consistent baselines so that every account inherits foundational security controls from the moment it is created. Within the AWS Landing Zone Accelerator (LZA) you create configurations for:

• AWS Organizations creates a hierarchical account structure that groups workloads by function and risk profile, enabling separation of duties through clear organizational boundaries between infrastructure, security, and workload teams.
• Service control policies (SCPs) applied at each level of the hierarchy establish preventive guardrails, enforcing data residency constraints, restricting services to approved Regions, and preventing the removal of security controls. As a result, individual accounts can’t deviate from sovereignty requirements regardless of the permissions granted within it.
• Dedicated audit and logging accounts support compliance is supported through centralized evidence collection, defining detective controls, and enabling continuous verification against regulatory frameworks. This allows governance to scale automatically, so that new accounts receive appropriate configurations without manual intervention.

To understand how you might build your landing zone, you first need to understand your sovereign requirements. In our first post, we described the foundational step of discovery, cataloguing, and establishing ownership to build a compliance matrix that captures those requirements. The AWS Well-Architected Digital Sovereignty Lens is the mechanism for reasoning about that matrix architecturally: it adds seven design principles that extend the operational excellence, security, reliability, and performance efficiency pillars of the Well-Architected Framework, mapped to five design concerns — locality, access control, continuity, portability, and transparency. Applying the Lens, you can evaluate your architecture against sovereignty best practices from the outset, recognizing that a workload’s sovereignty posture is defined by the verifiable technical controls actually in effect. A sovereign landing zone is how those design decisions become enforced, and the LZA Universal Configuration is the tool that deploys the controls, so the requirements identified during that phase flow into enforced, automated infrastructure where continual compliance is continuously verified.

Making it Sovereign

A sovereign landing zone extends the standard landing zone concept by embedding digital sovereignty requirements—data residency, access control, encryption, resilience, and compliance—directly into the foundational architecture.

Each pillar translates into specific, enforceable capabilities:

• Control (Locality and Access Control) – Oversight of data location, protection, access, processing, and movement is maintained in the sovereign landing zone through multiple layers of enforcement. Data residency is ensured using regional deny policies, while preventative and detective guardrails are implemented through Service Control Policies (SCPs), AWS Config rules, and AWS CloudFormation Hooks Encryption is enforced via AWS Key Management Service (AWS KMS) and AWS KMS external key stores, ensuring keys remain under customer control. Access restriction policies limit data movement and processing, and centralized identity management ensures only authorized principals can interact with sensitive data.
• Continuity – Business survivability and resilience against threats from system outages to geopolitical events is achieved in the sovereign landing zone through multi-AZ architecture patterns and tiered AWS Backup policies (continuous, hourly, daily, weekly, and monthly). Resilience baselines are established, and cold storage transitions are configured for long-term retention. The continuity dimensions – survivability, resiliency, operational independence, infrastructure and data management, recovery and testing, and interoperability and portability are each addressed through automated, policy-driven mechanisms that ensure business operations remain independent and recoverable under diverse threat scenarios.
• Compliance (Transparency and Auditability) – Adherence to cybersecurity standards, privacy regulations, industry-specific rules, and internal policies. The Landing Zone Accelerator automates the deployment of a security baseline mapped to regulatory frameworks, continual monitoring using AWS Security Hub, audit-ready configurations with immutable logging, and clear shared responsibility alignment. The LZA Compliance Workbook, detailed later in this post, maps these technical controls to twelve compliance frameworks, including ISO27001, C5, NATO D-32, and NIST 800-53 Rev5, as examples.

Shifting compliance left

Many regulatory and legal requirements are written in legal or policy language and need to be translated into technical implementations. This is one of the most significant challenges organizations face when pursuing digital sovereignty. Manual documentation and interpretation of control requirements often lead to complexity and errors. Organizations should integrate controls early into infrastructure provisioning processes, not add them on as an afterthought.

The translation problem

Consider a typical sovereignty requirement in which customer data must remain within national boundaries and be accessible only by authorized personnel. To address this single policy requirement, LZA deploys at least eight distinct technical implementations:

1. Service Control Policies (SCPs) preventing resource creation in non-approved regions
2. Amazon Virtual Private Cloud (Amazon VPC) configurations preventing traffic from traversing unauthorized locations
3. AWS Identity and Access Management (IAM) policies restricting access based on identity attributes
4. Encryption keys (AWS KMS) managed within sovereignty boundaries
5. AWS CloudTrail logging proving compliance
6. AWS Config rules detecting violations
7. Security Hub dashboards aggregating findings
8. AWS Backup providing survivability and continuity

Now multiply this across hundreds of control requirements within a single compliance framework, each requiring multiple technical implementations. With organizations operating across borders or industries, they need to satisfy multiple frameworks simultaneously, each with overlapping but distinct requirements requiring multiple implementations steps across environments and workloads. Without a systematic approach, this quickly becomes unmanageable.

Universal Configuration can replace months of complex planning, deploying hundreds of controls in hours with more predictable and successful audit outcomes.

The first post in this series introduced the compliance matrix where rather than treating each framework independently, it identifies where requirements overlap and maps them to a single set of technical controls that satisfy multiple frameworks simultaneously. This eliminates redundancy, reduces implementation effort, and means that a single sovereign landing zone deployment can address compliance obligations across geographic regions and industry verticals.

The LZA Compliance Workbook

The LZA Compliance Workbook, available on AWS Artifact, is a first-of-its-kind resource that blends infrastructure-level security, AWS Well-Architected, and the AWS Security Reference Architecture best practices with compliance alignment in a single place. It provides:

• Detailed security configuration descriptions based on the Universal Configuration deployment files documenting exactly what each configuration setting does and why
• Control requirement mappings across twelve compliance frameworks identifying which Universal Configuration controls address which regulatory requirements
• Implementation statements that translate Universal Configuration security capabilities into a compliance-friendly format providing the narrative evidence that auditors need

Geographic complexity

Geographic variation compounds this challenge. Different regions require alignment with different standards, for example: C5 in Germany, ENS in Spain, BIO in the Netherlands, NIST 800-53 for US federal workloads, NATO D-32 for defense, NERC-CIP for critical infrastructure, and ISO 27001 globally. A sovereign landing zone must be locally tailorable yet architecturally consistent. The Compliance Workbook’s multi-framework coverage demonstrates that the same Universal Configuration controls can help address requirements across frameworks.

The following table lists the frameworks supported at time of this writing.

Using the Workbook across the compliance lifecycle

The workbook supports each phase of compliance management:

• Observe and remediate – Documenting which detective controls monitor which requirements and what automated remediation is triggered on violation
• Audit – Providing implementation statements that describe what the Universal Configuration configures, why, and where evidence can be found
• Vendor compliance – Delineating the shared responsibility boundary between Universal Configuration–implemented controls and those the customer must address at the application and operational level

Important caveat

The LZA Universal Configuration will not, by itself, make you compliant. It offers a best-practice approach to establishing a well-architected AWS multi-account environment from which additional complementary solutions can be integrated. You must review, evaluate, and approve the solution according to your organization’s security requirements and determine applicable regulatory obligations. The LZA Universal Configuration can save immense time in designing a compliance-ready system architecture and automatically deploying it. However, you must also consider controls for the workloads, data, and users of the services you deploy, looking wholistically across the entire system.

LZA Universal Configuration

LZA on AWS is an open source solution published on GitHub that automates the deployment of a secure, multi-account environment aligned with AWS best practices and compliance frameworks.

LZA has been developed from years of field experience with highly regulated customers, including governments worldwide, and in consultation with AWS Partners and industry experts. The Universal Configuration implements a purpose-built hierarchy multi-account architecture using AWS Organizations with dedicated organizational units (Ous) for security, infrastructure, and workloads. The following is an example of OU structure:

Figure 2: Example OU structure

Following the AWS Security Reference Architecture (SRA), the sovereign landing zone uses three accounts to implement centralized security and compliance controls:

• The Security Tooling account (Audit) serves as the delegated administrator for centralized security services, including AWS Config, Amazon GuardDuty, Security Hub, Amazon Macie, AWS IAM Access Analyzer, Amazon Detective, AWS Audit Manager, and AWS CloudTrail, so the security team can manage, monitor, and respond to findings across the organization from a single account without requiring access to the management account.
• The LogArchive account maintains an immutable audit trail.
• The SharedServices account hosts AWS IAM Identity Center delegation for centralized identity management.

Graduated SCPs enforce governance proportional to risk—from data protection and encryption enforcement, through identity and security service protection, to network controls on infrastructure accounts. A quarantine SCP locks new accounts completely until the LZA pipeline completes configuration, ensuring no account ever operates without its security baseline. AWS Control Tower implements data residency controls separately, providing the overarching framework within which LZA operates.

AI-powered compliance and deployment

To demonstrate the power of combining the extensive documentation and compliance data of LZA with generative AI, we built the Landing Zone Accelerator Support Agent. This agent provides natural language access grounded in the source material to the configuration details, compliance mappings, and deployment guidance of Universal Configuration.

You can build something similar for your own environment using Amazon Quick. The agent’s knowledge base includes the LZA Compliance Workbook, the LZA Implementation Guide, and the Universal Configuration GitHub repository connected through webhooks, so the agent references the latest configuration files and compliance mappings.

To set up your own agent, follow these steps:

1. Create a custom chat agent in Amazon Quick
2. Set up a space and connect your LZA knowledge sources
3. Configure the agent instructions to specialize in LZA deployment and compliance guidance

Instead of manually searching through spreadsheets, GitHub pages, and PDF documentation, teams can ask questions in natural language and receive immediate, grounded answers. For example, prompting the agent with a question like, “How does LZA support encryption requirements for Germany C5?” produces a detailed response identifying the specific Universal Configuration controls that address C5 encryption requirements, including AWS KMS configuration for customer managed keys, Amazon Simple Storage Service (Amazon S3) bucket encryption policies enforced through SCPs, Amazon Elastic Block Store (Amazon EBS) default encryption settings across all accounts, and AWS CloudTrail log encryption.

The agent references exact configuration file paths and compliance workbook mappings, providing teams with immediately actionable implementation details rather than generic guidance. Being able to retrieve this information through natural language makes sovereign landing zone configuration accessible to compliance officers, solution architects, and security engineers alike.

To get started building your own LZA support agent, visit Amazon Quick chat agents to learn about creating custom chat agents and refer to the documentation on working with agents for step-by-step instructions.

AI-assisted management and deployment

The Universal Configuration supports AI-assisted management through the LZA MCP server—an open source Model Context Protocol (MCP) server providing guided UC merge (select a network model, customize settings, validate compatibility, and merge through natural language), schema discovery (explore LZA configuration schemas for your deployed version), and pipeline orchestration (deploy, monitor, and diagnose pipeline executions from your integrated development environment). The MCP server ships with Universal Configuration release artifacts embedded, requiring no separate download.

Partners at the core

Navigating digital sovereignty is complex, but you don’t have to do it alone. AWS Digital Sovereignty Competency Partners demonstrate expertise across four pillars: data residency and data perimeter controls, data protection and encryption key management, access control and privilege management, and operational independence and survivability.

Get expert guidance from AWS Partners like Atos, who provides cloud for clinics and German healthcare solutions, including C5-certified landing zones with GDPR and healthcare-specific controls. SVA offers C5-certified managed services in Germany. Schellman brings C5 assessment expertise and has collaborated directly on LZA development. And SoftwareOne delivers LZA implementations tailored for midmarket organizations.

The LZA serves as a common platform that accelerates partner delivery. Partners focus their differentiation on top with industry-specific controls, managed services, and compliance advisory rather than rebuilding baseline infrastructure for every customer. For the latest partner offerings, search Landing Zone Accelerator in the AWS Partner Finder tool.

Summary

Digital sovereignty isn’t achieved through a single policy decision or a one-time deployment—it’s an operational discipline embedded into the foundations of your cloud environment. This post has shown how the LZA Universal Configuration translates the three pillars of control, continuity, and compliance into automated, auditable, and enforceable architecture: from graduated SCPs that prevent deviation before it occurs to centralized security services that detect and respond to threats across the organization to a compliance workbook that maps hundreds of technical controls to twelve regulatory frameworks simultaneously. The sovereign landing zone makes sovereignty measurable, not aspirational.

Foundations are only the beginning. Future posts in this series will explore how workloads inherit and extend these controls at the application layer, how generative AI and agentic AI solutions can operate within sovereignty boundaries, and how specific regional implementations address local regulatory requirements. Whether you’re beginning your sovereignty journey or maturing an existing environment, the Universal Configuration provides a production-ready starting point. Deploy in hours what previously took months and invest the time saved into the workloads and innovation that drive your mission forward.