Why Project Managers Should Pick an Azure Data Zone Early

Week one: a developer accepts the default in a Microsoft Foundry dropdown, Global Standard, because the docs say to start there. Month six: the customer's security team asks where prompts are processed, and the honest answer is "any Azure region."

That is the case for picking your Azure data zone early. The deployment type is a one-field decision on day one and a cross-team rework on day 180. This is for whoever owns the schedule and the sign-offs.

What the deployment type controls

When you deploy a model in Foundry, the deployment type sets where your data is processed, how you pay, and how the deployment performs, per the Foundry deployment types documentation. Three types decide residency:

| Type | SKU code | Where prompts and responses are processed | | --- | --- | --- | | Global Standard | GlobalStandard | Any Azure region | | Data Zone Standard | DataZoneStandard | Only inside the US, EU or APAC data zone you chose | | Standard | Standard | Inside the Azure geography you specified |

One trap catches smart people. Data stored at rest stays in the designated Azure geography for every type, so "we created the resource in Sweden" sounds like an answer. It isn't: with a Global type, inference can still run in any Azure region.

What a late switch to a different Azure data zone costs

The docs describe the type as a choice you make at deployment creation, so plan any change as a new deployment, not a setting flip. It brings:

• New quota. For models on subscription-level quota management, Global Standard deployments of a model version share one pool across all regions in a subscription, while Data Zone Standard deployments share one pool per data zone. Approval for one doesn't cover the other, per the Foundry quotas and limits page.
• Model availability. Not every model supports every type, and new types roll out Global first, then Data Zone, then geography, with no guaranteed date for the last.
• Repeated testing and approvals. Every eval run and sign-off that referenced the old data flow gets reopened.

Settle the Azure data zone question in week one

Put four questions to the customer and the vendor, and get answers in writing:

1. Where may prompts and responses be processed: anywhere, one data zone, or one geography? Take this from the contract or regulator, not from memory.
2. Does the shortlisted model offer that type? Check the availability tables in Foundry Models sold by Azure.
3. Will you need reserved throughput or batch later? Data Zone has DataZoneProvisionedManaged and DataZoneBatch, so the residency answer survives that move.
4. Is the quota you need available in that zone's pool?

Enforce it with Azure Policy

The deployment types docs show a custom policy that denies a chosen SKU. This version covers every global type, plus DeveloperTier, which the docs say carries no data-residency guarantee. Save it as rule.json:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.CognitiveServices/accounts/deployments"
      },
      {
        "field": "Microsoft.CognitiveServices/accounts/deployments/sku.name",
        "in": [
          "GlobalStandard",
          "GlobalProvisionedManaged",
          "GlobalBatch",
          "DeveloperTier"
        ]
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

The docs' own example uses equals for one SKU; in takes a list. The portal version in the custom policy how-to wraps this rule in mode and policyRule.

az policy definition create \
  --name deny-global-foundry-deployments \
  --display-name "Foundry: deny deployment types without data residency" \
  --mode All \
  --rules rule.json

az policy assignment create \
  --name deny-global-foundry \
  --scope "/subscriptions/<your-subscription-id>/resourceGroups/<your-resource-group>" \
  --policy deny-global-foundry-deployments

You need Owner or Resource Policy Contributor at that scope. New assignments take a while to apply, so wait about 15 minutes, then try a GlobalStandard deployment and confirm it is denied. Now the compliant deployment:

az cognitiveservices account deployment create \
  --name <your-foundry-resource> \
  --resource-group <your-resource-group> \
  --deployment-name <your-deployment-name> \
  --model-format OpenAI \
  --model-name <model-name> \
  --model-version <model-version> \
  --sku-name DataZoneStandard \
  --sku-capacity 10

--sku-name is the field this whole article is about. Use a region inside your chosen data zone, and check the model supports the type there.

Global Standard vs Data Zone: the cheap-default objection

The strongest objection is that Global Standard is the sensible default. The docs agree: it launches first, has the lowest price, and offers the broadest region coverage and the highest default quota. For a prototype on synthetic data, use it.

The same page says to move off it only for a specific reason, "such as data residency." If your contract has one, Global Standard is not the cheaper option, it is the non-compliant one. Prototypes also become production, so keep them in their own resource group and scope the policy to the production ones.

First step

This week, add one line to the project charter: "Prompts and responses may be processed in: ____", with a named owner. Assign the policy before the first production deployment.

In production, where inference runs is a compliance fact the customer will audit, so settle it before the first deployment.