How do I restrict which regions resources can be deployed to in Azure?

Assign the built-in Azure Policy named 'Allowed locations'. It takes a parameter listing the approved regions and denies creation of any resource in a region outside that list. Assign it at a management group or subscription scope so it covers everything beneath, set the effect to Audit first to see impact, then switch to Deny to enforce. There is also a separate 'Allowed locations for resource groups' policy for the resource-group location itself.

Why does the allowed-locations policy flag global resources?

Some Azure resources have a location of 'global' rather than a specific region — things like Azure DNS, Front Door, and some management resources. A naive region restriction would block them. The built-in Allowed locations policy already excludes resource types whose location is global, and you can add 'global' to your allowed list or exempt specific resource types if a deployment needs it. Test in audit mode to catch any global resources before enforcing.

Should I restrict regions at the management group or subscription level?

Assign it as high as the rule is universally true. If every workload in the organization must stay in, say, two European regions, assign at the top management group so all current and future subscriptions inherit it. If only some subscriptions have the constraint, assign at those subscriptions or an intermediate management group. Assigning high means new subscriptions are covered automatically rather than being forgotten.

What are the benefits of restricting Azure regions?

Three main ones. Data residency and compliance — keep data in regions your regulations allow. Cost control and consistency — prevent someone accidentally deploying in an expensive or unexpected region and fragmenting your footprint. Reduced blast radius and simpler operations — fewer regions means fewer places to secure, monitor, and reason about. It also stops shadow deployments drifting into regions nobody is watching.

Field notes · Governance

Allowed-locations policy

Restricting Azure regions with an allowed-locations policy

By Captain O6 min read

Nothing stops a developer spinning up a database in a region your compliance team has never heard of — until you add one policy. It's the simplest guardrail in Azure and one of the highest-value.

New to cloud? CAMPUX is a free, build-first course. Start here →

Restrict Azure deployment regions by assigning the built-in "Allowed locations" policy: pass it the list of approved regions and it denies any resource created outside them. Assign it at a management group or subscription so everything beneath inherits it, run it in Audit first to catch surprises (including 'global' resources), then switch to Deny. You don't write anything — this is a built-in; the skill is scoping and rolling it out safely.

Region sprawl is a quiet problem: a resource here, a test there, and suddenly your data lives in five regions, two of which nobody is monitoring and one of which your regulations don't allow. An allowed-locations policy makes "we only run in these regions" a rule the platform enforces instead of a wiki page everyone ignores.

Why restrict regions

Data residency & compliance — keep data in the regions your regulations permit; this is often a hard legal requirement, not a preference.
Cost & consistency — stop an accidental deployment in an expensive or far-away region, and keep the footprint you actually reason about.
Blast radius & operations — fewer regions means fewer places to secure, monitor, and pay for. Every extra region is extra attack surface and extra dashboards.

Assigning the built-in policy

Check the built-ins first (there's no reason to write this one). Assign "Allowed locations" with your region list; there's a companion "Allowed locations for resource groups" for the RG's own location. From the CLI:

# the built-in "Allowed locations" definition has a well-known id
az policy assignment create \
  --name "allowed-locations" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --scope "/subscriptions/<sub>" \
  --params '{ "listOfAllowedLocations": { "value": ["westeurope", "northeurope"] } }'

Assign it as high as the rule is universally true. If the whole org must stay in two European regions, assign at the top management group so every current and future subscription inherits it — new subscriptions are the ones people forget.

The 'global' resources gotcha

Some resources report a location of global rather than a region — Azure DNS, Front Door, some management resources. A blunt region filter would block them, which is why the built-in already excludes global resource types. If a deployment still trips on one, add global to your allowed list or exempt the specific resource type. This is exactly the kind of surprise audit mode surfaces before it can break a real deployment.

Audit first, always

Assign with the effect set to Audit, read the compliance results across your scope, fix or exempt anything unexpected (global resources, a legitimately different region), then change the effect to Deny. Same audit-then-enforce discipline as every other guardrail — see writing a custom policy for the mechanics.

A region policy turns "please deploy in Europe" from a hopeful request into a fact of the platform.

Questions people also ask

How do I restrict which regions resources deploy to?

Assign the built-in "Allowed locations" policy with a parameter listing approved regions; it denies resources created elsewhere. Assign at a management group or subscription, audit first, then deny. Use "Allowed locations for resource groups" for the RG location itself.

Why does it flag global resources?

Some resources have a location of global (DNS, Front Door). The built-in already excludes global resource types; add global to your list or exempt the type if a deployment needs it. Audit mode catches these first.

Management group or subscription level?

Assign as high as the rule is universally true. Org-wide constraint → top management group, so all current and future subscriptions inherit it. Subset → those subscriptions or an intermediate management group.

What are the benefits?

Data residency/compliance, cost and footprint consistency, and reduced blast radius — fewer regions to secure, monitor, and pay for — plus no shadow deployments drifting into unwatched regions.