Announcing the AWS Digital Sovereignty Well-Architected Lens

As organizations accelerate cloud adoption, meeting digital sovereignty requirements has become essential to build trust with customers and regulators worldwide. The challenge isn’t whether to adopt the cloud—it’s how to do so while meeting sovereignty requirements, using a multidisciplinary approach.

Even though requirements vary by geography, organizations commonly address them through technical and operational controls applied consistently at scale. Controls address specific needs related to data residency, data protection, data privacy, access control, and resiliency. These controls also map to security and privacy baselines plus industry regulations. Examples include German BSI C5, UK GDPR, EU DORA, and newer regulations such as the EU AI Act.

Beyond technical and operational controls, in some jurisdictions, customers might have to align with interoperability and portability mandates requiring the adoption of specific infrastructure components, technology standards, and locally sourced software components.Partners and customers have said that they understand how AWS is sovereign-by-design, but they want to go further and apply those same design principles and best practices to their own workloads. Today, we’re introducing the AWS Digital Sovereignty Well-Architected Lens, a framework that helps you design, build, and operate workloads that are sovereign, compliance-aligned, and auditable while being survivable, interoperable, and portable across a range of deployment options.

The Digital Sovereignty Lens is available in the form of a whitepaper and as a custom lens file from AWS Well-Architected custom lens GitHub repository.

The AWS Well-Architected Framework

The AWS Well-Architected Framework is a structured assessment tool divided into six pillars. Each pillar is organized into a hierarchy of themes, questions, and best practices. Best practices describe the benefits of adoption. They also list actionable implementation guidance and implementation steps. The Digital Sovereignty Lens follows the same structure and is meant to complement the Well-Architected Framework. It presents additional questions and best practices designed to improve the digital sovereignty posture of your workloads.

How is the lens organized?

The Digital Sovereignty Lens outlines more than 60 best practices spread across the four pillars of Operational Excellence, Security, Reliability, and Performance Efficiency. It does not add new best practices to the Cost Optimization and Sustainability pillars. You should use existing best practices already defined in the Well-Architected Framework under those two pillars.

Each best practice in the Digital Sovereignty Lens maps to a specific question of the form “How do you do X?” For example, for the question “How do you design your workload for continuous auditability?”, the associated best practices include planning and preparing for audits, and automating evidence collection and reporting.

Underpinning the questions and the associated best practices are a set of design principles. The design principles list the key challenges organizations face and document steps required to address those challenges.

Design principles

The Digital Sovereignty Lens outlines five core design principles that engineering teams can adopt to address sovereignty requirements. These design principles build on top of secure by design and privacy by design principles. The principles and the key areas they address include:

• Apply standardized enforceable controls – Rather than relying on spreadsheets and manual enforcement, apply standardized compliance-aligned controls using policy as code and compliance as code practices. Automated controls leave no room for interpretation and reduce the risk of inconsistent implementations across teams.
• Establish adequate security posture in line with data sensitivity levels – Apply access controls, build data perimeters, and protect data at rest, in transit, and during compute. Calibrate controls to data sovereignty requirements—such as residency and export controls—to maintain business agility without compromising security or compliance.
• Design for continuous compliance – Point-in-time certifications are just snapshots. Integrate compliance checks throughout your software development lifecycle and collect evidence required for audits on a continuous basis. When compliance is built in from the start, you reduce compliance violations and maintain a consistently audit-ready posture.
• Design for interoperability and portability – Design workloads for interoperability and portability from the start. Build abstractions into your code and configurations, then test across multiple environments to verify consistent functionality.
• Design for survivability – Document system dependencies and fault isolation boundaries. Align your recovery objectives with business continuity goals, define what a minimum restorable service looks like, and test your recovery paths regularly.

Best practices

The following diagram provides a snapshot of some of the best practices in the lens.

Trust and transparency are key attributes of a sovereign workload. Trust is achieved through verification, not through claims. The Operational Excellence pillar focuses on best practices that lead to continuous compliance and auditability, improving verifiability. The Security pillar provides best practices that lead to greater visibility of controls and recommends independent Regional operations. The Reliability pillar addresses the need to achieve a balance between sovereignty and survivability by carefully considering how you design workloads for automated recoverability and protect data sovereignty. The Performance Efficiency pillar focuses on adopting standard protocols to optimize networking and compute in alignment with regulatory needs.

Who should use this lens?

The following users can benefit from this lens:

• Policy-makers and regulators – Use the sovereignty outcomes and general design principles as described earlier in this post to develop jurisdictional and sectoral digital sovereignty models.
• Technical leaders (CxOs and enterprise architects) – Use the lens as an input while outlining enterprise architecture strategies, or towards making objective technology decisions.
• Security and compliance consultants – Use the design principles and best practices to develop privacy and security policies that can subsequently be translated into technical and operational controls.
• Builders – Use the lens as a key input while designing, developing, and validating sovereign-ready workloads.
• Audit professionals – Use the implementation steps described in the best practices to understand possible sources of evidence and artifacts they should seek during security and privacy audits.
• Governance risk and compliance professionals – Use the lens to understand and document the overall risk landscape. Develop per-application risk profiles and manage risks over time.

Your path to sovereign-ready workloads

The Digital Sovereignty Lens is part of a wider effort at AWS to equip our customers with comprehensive guidance and tools required to address their sovereignty needs. We recently introduced the AWS European Sovereign Cloud: Sovereign Reference Framework (ESC-SRF). Customers and partners can use the ESC-SRF (available from AWS Artifact) as a foundation upon which they can build their own complementary controls when using the AWS European Sovereign Cloud. This can also be used as supporting documentation as part of audits showing how AWS meets sovereignty requirements across dimensions such as independence, operational control, data residency, and technical isolation.

During and leading up to AWS re:Invent 2025, we announced several new capabilities designed to increase trust, bring more transparency, and provide customers with more control and choice. They include the Nitro Isolation Engine, IAM Policy Autopilot, the Landing Zone Accelerator on AWS Universal Configuration, Controls Dedicated experience in AWS Control Tower, and productivity tools such as the CloudFormation IDE Experience.

We are not stopping here. We look forward to your feedback as we continue to improve the lens content. We will also continue to develop decision guides, reference architectures, prescriptive guidance, and solution accelerators that embed and codify the best practices described in the lens.

About the authors