Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure supports a spectrum of deployment options, including public cloud regions, hybrid environments, and sovereign or national cloud environments. This flexibility helps you design for reliability while meeting regulatory and jurisdictional requirements.
This article explains how sovereignty considerations influence reliability design decisions and what to plan for at key architecture decision points.
What sovereignty means for a reliable workload
Sovereignty means you retain control over your data and ensure that data remains subject to your jurisdiction's laws. In practice, sovereignty affects reliability design in two key ways:
- Access control: Only authorized parties can access or move data. Controls include encryption, customer-managed keys, role-based access control, and operational controls.
- Geographic control: Data remains within specified geographic boundaries so that it's governed by local laws.
Sovereignty is outcome-based. It doesn't require isolation from the global cloud. Many compliance requirements can be met in public cloud environments when you apply the right controls, including data residency controls, encryption, auditability, and lawful access protections.
Azure capabilities that support sovereignty
Azure provides several capabilities that help you meet sovereignty requirements:
- Data controls: Azure regions are grouped into geographies that define data residency boundaries. Azure also supports encryption and customer-managed keys, including centralized key management through Azure Key Vault.
- Operational controls: Azure Policy can constrain resource placement to specific regions, role-based access control can limit permissions, and Customer Lockbox can govern Microsoft support access. You can also use immutable logging and governance architectures to enforce compliance guardrails at scale.
- Deployment and infrastructure options: Azure supports multiple deployment and isolation models. Azure Government and Azure in China are physically isolated clouds that operate independently from global Azure. Microsoft Sovereign Cloud supports logical isolation patterns within Azure public cloud. Hybrid options such as Azure Local support customer-controlled and disconnected operation scenarios.
Where reliability and sovereignty design decisions intersect
When you design the reliability of your solution, you also need to consider and plan for any sovereignty concerns. This section highlights some decisions that you commonly need to make when considering reliability and sovereignty.
Region and availability zone selection
Where you place redundant infrastructure determines both reliability and compliance posture. Multi-region designs often improve reliability, but sovereignty constraints might limit region selection to approved geographic or geopolitical boundaries.
If you design a disaster recovery-based solution with multiple regions, and your workload must remain within a specific jurisdiction, choose a disaster recovery region in that same boundary. If no compliant secondary region is available, use single-region reliability with backup-based recovery, and document the related recovery tradeoffs.
Tip
Availability zones provide an additional reliability layer inside a region without crossing geographic boundaries. Use multizone architecture where supported.
Backup, replication, and disaster recovery locations
Backup and replication destinations should follow the same regulatory boundaries as the workload they protect. Some services support replication to regions you choose, while others use Azure-defined region pairs.
When you store backups or replicas outside your primary boundary, ensure data is encrypted and key placement is planned carefully. If encryption keys are only stored in the primary region, they might be unavailable during a region outage.
When you use customer-managed keys with replication to another Azure region that isn't the paired region, align key placement with data placement. Azure Key Vault Managed HSM supports distributing keys across regions to help keep key availability aligned with protected data.
Operational access and auditability
Reliability operations should remain controlled and auditable. Azure safe deployment practices roll out changes incrementally and isolate failure domains to reduce multiregion impact risk.
For regulated workloads, Customer Lockbox helps ensure Microsoft support engineers can't access customer data without explicit approval. Use Azure Monitor and Azure Activity Log to retain failover and recovery records for audit and compliance reporting.