Data Residency and Sovereignty Requirements

Data residency refers to the physical or geographic location where data is stored. Data sovereignty extends this concept to the legal and regulatory requirements that data must remain within a specific jurisdiction. For example, the EU's General Data Protection Regulation (GDPR) requires that personal data of EU citizens be stored in the EU or in countries with equivalent protection. Similarly, countries like Brazil, India, and China have laws that mandate local storage of certain types of data.

In Azure, data residency is enforced through the concept of regions. Each Azure region is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network. When you deploy a resource like a storage account or a virtual machine, you choose a region. Azure guarantees that for most services, data at rest remains within that region unless you explicitly configure cross-region replication.

Azure uses several mechanisms to enforce data residency:

Azure's paired regions are designed to be at least 300 miles apart within the same geography. For example, East US is paired with West US. This ensures that even during a disaster, data remains within the United States.

Azure Policy is a service that allows you to create, assign, and manage policies that enforce rules for your resources. To enforce data sovereignty, you can use built-in policies like:

You can also create custom policies to enforce data residency for specific services. For example, you can require that Azure SQL databases be deployed only in regions within the European Union.

Azure Blueprints enable you to define a repeatable set of Azure resources that implement and adhere to standards, patterns, and requirements. A blueprint can include policies, role assignments, and resource templates. For data sovereignty, you can create a blueprint that enforces allowed locations, ensures data encryption at rest, and restricts cross-region replication.

Azure Key Vault allows you to store encryption keys in a specific region. With customer-managed keys (CMK), you control the keys used to encrypt your data. If you use a key stored in a Key Vault in a specific region, Azure will not be able to move your data to another region without your key, providing an additional layer of sovereignty enforcement.

Azure divides the world into geographies, each containing one or more regions. A geography is a discrete market, typically containing two or more regions, that preserves data residency and compliance boundaries. For example: - United States geography: East US, East US 2, Central US, etc. - Europe geography: North Europe, West Europe, France Central, etc. - Asia Pacific geography: Southeast Asia, East Asia, etc.

Data residency requirements often mandate that data stay within a specific geography. Azure's geo-redundant storage ensures that data is replicated within the same geography.

For customers with the highest compliance needs, Azure offers sovereign clouds: - Azure Government: For US government agencies and their partners. Data is stored in US datacenters and accessed only by US persons. - Azure China (21Vianet): Operated by 21Vianet, a Chinese company. Data remains in China and is subject to Chinese law. - Azure Germany: Was available but is being retired; now use Azure regions in Germany (e.g., Germany West Central) which are part of the European geography.

When you use Azure services, data may be transferred between regions for performance or redundancy. However, Azure provides options to restrict data movement: - Disable geo-redundant storage: Choose LRS or ZRS to keep data within a single region. - Azure Traffic Manager: You can configure routing methods to keep traffic within a region. - Azure Front Door: Can be configured to route requests to the nearest region, but you can restrict backend origins to specific regions.

To enforce data residency, you can use Azure Policy to:

Example policy definition to restrict locations:

{
  "policyRule": {
    "if": {
      "not": {
        "field": "location",
        "in": ["eastus", "westus"]
      }
    },
    "then": {
      "effect": "deny"
    }
  }
}

Azure Resource Graph allows you to query resources across subscriptions. You can use it to audit data residency compliance. For example, you can query all storage accounts and their replication settings to ensure they are not using geo-redundant storage if that violates sovereignty.

A blueprint can include:

Azure provides a portfolio of compliance offerings (e.g., ISO 27001, SOC 2, FedRAMP). These certifications attest that Azure meets data residency and sovereignty requirements. For the exam, know that Azure maintains compliance with over 90 offerings.

The AZ-305 exam often presents scenarios where a company must comply with data residency laws. For example:

You must choose the appropriate Azure services and configurations to meet these requirements.

A large European bank must store all customer financial data within the European Union. They deploy Azure resources in the 'West Europe' region. They use Azure Policy to deny any resource creation outside of EU regions (West Europe, North Europe, France Central, etc.). They configure all storage accounts with LRS or ZRS to avoid geo-replication. For Azure SQL Database, they disable geo-replication. They use Azure Blueprints to enforce these settings across multiple subscriptions. They also use customer-managed keys stored in Azure Key Vault in West Europe. A common issue is that developers accidentally create resources in 'East US' for testing; Azure Policy denies the deployment, and the compliance dashboard alerts the governance team.

A US federal agency must comply with FedRAMP High requirements. They use Azure Government, which is a physically isolated instance of Azure in US datacenters. All data stays within the US. They restrict resource creation to Azure Government regions (US Gov Virginia, US Gov Texas, etc.). They use Azure Policy to enforce this. They also require that all encryption keys be stored in Azure Government Key Vault. Performance is a consideration because Azure Government has fewer regions; they use Availability Zones within the same region for high availability. A misconfiguration that could occur is using Azure commercial instead of Azure Government; the agency uses Azure Policy to block connections to commercial Azure.

A multinational company operating in Brazil must keep Brazilian customer data within Brazil. They deploy resources in the 'Brazil South' region. They use Azure Policy to restrict locations to Brazil South only. They configure all storage with LRS. They also use Azure Traffic Manager to route user traffic to the Brazil South endpoint. They must ensure that disaster recovery does not replicate data outside Brazil; they use Azure Site Recovery with a secondary region in Brazil South (though Azure only has one region in Brazil, so they use a different availability zone or rely on backup to a local datacenter). A common mistake is assuming that Brazil South is paired with a region outside Brazil; in reality, Brazil South is paired with South Central US, but GRS is not allowed due to sovereignty. They must use LRS or ZRS only.