Restricting Azure Resource Deployment by Region

This week, I’ve been studying some topics ahead of my 70-533 exam and one of the topics that I covered which I though would make a really relevant and hopefully not too long of a post would be the subject of restricting Azure resource deployment to specific regions.

Many organisations have considerations around data privacy and sovereignty. For me and many folks in the UK, right now that means your data is probably living in an Azure region in Europe. Either Dublin or Amsterdam. With the UK datacentres being brought online fairly recently and the available features growing month by month, it makes using those regions more appealing. With the prospect of Brexit and how your data soverignty may be effected by that shake up could potentially make those UK datacentres even more appealing in the months and years to come.

With an out of the box Azure subscription, we have the power to deploy resources to any region we like be it UK, US, South America or Asia but with these privacy and data protection concerns wouldn’t it be great if you could limit this so that even the most well trained administrators and users cannot accidently place your data on the wrong side of a pond?

Read on below the fold and I’ll explain how to create an Azure Resource Policy and how to apply that to your evironments.

The first step here is obviously to create our policy. This is going to start life as a short JSON script which we can deploy and apply via either the REST API, Azure CLI or PowerShell but for here, I will focus on PowerShell. Sadly, we can’t deploy this as part of a Resource Manager deployment otherwise I would have posted the whole thing as a Deploy to Azure button affair.

Create an Azure Resource Policy Definition

First, we need to create our policy definition. I’ve done that part for you by adding two definition templates (for now) to a GitHub repository at There are two templates of relevance here, permittedLocationsUK.json and permittedLocationsEU.json. The UK file permits only the UK West and UK South datacentre regions whilst the EU file permits only the North Europe and West Europe regions.

HINT: You can use Get-AzureRmLocation | Select Location, DisplayName to return all the locations and their internal and display names.

Once you have the files, you need to login to PowerShell and create the policy definitions in your tenant. The following PowerShell code will add the policy definitions to your tenant. You can either run one line for a specific location, or you could run both so you have them both installed.

# Creates the Policy Definition for the Azure UK Datacentre Regions
New-AzureRmPolicyDefinition -Name permittedLocationsUK -Description "This policy configures restrictions to only allow resource deployment in the Azure UK Datacentre Regions." -Policy "C:\permittedLocationsUK.json"

# Creates the Policy Definition for the Azure EU Datacentre Regions
New-AzureRmPolicyDefinition -Name permittedLocationsEU -Description "This policy configures restrictions to only allow resource deployment in the Azure EU Datacentre Regions." -Policy "C:\permittedLocationsEU.json"

Assigning an Azure Resource Policy

In the steps above, we created a policy definition which we now want to apply.  At this point, we have a choice we can make. We can either apply these policies to a specific Resource Group or to an entire Subscription. I personally like the idea of applying it once at the subscription level however your use case may vary in that you need to restrict only a sub-set of data in a particular Resource Group.

# Apply the UK Policy Definition to an entire Subscription
$policy = Get-AzureRmPolicyDefinition -Name permittedLocationsEU
$sub = Get-AzureRmSubscription -Name "Your Subscription Name"
New-AzureRmPolicyAssignment -Name "Permitted Locations UK Only" -PolicyDefinition $policy -Scope "/subscriptions/$sub"

# Apply the EU Policy Definition to a specific Resource Group
$policy = Get-AzureRmPolicyDefinition -Name permittedLocationsEU
$rg = Get-AzureRmResourceGroup -Name your-resource-group-name
New-AzureRmPolicyAssignment -Name "Permitted Locations EU Only" -PolicyDefinition $policy -Scope $rg.ResourceId

Once you’ve entered one of these commands, you’re set. Any new resources deployed into the environment will be subject to those restrictions and will generate a failure during resource deployment if they breach the policy.

Softening the Policy Behaviour

In some cases, you may want to not deny people the ability to creating out of territory resources but to create administrative warnings or alerts that it has occurred so you can go and speak to those people about there requirement for the out of territory usage.

We can do this by modifying the Resource Policy Definition before uploading it. If you take a look at the JSON, you will see the “effect” element set to a value of “deny”. You can change this from deny to “audit”. This will allow the deployments to continue but will instead, generate an alert for administrators to see in the Azure audit logs.

Viewing Assigned Policies and Removing Policies

If you have picked up an existing subscription from another admin and need to check out what policies are currently in effect, you can simply use Get-AzureRmPolicyAssignment to return a list of all assigned policies and the scope to which it is assigned. If you have an existing policy which you need to remove then you can do this too. You need to define the scope for the removal so the syntax will be very similar to the assignment of the policy in the first instance.

There are some built-in policies in Azure which don’t have friendly names but GUIDs as their names. You will want to watch out for these if they have been applied anywhere as you will need to check more carefully what they are doing unless you can remember the GUIDs from memory that is.

$rg = Get-AzureRmResourceGroup -Name your-resource-group-name
Remove-AzureRmPolicyAssignment -Name "Permitted Locations EU Only" -Scope $rg.ResourceId


Richard works as a Cloud Consultant for Fordway Solution where his primary focus is to help customers understand, adopt and develop with Microsoft Azure, Office 365 and System Center. Richard Green is an IT Pro with over 15 years' of experience in all things Microsoft including System Center and Office 365. He has previously worked as a System Center consultant and as an internal solutions architect across many verticals. Outside of work, he loves motorbikes and is part of the orange army, marshaling for NGRRC, British Superbikes and MotoGP. He is also an Assistant Cub Scout Leader.