Azure PolicyV2 to Allow Only Regional and Data Zone Model Deployments
If you want to control where Azure AI model inference can run, blocking only Global deployments is a good start, but it is not the full governance story.
In many environments, the real requirement is stricter:
- allow deployments in a dedicated approved Azure region, or
- allow deployments in the EU Data Zone, and
- deny everything else.
That is a different policy design than simply searching for Global in the SKU name.
Microsoft’s deployment model makes an important distinction:
StandardandProvisionedManagedkeep processing in the selected Azure region.DataZoneStandard,DataZoneProvisionedManaged, andDataZoneBatchkeep processing inside the Microsoft-defined data zone.GlobalStandard,GlobalProvisionedManaged, andGlobalBatchcan process prompts and responses in any geography where the model is deployed.
If your platform standard says model deployments must stay either in a dedicated EU region or in the EU Data Zone, Azure Policy is the right place to enforce it.
The governance goal
The control in this post is designed for this exact rule:
- allow regional model deployments only in approved EU regions,
- allow EU Data Zone deployments,
- deny Global deployments,
- deny any other deployment type that falls outside those approved patterns.
This gives you a clean separation between two acceptable operating models:
StandardorProvisionedManagedwhen you need strict single-region control,DataZone*when EU-wide processing is acceptable.
Data Zone is not the same as single-region processing. It keeps inference inside the EU data zone, but Microsoft can still process requests in any EU member nation within that zone.
Why this matters
Microsoft documents that data at rest stays in the designated geography for all deployment types, but the location of inferencing depends on the deployment type.
That means these are not equivalent choices:
Global*: prompts and completions may be processed in any geography where the model is available.DataZone*: prompts and completions stay inside the defined data zone, such as the European Union.StandardandProvisionedManaged: prompts and completions stay in the deployment region.
For many organizations, EU Data Zone is sufficient because the data stays within the European Union. For stricter requirements, where one exact Azure region must be enforced, only regional deployments are acceptable.
The Azure Policy
The following custom policy uses an allowlist model.
It permits only these patterns:
Standardin an approved EU regionProvisionedManagedin an approved EU regionDataZoneStandardin an approved EU regionDataZoneProvisionedManagedin an approved EU regionDataZoneBatchin an approved EU region
Everything else is denied or audited depending on the assignment effect.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
{
"displayName": "Allow only approved regional and EU Data Zone model deployments",
"policyType": "Custom",
"mode": "All",
"description": "This policy allows Azure AI model deployments only in approved EU regions or EU Data Zone deployment types and blocks all other deployment types.",
"parameters": {
"effect": {
"type": "String",
"metadata": {
"displayName": "Effect",
"description": "Deny (block) or Audit (log only)"
},
"allowedValues": [
"Deny",
"Audit",
"Disabled"
],
"defaultValue": "Deny"
},
"allowedRegions": {
"type": "Array",
"metadata": {
"displayName": "Allowed Azure regions",
"description": "Azure regions where regional or EU Data Zone model deployments are allowed"
},
"defaultValue": [
"francecentral",
"germanywestcentral",
"italynorth",
"northeurope",
"polandcentral",
"spaincentral",
"swedencentral",
"westeurope"
]
},
"allowedRegionalSkus": {
"type": "Array",
"metadata": {
"displayName": "Allowed regional deployment SKUs",
"description": "Single-region deployment types that are allowed in the approved regions"
},
"defaultValue": [
"Standard",
"ProvisionedManaged"
]
},
"allowedDataZoneSkus": {
"type": "Array",
"metadata": {
"displayName": "Allowed Data Zone deployment SKUs",
"description": "Data Zone deployment types that are allowed when deployed in an approved EU region"
},
"defaultValue": [
"DataZoneStandard",
"DataZoneProvisionedManaged",
"DataZoneBatch"
]
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.CognitiveServices/accounts/deployments"
},
{
"not": {
"anyOf": [
{
"allOf": [
{
"field": "Microsoft.CognitiveServices/accounts/deployments/sku.name",
"in": "[parameters('allowedRegionalSkus')]"
},
{
"field": "location",
"in": "[parameters('allowedRegions')]"
}
]
},
{
"allOf": [
{
"field": "Microsoft.CognitiveServices/accounts/deployments/sku.name",
"in": "[parameters('allowedDataZoneSkus')]"
},
{
"field": "location",
"in": "[parameters('allowedRegions')]"
}
]
}
]
}
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
}
}
How the policy works
The logic is allowlist-first.
- It targets
Microsoft.CognitiveServices/accounts/deployments. - It defines which regional SKUs are acceptable.
- It defines which Data Zone SKUs are acceptable.
- It defines which Azure regions are acceptable for those deployments.
- If a deployment does not match one of the approved combinations, the policy effect is applied.
That means GlobalStandard, GlobalProvisionedManaged, and GlobalBatch are blocked automatically because they are outside the approved set.
This is stronger than a simple contains: Global check because it also blocks any future or unexpected deployment type that is not explicitly approved.
Important detail: Data Zone and regional are not interchangeable
This is the part many teams get wrong.
DataZoneStandard and DataZoneProvisionedManaged are valid choices for EU data residency requirements, but they are not single-region controls.
If the Foundry or Azure OpenAI resource is created in an EU member nation and the deployment type is Data Zone, Microsoft states that prompts and responses may be processed anywhere within the European Union data zone.
If your internal requirement says the model must run only in one specific Azure region, use Standard or ProvisionedManaged instead.
Use Data Zone when the control is geography. Use regional deployment when the control is one exact Azure region.
Why the policy uses approved regions
Even for Data Zone deployments, I recommend limiting the deployment resource location to an approved list of EU member nation regions.
That helps with three things:
- it keeps deployment placement aligned with your platform landing zones,
- it prevents accidental deployment into non-approved geographies,
- it gives you one reusable policy assignment pattern across subscriptions.
The allowedRegions parameter is where you can tune the control for your own environment.
Caveats and edge cases
This policy is useful, but it does not solve every residency or compliance requirement by itself.
- Data at rest and location of processing are different controls.
- Data Zone keeps inferencing inside the EU data zone, not inside one single Azure region.
- Model availability differs by region and deployment type, so a compliant deployment type might still be unavailable for the model you want.
- Some advanced scenarios, such as fine-tuning, batch workflows, stored state, or other stateful features, can introduce additional storage or processing considerations that should be reviewed separately.
DeveloperTieris intentionally not allowed by this policy. If you need fine-tuned model evaluation in non-production, add a scoped exception or extend the allowlist deliberately.
This policy governs deployment type and deployment location. It does not replace separate controls for networking, private endpoints, RBAC, encryption, or feature-specific data handling.
Recommended rollout
Roll this out in two phases.
Phase 1: Audit
Start with Audit.
That gives you a clean inventory of:
- subscriptions using Global deployment types,
- teams deploying into non-approved regions,
- workloads that need EU Data Zone instead of Global,
- workloads that need one fixed region instead of Data Zone.
Phase 2: Deny
After you understand the impact, switch the policy assignment to Deny.
That makes the approved deployment pattern the default path instead of relying on documentation or manual review.
What developers should use instead
If you enforce this policy, developers need a clear replacement path.
Use this rule of thumb:
- Need processing to stay in one exact Azure region: use
StandardorProvisionedManagedin an approved EU region. - Need processing to stay within the European Union but not necessarily one exact region: use
DataZoneStandard,DataZoneProvisionedManaged, orDataZoneBatch. - Need the highest global flexibility with no residency restriction: that is exactly the scenario this policy is designed to prevent in controlled environments.
Before rollout, verify that the required model is available in the deployment type and region you approve. That is often the real operational constraint.
Final thoughts
This pattern is stronger than a simple Global blocklist because it encodes the approved operating model directly:
- approved EU regional deployments,
- approved EU Data Zone deployments,
- no Global deployments.
That is usually what security and platform teams actually want. The compliant path becomes explicit, enforceable, and repeatable.