Europe costs nine per cent

Nine per cent. That is the premium you pay from 1 September 2026 for deciding that your inference is processed in Europe, measured against the same request on Global Standard. I first took the number for the story. It is not. The story is that data residency in Microsoft Foundry has become a line item in your cost model, and that for part of your model catalogue you cannot buy it at all.

Three price levels, one effective date

Microsoft has repriced the deployment types that narrow where processing happens. Global stays the baseline and stays unchanged. Anything narrower costs more, and the new APAC zone starts at the top.

Deployment type

Where processing happens

Price against Global from 01.09.2026

Global Standard

any Azure region where the model is deployed

baseline, unchanged

Data Zone Standard, EU

anywhere inside the EU zone

plus 9 per cent

Data Zone Standard, APAC

anywhere inside the new APAC zone

plus 20 per cent

Standard, meaning regional outside the US

exactly the region of your deployment

plus 7 to 16 per cent

Two points that the announcement does not stress and that matter more for planning than the percentages.

First, the premium buys processing, not storage. Data at rest stays in the assigned Azure geography for every deployment type. What you are paying for is a commitment about the path of the request.

Second, the deployment type also determines your quota. Global Standard deployments of the same model share one pool across all regions in a subscription, Data Zone deployments share a pool per zone. Moving from Global to EU changes the tariff and the pot you draw from.

A data zone is not the EU Data Boundary

The two terms get used interchangeably in tenders, and that goes wrong on a regular basis.

A data zone is a technical property of a single Foundry deployment. You pick it when you create the deployment, it applies to that deployment only, and from September it carries a price.

The EU Data Boundary is a contractual commitment spanning a set of services. It has a different scope, its own list of exclusions and its own small print. Together they do not add up to one statement about your architecture. They are two separate checks.

The sentence worth putting into your review template: a data zone governs where a request is processed, the EU Data Boundary governs what Microsoft commits to contractually. A deployment can run inside the EU zone and still call models that sit outside the scope of the boundary.

The exclusion list lives in the model catalogue

This is where it becomes concrete, and this is the part you cannot solve by paying.

Claude comes in Foundry in two variants, one hosted on Anthropic infrastructure outside Azure and one hosted end to end on Azure, the latter GA. Data Zone Standard exists for it as a US zone only, and only for the Azure-hosted claude-opus-5, claude-opus-4-8 and claude-sonnet-5. There is no EU zone for Claude. Everything else runs Global Standard.

Two further details rarely appear together. Claude in Foundry bills through an Azure Marketplace subscription in Claude Consumption Units and sits in the Product Terms as a Non-Microsoft Product. And Foundry ships no built-in content filtering for Claude deployments, so if you need a filtering layer you configure it yourself.

In practice: for models listed as partner models, the residency decision is made when you choose the model, not when you create the deployment. Read the catalogue row before you draw the architecture, not after.

On the seat side there is no deployment type

The dispatch on AI gateways argued that a gateway only sees traffic running on API keys, and that seats stay outside. Processing location follows the same split, with different consequences.

In Copilot, Copilot Studio and the agent modes in Word, Excel and PowerPoint you do not pick a deployment type. You get admin centre settings instead, and two of them belong on your list.

One is the setting for AI providers operating as Microsoft subprocessors, which controls the use of Anthropic models in the Microsoft 365 apps. Processing for those models happens outside the EU Data Boundary, with Anthropic acting as a Microsoft subprocessor under the Product Terms and the DPA. For tenants in the EU, EFTA and the UK created after 25 March 2026 the setting is on by default. Older tenants find their default in the Message Center.

The other is flex routing, which lets inferencing leave the EU Data Boundary under peak load. In Power Platform a dedicated checkbox appears for it once the environment sits inside the boundary.

Neither setting costs you anything, and both change the answer to the question your data protection officer will ask. That is the difference to the Foundry side: there you buy residency, here you administer it.

What I cannot assess

The four percentages come from Microsoft's announcement. The pricing page itself renders rates per model and region only in the portal, so I could not verify the individual values. If you are budgeting, pull the numbers for your specific models from the pricing calculator rather than from this text.

Whether the premium applies to provisioned throughput as well is unclear to me. Reservations are purchased separately for Global, Data Zone and Regional and are not interchangeable, which suggests separate tariffs. Whether running reservations are grandfathered, I found no documented answer.

It is also open whether the change reaches models billed through the Marketplace in their own consumption units, as Claude is. Since there is no EU zone there anyway, the question is largely academic for European workloads.

My recommendation

Decide the deployment type per workload, not per tenant. A tenant-wide "everything EU" rule sounds tidy and pays nine per cent on requests that never needed the commitment.

Before the effective date you want two lists. The first: every deployment running today on a data zone or on regional outside the US. That is exactly the set whose invoice grows in September. The second: one row per workload with model, deployment type and reason. Where the reason stays empty, Global is the right answer.

Then the two admin centre settings, with a date and an owner. That is not a technical measure, it is the most important one.

I consider the change an honest one. A regional pool with high availability costs more than a global one, and a price tag forces the decision that used to disappear under "let us do it to be safe". My reservation stands regardless: a premium you can pay is harmless next to a zone that does not exist for your model. Check availability first, price second.

Sources

• Microsoft Foundry Model Deployment Pricing Update, Microsoft Community Hub, 27.07.2026
• Claude models in Microsoft Foundry, Microsoft Learn, as of 17.08.2026
• Understanding deployment types in Microsoft Foundry Models, Microsoft Learn, as of 08/2026
• Region availability for Foundry Models sold by Azure, Microsoft Learn, as of 07/2026
• Microsoft Foundry Models quotas and limits, Microsoft Learn, as of 17.07.2026
• Copilot in Microsoft 365 apps with Anthropic models, Microsoft Learn, as of 08/2026
• Move data across regions for Copilots, AI agents, and generative AI features, Microsoft Learn, as of 2026
• Save costs with Microsoft Foundry Provisioned Throughput Reservations, Microsoft Learn, as of 17.07.2026