On most Azure services, "pick a region" is a long dropdown. For Claude on Microsoft Foundry the choice is narrower and has two dimensions: where your Foundry resource lives, and which deployment type — Global Standard or Data Zone Standard — each Claude deployment uses. This article lays out the current options and the residency statements you can (and cannot) expect from the official documentation.
The current map
| Deployment type | Regions | Models |
|---|---|---|
| Global Standard | East US2, Sweden Central | All Claude models, both hosting versions |
| Data Zone Standard (US) | US data zone | claude-sonnet-5, claude-opus-4-8, claude-haiku-4-5 (Hosted on Azure) |
Your Foundry project or resource must sit in one of the supported deployment regions — if you try to deploy Claude from a resource in an unsupported region, the portal returns a "Region not available" error. Separately, Anthropic's Supported Regions Policy may restrict availability based on your billing country or region, independent of where the Azure resource lives. Region lists change; verify the current list in Microsoft's documentation before you commit an architecture to it.
Global vs. Data Zone: what you're actually choosing
Global Standard gives you the full Claude catalog on Foundry — every model, in both the Hosted on Azure and Hosted on Anthropic flavors (see deployments for that distinction). Data Zone Standard (US) constrains processing to the United States data zone, at the cost of a shorter model list, Hosted on Azure only.
There's also a pricing angle. Claude on Foundry doesn't support Anthropic's inference_geo request parameter, but a US Data Zone Standard deployment is documented as equivalent to setting inference_geo: "us" — and it carries the same 1.1x multiplier on token pricing that US-pinned inference carries on the first-party API. In plain terms: guaranteed-US processing costs about 10% more per token than globally routed requests.
One operational nuance: quota is managed at the Azure subscription level and shared. All Global Standard deployments of the same model and version in a subscription draw from one pool across regions, while Data Zone deployments share a pool within each data zone. Spinning up a second region does not buy you a second quota pool — see Foundry quota types.
Latency: what region choice does and doesn't fix
Region choice sets where your requests enter Azure's front door, so putting the Foundry resource near your application tier keeps that leg short. But with Global Standard, inference itself can be routed globally, and with Hosted on Anthropic deployments the model runs on Anthropic's infrastructure outside Azure entirely. So treat region selection as controlling ingress and data-at-rest location more than end-to-end latency. Measure real latency from your actual workload region before promising numbers to stakeholders.
Data-residency statements you can expect
The residency story depends primarily on the hosting version, not the region dropdown:
Hosted on Azure: prompts and outputs are processed on Azure infrastructure end to end (ingress, API services, GPU inference), and data at rest stays in the selected Azure geography, scoped to the Global or Data Zone deployment option. Per Anthropic, prompts and completions remain within Azure; only usage metadata and safety-flagged content egress to Anthropic. Automatic safeguards may flag content for Anthropic Trust & Safety review on an exceptions basis.
Hosted on Anthropic: data may be processed outside Azure — including outside your selected Azure region — governed by Anthropic's Data Processing Addendum and Commercial Terms. For both options, Anthropic remains the seller and operator and acts as an independent data processor for prompts and outputs.
Where to go next
Pair this with quota types (shared pools change multi-region math) and private endpoints for network-level control. The broader cross-cloud view is in regions and availability.