Azure Region Selection for Compliance

Azure regions are geographical areas containing one or more datacenters that are connected through a dedicated low-latency network. When you deploy a resource, you choose a region — for example, East US, West Europe, or Southeast Asia. For compliance, the region determines where your data is stored at rest and where it is processed. Many organizations have legal obligations to keep data within specific geographical boundaries. For instance, the European Union's General Data Protection Regulation (GDPR) requires that personal data of EU citizens remain within the European Economic Area (EEA) unless explicit safeguards are in place. Similarly, financial institutions in the United States may need to keep data within US borders per regulations like the Gramm-Leach-Bliley Act. Azure provides a wide selection of regions worldwide, including specialized sovereign regions (e.g., Azure Government in the US, Azure China 21Vianet) that offer additional compliance assurances.

Azure enforces data residency through contractual commitments and technical controls. When you create a resource in a specific region, Azure's default behavior is to keep that resource's data at rest within that region. For example, an Azure SQL Database deployed in West Europe will have its data files stored on disks in West Europe datacenters. However, some services, like Azure Backup or Azure Site Recovery, can replicate data to another region if you configure geo-redundancy. For compliance, you must ensure that such replication does not violate data residency rules. Azure's Data Processing Addendum (DPA) contractually binds Microsoft to respect your region choice. Additionally, Azure Policy allows you to enforce region restrictions at the subscription or management group level, preventing users from deploying resources in non-compliant regions.

Azure organizes regions into geographies. A geography is a discrete market, typically containing two or more regions, that preserves data residency and compliance boundaries. For example, the Europe geography includes West Europe (Netherlands) and North Europe (Ireland). Data can be replicated between regions within the same geography for disaster recovery without leaving the geography. This is important for GDPR compliance: data stored in West Europe can be replicated to North Europe and still remain within the EEA. Azure also offers sovereign regions: Azure Government (US) for US government agencies and their partners, Azure China 21Vianet operated by 21Vianet in China, and Azure Germany (deprecated, now using standard regions). These sovereign regions have additional compliance certifications and are physically and logically isolated from the public Azure cloud.

Region selection can affect pricing. Not all services are available in all regions, and pricing may vary. For compliance, you may be forced to use a region with higher costs. For example, a financial services company in Singapore might need to store data within Singapore, so they must use the Southeast Asia region even if East US is cheaper. Azure provides a pricing calculator to estimate costs per region. There is no additional charge for choosing a region — you pay for the resources you use, but the same resource type may have different rates in different regions due to local infrastructure costs.

In on-premises datacenters, you own the physical infrastructure, so you have full control over data location — but at the cost of capital expenditure and maintenance. With Azure, you trade control for convenience. You must trust that Azure honors its contractual data residency commitments. The on-premises equivalent would be building your own datacenter in a specific country — expensive and slow. Azure regions give you the ability to deploy globally in minutes while maintaining compliance, but you must carefully read the DPA and understand which services support data residency.

In the Azure portal, when you create a resource, the first step is selecting a region. The portal shows a list of regions, and you can filter by geography. You can also use Azure Policy to enforce allowed regions. With the Azure CLI, you can list regions:

az account list-locations --query "[].{Name:name, DisplayName:displayName}" --output table

To set a policy restricting regions, you would use Azure Policy definitions. For example, the built-in policy "Allowed locations" allows you to specify which regions are permitted. You can assign it at a subscription scope:

az policy assignment create --name "restrict-regions" --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" --params '{"listOfAllowedLocations":{"value":["westeurope","northeurope"]}}'

This ensures no resources can be created outside the allowed regions. For compliance, you can also use Azure Blueprints to deploy a set of policies and role assignments that enforce region restrictions and compliance standards.

Consider a healthcare provider in Australia that must comply with the Privacy Act 1988, which requires health data to be stored in Australia. They would deploy all resources in the Australia East or Australia Southeast regions. They would use Azure Policy to block deployments in other regions. They would also configure Azure SQL Database to use locally redundant storage (LRS) rather than geo-redundant storage (GRS) to prevent data from replicating outside Australia. Another scenario: a global e-commerce company handling EU customer data must ensure data stays within the EU. They deploy in West Europe or North Europe and use Azure Policy to enforce that. They may also use Azure Information Protection to label data and prevent accidental export.

Step 1: Identify Compliance Requirements First, determine the regulatory frameworks applicable to your organization. Common ones include GDPR, HIPAA, FedRAMP, and PCI DSS. Each has specific data residency and processing requirements. For example, GDPR requires that personal data of EU citizens be stored within the EEA unless adequacy decisions exist. Identify the countries or regions where your data must reside.

Step 2: Map Requirements to Azure Geographies Azure's geography documentation lists which regions belong to which geography and what compliance certifications each geography offers. For instance, the US Government geography includes US Gov Virginia and US Gov Texas, which have FedRAMP High and DoD IL5 certifications. Use the Azure compliance documentation to verify that the geography meets your needs.

Step 3: Select a Region Within the Geography Choose a region that offers the services you need. Not all services are available in every region. Use the Azure Products by Region page to check availability. For example, if you need Azure Kubernetes Service (AKS) in Canada, you must use Canada Central or Canada East. Also consider latency to your users. For compliance, you may need to choose a region that is physically within the required jurisdiction.

Step 4: Enforce Region Restrictions with Azure Policy Create a policy assignment using the built-in "Allowed locations" policy to restrict resource creation to the approved regions. You can also create custom policies to deny deployment if a resource does not meet region criteria. This prevents accidental deployment in non-compliant regions.

