AWS Consulting ·
AWS Digital Sovereignty Lens: what it checks and how to run a sovereignty review
The AWS Digital Sovereignty Lens is a Well-Architected lens for designing, building and operating workloads that must meet sovereignty requirements — where data sits, who can reach it, whether it keeps running when conditions change, whether it can move, and whether you can prove it.
By Upvantix team
The AWS Digital Sovereignty Lens is a Well-Architected lens for designing, building and operating workloads that must meet sovereignty requirements — where data sits, who can reach it, whether it keeps running when conditions change, whether it can move, and whether you can prove it. AWS announced it on 5 October 2026. It covers four of the six Well-Architected pillars — operational excellence, security, reliability and performance efficiency — with 21 questions and 37 best practices; existing Well-Architected guidance covers cost optimization and sustainability.
The lens is delivered as a custom lens: you download the lens definition from AWS's Well-Architected custom lens repository on GitHub, import it into the AWS Well-Architected Tool, attach it to a workload and run a review that flags high- and medium-risk issues for an improvement plan. AWS recommends including engineering, legal, compliance and security in the first review, recording assumptions and accepted risks, and repeating the review when regulations, workloads or dependencies change.
The lens does not tell you which laws apply. Your legal and compliance teams decide that — for example India's DPDP Act and RBI's payment-data storage rule, the UAE's personal data protection law, or US federal requirements such as FedRAMP. The lens helps you show how the workload meets whatever they decide.
This page is general information, not legal or regulatory advice. Confirm which sovereignty and data-residency obligations apply with your legal and compliance teams.
The five questions behind the lens
The lens frames sovereignty as five questions (AWS blog, 5 Oct 2026):
- Locality — where is the workload located?
- Access control — who can reach it?
- Continuity — will it keep working when conditions change?
- Portability and interoperability — can it be transferred elsewhere?
- Transparency and auditability — can you prove sovereignty controls are in place?
- The first four can trade off against each other — a mandate that keeps data in one country can limit disaster-recovery options. The fifth asks for the evidence that the other four are handled.
What the lens covers: 4 pillars, 21 questions
Cost optimization and sustainability: existing Well-Architected guidance applies.
| Criterion | Questions (ID: question) | Which of the five concerns it mainly answers (our mapping) |
|---|---|---|
| Operational excellence (6) | DSOPS01 govern sovereignty controls · DSOPS02 baseline and automate sovereignty compliance · DSOPS03 design for continuous auditability · DSOPS04 monitor current compliance status · DSOPS05 remediate non-compliance · DSOPS06 address regulatory changes | Transparency and auditability |
| Security (9) | DSSEC01 secure foundations · DSSEC02 control access to data within sovereign boundaries · DSSEC03 prove sovereignty controls are effective · DSSEC04 detect and investigate security events · DSSEC05 secure infrastructure access while enabling regional operations · DSSEC06 apply data sovereignty requirements · DSSEC07 verifiable controls over sensitive data · DSSEC08 specialised data protection requirements · DSSEC09 respond to incidents while meeting sovereignty requirements | Locality; access control |
| Reliability (4) | DSREL01 business continuity within sovereign boundaries · DSREL02 third-party sovereignty risks · DSREL03 interoperability and portability across jurisdictions · DSREL04 disruptions beyond technical failures | Continuity; portability |
| Performance efficiency (2) | DSPERF01 select the right sovereign solution per workload · DSPERF02 validate software dependencies for sovereignty compliance | Weighs all five |
When the lens applies: the seven scenarios
The whitepaper lists seven scenarios: public digital infrastructure (such as payment, securities-trading and healthcare platforms); operating in a new jurisdiction; protecting citizens' data under export-control and privacy laws; restricting who can provide operational support and from where; planning for disruptions such as trade restrictions, licensing changes or geopolitical events; aligning with policy-led technology initiatives; and adopting new technology such as generative AI without breaking existing controls.
How to run a Digital Sovereignty Lens review
- Download the lens JSON from the AWS custom lens repository on GitHub (aws-samples/sample-well-architected-custom-lens, folder digital-sovereignty-lens).
- Import it into the AWS Well-Architected Tool as a custom lens, then publish it in your account so it can be applied to workloads.
- Define the workload and apply the lens alongside the Well-Architected Framework lens.
- Run the review with engineering, legal, compliance and security in the room. Answer each question with evidence, not intent.
- Review the high- and medium-risk items and turn them into an improvement plan with owners and dates.
- Record assumptions and accepted risks; repeat when laws, workloads, dependencies or operating conditions change.
The AWS controls the lens points to
- Preventive: service control policies and resource control policies to restrict Regions and resource access; IAM policies; AWS Control Tower's digital sovereignty control group, covering data residency, granular access restriction, encryption and resiliency.
- Detective and verification: AWS Config for drift, IAM Access Analyzer for access paths, AWS CloudFormation Guard for template checks.
- Foundations: the AWS Nitro System restricts access so that nobody, including AWS employees, can access customer data running on Amazon EC2.
- Operational controls: decide which personnel provide support, from which locations and under what authority, and review that access on a schedule.
- No single control meets residency or sovereignty requirements by itself; they layer together.
Sovereignty requirements differ by market (cited examples only)
- India: the DPDP Act, 2023 lets the Central Government restrict transfers of personal data to notified countries (s.16(1)). RBI requires payment system providers to store the entire payment-system data only in India (RBI circular, 6 April 2018). AWS has two India Regions, Mumbai (ap-south-1) and Hyderabad (ap-south-2). See our data residency and DPDP guide.
- UAE: Federal Decree-Law No. 45 of 2021 on personal data protection allows cross-border transfers, in cases approved by the UAE Data Office, where the destination has adequate data-protection law or a relevant agreement applies (Article 22), or, where it doesn't, in listed cases such as a binding contract, the data subject's explicit consent or public interest (Article 23), with details left to executive regulations. Article 2 excludes, among others, government data, health data and banking and credit data that are governed by their own legislation, and free-zone companies with their own data-protection laws. AWS's Middle East (UAE) Region is me-central-1.
- USA: AWS GovCloud (US) Regions address requirements such as FedRAMP High, DoD SRG Impact Levels 4 and 5 and CJIS.
- These are examples, not a full list. Your legal team decides which apply.
Sovereignty review decision table
| Criterion | Questions to answer before the review | AWS controls to check | Evidence to bring |
|---|---|---|---|
| Where data and backups may live | Which laws, regulators or contracts set location? Do backups, logs and DR copies count? | SCPs/RCPs denying non-approved Regions; Control Tower data-residency controls; AWS Backup copy rules | Approved-Region list; policy documents; backup copy configuration |
| Who may operate the workload | Who provides support, from where, under what authority? | IAM Identity Center permission sets; SCPs; break-glass procedure; CloudTrail | Access review records; break-glass log |
| Who controls the keys | Must keys be customer-managed, imported or in a dedicated HSM? | AWS KMS customer managed keys; imported key material; AWS CloudHSM | Key policies; rotation records |
| How it recovers inside the boundary | Can DR stay in-country? What if a Region or provider is unavailable? | Multi-AZ design; second in-country Region where available; restore testing | DR test results; recovery runbook |
| How it could move | What is the exit plan? Which formats and dependencies lock you in? | Infrastructure as code; open data formats; dependency inventory | Exit plan; dependency register |
| How you prove it continuously | Which controls are monitored, and who reviews findings? | AWS Config rules; IAM Access Analyzer; CloudFormation Guard in pipelines | Compliance dashboards; remediation records |
| What new tech changes | Do GenAI or SaaS add cross-border flows or third parties? | Model and inference-location settings; data-flow review | Updated data-flow map; risk acceptance |
How this relates to a standard Well-Architected Review
The lens adds sovereignty questions to a normal review; it doesn't replace it. If you haven't reviewed the workload against the core framework, start there.
Where Upvantix fits
Upvantix is an AWS Select Tier Services Partner. We can help your team prepare for a Digital Sovereignty Lens review: gather the evidence for each question, check Region and access controls in your AWS accounts, and turn high-risk findings into an improvement plan. Legal decisions on which laws apply stay with your advisers.
This guide summarises AWS's announcement of 5 October 2026, the Digital Sovereignty Lens whitepaper and lens definition, and public legal texts, as read on 12 October 2026. It is general information, not legal or regulatory advice. Lens content and laws change; confirm which obligations apply with your legal and compliance teams.
Common questions about the AWS Digital Sovereignty Lens
What is the AWS Digital Sovereignty Lens?
A Well-Architected lens, announced by AWS on 5 October 2026, with best practices for designing, building and operating workloads that must meet digital sovereignty requirements.
What does the lens cover?
Four pillars — operational excellence, security, reliability and performance efficiency — with 21 questions and 37 best practices. Existing Well-Architected guidance covers cost optimization and sustainability.
Is the Digital Sovereignty Lens built into the Well-Architected Tool?
It is published as a custom lens. You download the lens definition from AWS's Well-Architected custom lens repository on GitHub and import it into the AWS Well-Architected Tool.
Who should take part in a sovereignty review?
AWS recommends engineering, legal, compliance and security together, so obligations can be matched to workload evidence and remediation agreed.
Does the lens tell me which laws apply?
No. It helps you design and evidence controls. Your legal and compliance teams decide which data-protection, residency or sector rules apply in each country.
Is the lens only for the public sector?
No. AWS lists scenarios such as payment, securities-trading and healthcare platforms, expansion into new jurisdictions, operator-access restrictions and adopting generative AI.
Has Upvantix run Digital Sovereignty Lens reviews for customers?
The lens is new. Upvantix, an AWS Select Tier Services Partner, can help you prepare the evidence and AWS controls for a review; we don't claim past reviews or give legal opinions.