Claude on Azure: Choosing Between Claude and Azure OpenAI in Microsoft Foundry

A Microsoft estate no longer implies OpenAI models by default

For two years, the reasoning in most UK enterprises ran: we are an Azure shop, so Azure OpenAI is the path of least resistance, so GPT models it is. That reasoning rested on procurement and governance rather than model quality, and it was often correct.

Claude is now a generally available, Azure-billed, Entra-governed option inside Microsoft Foundry, following the November 2025 Microsoft, NVIDIA, and Anthropic partnership, and that removes the basis for the old reasoning. Microsoft itself now ships Anthropic models across its own products, from Foundry to Microsoft 365 Copilot and Copilot Studio. The question has changed from ‘can we use Claude in our Microsoft estate?’ to ‘which workloads should run on which model, under the governance we already have?’

This guide sets out how we approach that question for UK organisations, with the compliance caveats stated plainly.

What exactly is Claude in Microsoft Foundry?

Microsoft’s documentation describes two hosted versions of the same models:

• Hosted on Anthropic infrastructure: requests are served by Anthropic, outside Azure, with Foundry providing the deployment, identity, and billing surface.
• Hosted on Azure: generally available models running on Azure infrastructure end-to-end, with a choice of Global Standard or Data Zone Standard (US) deployment types.

The compliance analysis for both versions starts from Microsoft’s hosting comparison. It states that Anthropic is the seller of record, the operator, and the data processor for Claude in Foundry, and that any service level agreement (SLA) comes from Anthropic. It also states that Claude models are Non-Microsoft Products under the Product Terms, with data retention governed by Anthropic’s Data Processing Addendum and Commercial Terms. Azure provides the deployment, billing, and support relationship, and also the infrastructure for the Azure-hosted version, while the data processing relationship is with Anthropic.

For both versions, the platform adds the features that make Claude usable in an enterprise setting:

• Identity and governance: Microsoft Entra ID authentication, Azure role-based access control, and existing Azure policy surfaces.
• Billing: usage billed in Claude Consumption Units as a line on the Azure bill, with MACC drawdown, so committed Azure spend covers Claude usage.
• The Claude API surface: the Messages API via the Anthropic SDKs against a Foundry endpoint, with prompt caching, tool use, extended thinking, and streaming.
• Zero data retention available for high-sensitivity workloads.

Model availability and lifecycle differ between the two hosted versions, and the line-up changes with each release. Treat the Microsoft Learn model list as the source of truth on the day you deploy.

How should you choose between Claude and Azure OpenAI?

We recommend Claude first, and we follow that recommendation in our own delivery, where Claude models are the default across our production work. We document the outcomes quarterly in the AI Velocity Report. A default is only useful if its limits are clear, so we set out below the cases where it gives way.

Azure OpenAI leads where:

• The workload is already built and tuned against GPT models, and switching costs exceed any gain.
• The workload depends on deep Microsoft-native integration, because the tightest product couplings across the Microsoft data and productivity stack ship against Azure OpenAI first.
• Your compliance position depends on the workload sitting inside Microsoft’s own product compliance boundary. Azure OpenAI is a Microsoft-operated service, whereas for Claude in Foundry (both hosted versions) Anthropic is the seller, operator, and data processor under Non-Microsoft Product terms. Involve your data protection team in that distinction early.

Claude, our default, leads where:

• The workload is agentic or code-centric, such as multi-step tool use, long-running coding agents, or complex refactoring. Claude’s published strengths sit here, and they are why our own delivery tooling is built around Claude, with the outcomes documented quarterly in our AI Velocity Report.
• The workload needs long-context analysis, such as large document sets, whole-codebase reasoning, and the million-token context windows on current models.
• Caching economics are significant. Agentic and retrieval-heavy workloads re-send large, stable prefixes, and prompt caching changes both cost and throughput (on Foundry, cache reads are also excluded from input-rate limits). Our token cost guide covers the mechanics.

