Keep Azure in the right regions: the allowed-locations policy

Someone deploys a VM to a region on the other side of the world. Now you have data where it shouldn't be, latency you didn't plan for, and an awkward question at your next audit. Restricting which regions people can use is one of the first governance guardrails the Cloud Adoption Framework recommends, and Azure ships a built-in policy for it.

Assign the built-in "Allowed locations" policy with the regions you permit, in Terraform:

data "azurerm_subscription" "current" {}

resource "azurerm_subscription_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations"
  subscription_id      = data.azurerm_subscription.current.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["uksouth", "ukwest"] }
  })
}

terraform apply, and from now on any attempt to create a resource outside uksouth or ukwest is refused. No custom policy to write, no ongoing effort. That long id is the built-in "Allowed locations" definition. If you'd rather confirm it in your own tenant, look it up by name:

az policy definition list --query "[?displayName=='Allowed locations'].name" -o tsv

That's a real compliance control in a few lines. It's the CAF instinct in miniature: decide the boundary once, and let the platform enforce it for everyone.

At scale this sits inside a policy initiative applied across the management-group hierarchy, with a matching rule for resource groups. One subscription-level assignment is plenty to start.

Next: finding every public-facing storage account in thirty seconds.