Step 5: Configure Data Replication Settings For services that offer geo-replication, such as Azure Storage, SQL Database, and Cosmos DB, ensure that replication is configured to stay within the same geography. For example, for Azure Storage, choose Locally Redundant Storage (LRS) or Zone-Redundant Storage (ZRS) instead of Geo-Redundant Storage (GRS) if cross-geography replication is not allowed. For SQL Database, configure active geo-replication only to regions within the same geography.

Step 6: Monitor Compliance with Azure Policy and Azure Blueprints Use Azure Policy's compliance dashboard to audit existing resources for region compliance. Azure Blueprints can package policies, role assignments, and resource groups to enforce compliance at scale. Regularly review the compliance state and remediate any non-compliant resources.

A hospital chain in Germany needs to migrate patient records to Azure. They must comply with GDPR and the German Bundesdatenschutzgesetz (BDSG), which require data to stay within Germany or the EU. The team selects the West Europe region (Netherlands) and North Europe (Ireland) as allowed regions. They create an Azure Policy to deny any resource creation outside these two regions. They configure Azure SQL Database with locally redundant backup and disable geo-replication. They also use Azure Blueprints to deploy a standardized environment with built-in compliance policies. Cost: They compare pricing between West Europe and North Europe and choose West Europe for lower latency to their German users. What could go wrong? If a developer accidentally creates a storage account in East US, the policy will deny it. But if they had not enforced policy, data could have been stored in the US, violating GDPR and leading to fines up to 4% of annual global turnover. Additionally, if they had enabled geo-redundant storage without realizing it replicates to a paired region in a different geography (e.g., West Europe pairs with East US? Actually, West Europe pairs with North Europe, both in EU — but some pairings cross geographies, e.g., East US pairs with West US — but that's within US. However, for sovereign regions, pairings may cross. Always check the paired region list. In this scenario, West Europe's paired region is North Europe (both in EU), so GRS would be safe. But if they used a region like France Central, its paired region is France South (both in France), so still safe. The key is to know the pairing.

The AZ-900 exam tests your understanding of how Azure regions support compliance. Specifically, you need to know:

- The difference between a region and a geography. - The purpose of sovereign regions (Azure Government, Azure China). - How data residency is guaranteed. - How Azure Policy can enforce region restrictions. Common wrong answers: 1. "All Azure regions are compliant with all regulations." Reality: Compliance certifications are region-specific. For example, Azure Government regions have FedRAMP High, but commercial regions may not. 2. "You can store data in any region and it will never leave that region." Reality: Some services replicate data by default to a paired region for disaster recovery. You must disable or configure replication to stay within geography. 3. "Azure guarantees data residency for all services." Reality: Data residency commitments vary by service. Some services, like Azure Traffic Manager, do not store customer data at rest. Others, like Azure SQL Database, store data in the selected region but may process data in other regions for support. Memory trick: Think of a geography as a fenced yard with multiple sheds (regions). Your data can move between sheds within the same yard but cannot leave the yard unless you build a gate (geo-replication). Azure Policy is the lock on the gate that prevents data from going to the wrong yard. Edge cases: The exam may ask about the paired region concept. For example, if you choose West US, its paired region is East US (both in US). But if you choose Brazil South, its paired region is South Central US (which is in the US). That means data replicated via GRS would leave Brazil, which could violate Brazil's data protection law (LGPD). So you must choose LRS or ZRS instead.

Scenario 1: European Bank Complying with GDPR A large bank headquartered in Frankfurt needs to migrate its customer data to Azure. GDPR mandates that personal data of EU citizens must remain within the EEA. The bank's compliance team identifies that the Europe geography (West Europe and North Europe) meets this requirement. They select West Europe for its proximity to Frankfurt. They create an Azure Policy at the management group level to allow only West Europe and North Europe. For Azure SQL Database, they configure backups with locally redundant storage to prevent any data from leaving the EU. They also use Azure Blueprints to deploy a standardized environment with built-in policies and role assignments. What could go wrong? If a developer enables geo-redundant storage, data would replicate to North Europe (still in EU) — that's fine. But if the bank later expands to use Azure Front Door, they must ensure that edge locations do not cache data outside the EU. They configure Front Door to only use origins in West Europe and disable caching at edge locations outside the EEA. Cost: West Europe is slightly more expensive than North Europe, but the latency benefit justifies it. The bank saves money by using reserved instances for their VMs.

Scenario 2: US Healthcare Provider Under HIPAA A hospital network in Texas must comply with HIPAA, which requires that protected health information (PHI) be stored within the United States. They choose the US geography, specifically South Central US (Texas) for low latency. They use Azure Policy to restrict all resources to US regions (East US, West US, South Central US, etc.). For Azure Storage, they use geo-redundant storage (GRS) to replicate to the paired region (North Central US), which is still within the US. They also enable encryption at rest and in transit. They sign a Business Associate Agreement (BAA) with Microsoft, which is available for all US commercial regions. What could go wrong? If they accidentally deploy in a region outside the US, such as Canada Central, they could face HIPAA violations. Azure Policy prevents this. However, if they use a third-party service that stores data in another region, that could be a problem. They must vet all services. Cost: They use Azure Hybrid Benefit to reduce Windows Server costs.

Scenario 3: Chinese Subsidiary Using Azure China 21Vianet A multinational corporation has a subsidiary in China. Chinese law requires that data of Chinese citizens be stored within China and that the cloud provider be operated by a Chinese company. They choose Azure China 21Vianet, which is a physically isolated instance of Azure operated by 21Vianet. They deploy all resources in China North 2 (Beijing) or China East 2 (Shanghai). They cannot use Azure Policy in the same way because Azure China has its own policy service. They must ensure that no data is replicated to commercial Azure regions. They configure all storage to use locally redundant storage. What could go wrong? If they try to use a global Azure service like Azure DevOps, it may not be available in Azure China. They must use local alternatives. Cost: Pricing in Azure China is different and generally higher due to operational costs.