AWS Architecture Blog
Announcing the AWS Digital Sovereignty Lens for the Well-Architected Framework
October 2026: This post was reviewed and updated for accuracy.
Today we’re launching the AWS Digital Sovereignty Lens, a new Well-Architected lens providing customers with extended guidance for designing, building, and operating sovereign workloads on AWS.
Customers tell us that digital sovereignty brings a unique set of challenges that existing architecture guidance doesn’t fully address. Sovereignty requirements don’t arrive as a single brief. They come from multiple teams, including privacy, legal, compliance, and security. These requirements sometimes conflict. For example, a localization mandate requires in-country storage, whereas resilience might call for replication across jurisdictions.
Sovereignty also depends on coordinated choices across compute, storage, networking, identity, encryption, and operations. A decision in one layer can weaken a control in another. Third-party dependencies, from software libraries to external APIs, carry jurisdictional exposure of their own.
The lens builds on the AWS Digital Sovereignty Pledge we made in 2022, our commitment to giving you sovereignty controls and features in the cloud without compromising on capabilities, performance, innovation, and scale.
Five questions that define a sovereign workload
The lens treats sovereignty as an architectural concern. It uses five questions to help you determine which concerns apply to your workload and to what degree:
- Where is the workload located? (locality)
- Who can reach it? (access control)
- Will it keep working when conditions change? (continuity)
- Can it be transferred elsewhere? (portability and interoperability)
- Can you prove sovereignty controls are in place? (transparency and auditability)
The first four concerns can trade off or influence one another. Mandates that restrict technology choices to a narrow pool of providers, for example, can constrain your recovery and exit options. You decide which concern takes precedence, which risks to accept, and why. The fifth question plays a different role. It asks what controls and evidence demonstrate that the other four concerns are addressed.
What’s in the lens
If you’ve run a Well-Architected review the structure is familiar: pillars, questions, and best practices. The lens covers four of the six pillars, with 21 questions and 37 best practices:
- The operational excellence pillar covers sovereignty governance, compliance automation, continuous auditability, compliance monitoring and remediation, and regulatory change. It answers the fifth question (of the Five questions that define a sovereign workload): can you prove sovereignty controls are in place?
- The security pillar covers secure foundations, access control, control verification, threat detection, operator access, data protection, and event response. It answers the first two questions: where is the workload located, and who can reach it?
- The reliability pillar covers continuity planning, third-party risk, portability and interoperability, and disruptions beyond technical failures. It answers questions three and four: will it keep working, and can it be transferred?
- The performance efficiency pillar covers sovereign deployment choices and software-dependency assessment, weighing all five questions against each other.
For the remaining two pillars, cost optimization and sustainability, the existing Well-Architected guidance applies to sovereign workloads.
What are sovereignty controls?
Sovereignty controls build on capabilities that builders already use, including service control policies (SCPs), resource control policies (RCPs), AWS Identity and Access Management (IAM) policies, firewall rules, and backup policies. No single control meets data residency, data sovereignty, or continuity requirements on its own. They layer together in a defense-in-depth approach. AWS Control Tower groups these controls under its digital sovereignty category, covering data residency, granular access restriction, encryption, and resiliency.
The lens also covers controls you build yourself. These include validating infrastructure templates with AWS CloudFormation Guard, verifying access policies with IAM Access Analyzer, and detecting configuration drift with AWS Config.
Not every sovereignty control is technical. Deciding which personnel can provide operational support, from which locations, and under what authority is an operational control. Reviewing that access on a regular schedule is another. Together, technical and operational controls combine to produce continuous evidence of your sovereignty posture.
This is what sovereign-by-design means in practice. AWS builds sovereignty foundations, such as the Nitro System, which enforces access restrictions so that nobody, including AWS employees, can access customer data running in Amazon Elastic Compute Cloud (Amazon EC2). Your controls express jurisdictional requirements on top of those foundations, using familiar policy tools reinforced by operational controls.
Where sovereignty requirements arise
Sovereignty requirements extend beyond public sector workloads. The lens describes seven scenarios where they commonly arise. Four of them illustrate the range:
- You’re expanding a workload into a new jurisdiction and need to identify which obligations apply before you deploy.
- Regulation restricts who can provide operational support for your workloads, from where, and under what authority.
- Residency constraints limit your disaster recovery options, and you need recovery paths that hold within approved jurisdictional boundaries.
- You’re adopting emerging technology such as generative AI, and need to confirm that new data flows and dependencies don’t undermine existing sovereignty controls.
If one or more scenarios match your workload, the lens applies to you.
How to use the lens
The lens works with the AWS Well-Architected Tool. Import it as a custom lens, select a workload, and run a review. The review identifies high- and medium-risk issues, which you prioritize and address through targeted improvement plans. This grounds sovereignty decisions in evidence rather than assumptions.
For your first review, include participants from engineering, legal, compliance, and security. Together, they can connect applicable obligations to workload evidence, prioritize risks, and agree on remediation plans. Record assumptions, accepted risks, owners, and follow-up actions. Repeat the review when regulations, workloads, dependencies, or operating conditions change.
Getting started
The Digital Sovereignty Lens is available today in the AWS Well-Architected custom lens GitHub repository. Download the lens definition, import it into the AWS Well-Architected Tool, and run your first review.
To learn how AWS builds sovereign-by-design infrastructure and controls, visit AWS Digital Sovereignty. For help addressing technical and operational sovereignty requirements, consider engaging AWS Digital Sovereignty Competency Partners.
In 2022, we pledged control without compromise. The Digital Sovereignty Lens is how you architect for it.