View a markdown version of this page

Design principles - Digital Sovereignty Lens

Design principles

The Digital Sovereignty Lens adds seven design principles that address sovereignty as a cross-cutting concern. They extend, rather than repeat, the design principles in the AWS Well-Architected Framework for operational excellence, security, reliability, and performance efficiency. Each principle maps to one or more of the five design concerns, and where it builds on an existing Well-Architected principle, it links to that principle instead of restating it.

  • Apply standardized, enforceable controls (locality, access control, transparency and auditability). Turn regulatory obligations into automated controls, and keep each control traceable to the requirement it satisfies. Automated controls stay consistent across teams and jurisdictions and produce evidence on demand. This means you can demonstrate compliance instead of asserting it. This builds on the security principle automate security best practices and the operational excellence principle safely automate where possible.

  • Apply controls in proportion to data sensitivity and jurisdiction (locality, access control). Classify data first, then match the strength of each control to the sensitivity of the data and to the jurisdictions that govern it. Proportionate controls protect sensitive data while preserving business agility. Extend your security baseline with sovereignty controls for privacy, residency, and operator access, which go beyond foundational security measures such as encryption and least privilege. This builds on the security principles protect data in transit and at rest and keep people away from data.

  • Design for continuous compliance (transparency and auditability). Verify compliance continuously and remediate automatically, so a workload continues to meet its obligations as configurations, dependencies, and regulations change. Continuous verification keeps your workloads audit-ready and surfaces drift early, when it is least expensive to fix. Evidence you gather continuously is more credible than evidence you reconstruct during an audit. This builds on the Well-Architected principles implement observability and maintain traceability.

  • Design for interoperability and portability (portability and interoperability). The more portable and interoperable a workload is, the lower the continuity risk if it needs to operate across or exit to another environment. Improve portability and interoperability by abstracting Region- and environment-specific dependencies, aligning with open standards, and adopting open data formats. Test the same suite across each target environment to confirm the workload runs consistently.

  • Design for survivability (continuity). Design recovery within your sovereignty boundaries, so a successful failover preserves compliance and function. After a failover, confirm that data stays in approved jurisdictions, operator access restrictions hold, and audit trails continue. Plan for regulatory, trade, and supply-chain disruptions in addition to technical failure, so you can relocate a workload when conditions require it. This builds on the reliability principles test recovery procedures and automatically recover from failure and the operational excellence principle anticipate failure.

  • Evaluate sovereign architecture decisions based on evidence, not assumptions (all design concerns). Baseline your sovereignty requirements across the five design concerns. Understand what your provider delivers and document what you must build on top. Then select deployment models, services, and dependencies that meet those requirements, not on opinions or perceived risk. Sovereignty decisions made without data tend to result in over-engineered (restricting unnecessarily) or under-engineered (discovering gaps in production) workloads. This builds on the general design principle drive architectures using data.

  • Validate software dependencies for sovereignty beyond security (portability and interoperability, continuity). Standard vulnerability scanning uncovers security risks only. Based on your sovereignty risk model, assess software components for export control exposure, licensing compatibility, supply chain provenance, and jurisdiction-specific certification requirements.

As with the design concerns, which principles apply and to what degree depends on your jurisdiction and organizational goals. Not all seven are relevant in every context.