For mainstream generation, summarisation, extraction, and RAG (retrieval-augmented generation) answering, both are capable. We still default to Claude there, for consistency of tooling, terms, and caching behaviour across the estate, and we let a measured evaluation overturn the default where a specific workload gives reason to. Foundry’s evaluation tooling supports side-by-side comparison against your own data, and our Azure AI Foundry service page describes the process we run.

Foundry’s single governance surface makes it possible to mix Claude and OpenAI models in one solution. We treat that the way our token cost guide treats every multi-vendor move. Exhaust single-vendor tiering first, since large, medium, and small Claude models cover most task classes with one set of terms and behaviours, and add another provider’s models only when a measured, recurring workload justifies it. Where you do mix, route deterministically by task class in configuration, so the behaviour is auditable. Per-request ‘smart routing’ hands the decision to another model, and those decisions go unlogged.

The residency caveat for UK buyers

As of August 2026, Azure-hosted Claude deployments offer Global and US data zones only. There is no EU or UK data zone for Claude in Foundry, and the Anthropic-hosted version runs outside Azure entirely. For a UK organisation with in-region processing commitments, that rules Foundry out for those specific workloads today, whatever the billing advantages.

We work through the decision in this order:

1. EU or UK in-region processing contractually required? Route through AWS Bedrock EU regions or Google Vertex AI EU endpoints. The full residency analysis, including the first-party API’s options, is in the Claude GDPR guide.
2. US-region processing acceptable under Standard Contractual Clauses (SCCs) and the UK Addendum? Foundry’s Data Zone Standard (US) deployment is a workable position for many UK workloads, with the standard transfer mechanisms documented.
3. No geographic constraint? Global Standard deployments give the widest capacity.

Check the deployment types and regions documentation on the day of commitment. Data zones are the fastest-moving fact in this area, so re-check this section first when you revisit the decision.

Anthropic models in Microsoft 365 Copilot are a separate arrangement from Foundry. They are currently excluded from the EU Data Boundary and disabled by default for UK, EU, and EFTA tenants. Assess them separately, using our Copilot opt-in post, which covers what UK administrators should check.

What does this mean for the build-side stack?

For teams building AI features into their software, Foundry-hosted Claude fits the standard Azure patterns:

• Entra-authenticated access.
• Azure Kubernetes Service (AKS) for the application tier, or Functions for event-driven pieces.
• A deliberate home for quotas and usage logging.
• Monitoring through the Azure surfaces you already run.

Our deploying Claude agents on Azure guide covers those architectures, and MCP patterns for production agents covers connecting models to your systems safely.

Development tooling is a separate decision. Choosing between Claude Code and GitHub Copilot is a tooling choice rather than a Foundry deployment choice, and we compare them in our guide to Claude Code versus GitHub Copilot for .NET teams.

How to run the decision, in order

1. Classify the workloads. The leading model can differ between agentic and code-centric work, long-context analysis, mainstream generation, and RAG answering.
2. Apply the residency filter first. Each workload either can or cannot use a given route, so this step removes options before any discussion of quality.
3. Evaluate the shortlist against your data. Measure grounding accuracy, task success, latency, and cost per outcome in Foundry’s evaluation tooling, rather than relying on vendor benchmarks.
4. Decide the governance envelope. One platform (Foundry) with per-workload model choice keeps identity, billing, and policy in one place. Additional platforms (Bedrock, Vertex) come in only where residency or capability requires them.
5. Write the routing down. Record which task classes use which model in configuration, and set a review cadence, as our token cost guide recommends for tiering.

Next steps

If you have a model decision to make now, read the Claude GDPR guide next for the assurance and residency detail. If the workload involves your own data, read RAG versus fine-tuning versus prompt engineering as well.

We run this evaluation as a structured engagement covering workload classification, the residency filter, side-by-side evaluation in Foundry, and a written routing policy. Book a free consultation to scope it.