Claude on Azure is GA: Foundry deployment and CCU costs

Claude is now generally available in Microsoft Foundry. Microsoft and Anthropic announced GA on 29 June 2026, with Claude Opus 4.8 and Claude Haiku 4.5 running on Azure infrastructure end to end: native endpoints, Microsoft Entra ID authentication, Azure role-based access control, and billing through a new Azure Marketplace meter called Claude Consumption Units (CCU). The Messages API arrives with prompt caching, extended thinking and tool streaming intact, and Foundry Agent Service can use Claude as the reasoning core of an agent. This follows the Microsoft, NVIDIA and Anthropic partnership announced in November 2025, which first brought Claude models into the Foundry catalog in preview.

For a Swedish organisation standardised on Azure, the procurement story is the headline. There is no separate Anthropic contract to negotiate. You subscribe to the offer through Azure Marketplace, usage lands as one consolidated line on your Azure invoice, and eligible customers draw the spend against their Microsoft Azure Consumption Commitment (MACC). Identity, networking and governance controls you already run keep working. The caveat sits in the data-zone column: at launch there are Global and US data zones only, with Anthropic acting as data processor. That combination deserves a proper residency assessment before anything regulated goes to production, and the second half of this article walks through exactly that.

What GA actually includes

Two hosting options in one catalog

Foundry now offers Claude models in two configurations, and the distinction matters more than the marketing suggests. The Hosted on Azure option runs inference on Azure infrastructure: request ingress, API services and GPU inference all execute inside Azure, and this is the version that reached GA with Opus 4.8 and Haiku 4.5. The Hosted on Anthropic infrastructure option routes your requests to Anthropic's own environment. It exposes a broader model lineup and the fuller Claude API feature set, but your prompts and outputs may be processed outside Azure, including outside your selected region. Both options are purchased, deployed and billed the same way through Foundry.

In both configurations Anthropic is the seller of record, operates the inference service, and acts as data processor for prompts and outputs. Claude models are Non-Microsoft Products under the Microsoft Product Terms. Support still goes through Microsoft, which is a genuine simplification for teams that want one throat to choke, but the contractual data-protection relationship for model traffic is with Anthropic under Anthropic's Data Processing Addendum. Keep that distinction in mind for the compliance section below.

The feature surface

The GA release ships the capabilities that make Claude economical to run in production rather than a bare Messages endpoint:

Prompt caching: repeated context (system prompts, tool definitions, long documents) is cached so you stop paying full input price for it on every call. If you run agents with large tool schemas, this is the single biggest cost lever.
Extended thinking: the model can spend additional reasoning tokens on hard problems, with visibility into the reasoning process.
Tool streaming: tool-use parameters stream incrementally, which cuts perceived latency for agents that pass large arguments.
Zero data retention option: prompts and completions are not retained after the API call completes, for workloads where even transient provider-side storage is a problem.

On the agent side, Foundry Agent Service can now use Claude as the reasoning core of an agent while the Foundry Control Plane monitors and evaluates agent responses. Microsoft's announcement also points at the Foundry model router, which it claims can cut model spend by up to 50 percent while improving user satisfaction by routing each request to an appropriate model. Treat that number as a vendor claim to validate against your own traffic, but the mechanism is real: with Claude and Azure OpenAI models behind one router, per-request model selection becomes a configuration decision instead of an architecture decision.

How to deploy it

Deployment follows the Foundry partner-model flow rather than the classic Azure OpenAI flow. The sequence:

1. Check Marketplace permissions. Claude requires an Azure Marketplace subscription to the Claude offer. Whoever deploys needs the RBAC rights to subscribe to Marketplace offerings on the billing account, which in most enterprises is not the individual developer. Sort this first; it is the step that stalls pilots.
2. Subscribe and accept the offer. From the Foundry model catalog or Azure Marketplace, subscribe to the Claude offer and accept it on your Azure billing account. This is the moment the CCU meter attaches to your invoice.
3. Deploy the model. Pick Claude Opus 4.8 or Claude Haiku 4.5 from the catalog and choose the deployment type. Where a model exists in both hosting versions, Foundry lands you on the Azure-hosted version by default. Choose your data zone deliberately rather than accepting the default.
4. Wire up authentication. Deployments authenticate with Microsoft Entra ID, so use managed identities from your workloads and scope access with the same RBAC model you use for the rest of Foundry. No long-lived Anthropic API keys to vault and rotate.
5. Call the Messages API. The deployment exposes an Anthropic-native endpoint on your Foundry resource. Existing code written against the Anthropic Messages API ports with a base-URL and auth change rather than a rewrite.

curl -X POST \
  "https://<resource-name>.services.ai.azure.com/anthropic/v1/messages" \
  -H "Authorization: Bearer <entra-id-token>" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-4-8",
    "max_tokens": 1024,
    "messages": [
      { "role": "user", "content": "Summarise this contract clause..." }
    ]
  }'

Because the endpoint speaks the Anthropic API shape, the official Anthropic SDKs work against it. That matters for portability: an application written this way can move between Foundry, the first-party Claude API and other clouds that host Claude with minimal code churn, which is a useful negotiating position to preserve.

One operational note: Foundry does not apply Azure AI Content Safety filtering to Claude deployments at deployment time. Anthropic's own safety systems are active, but if your governance model assumes the Azure content-filter layer sits in front of every model, you need to configure content safety explicitly or update the assumption.

What Claude Consumption Units cost, versus Azure OpenAI

CCU is a billing translation layer, not a new pricing scheme, and understanding it takes about two minutes. For every call, Anthropic meters your input and output tokens per model and prices them at its published per-model token rates, the same rates listed on the Claude pricing page. Any negotiated discount is applied. The resulting dollar amount converts to CCUs at a fixed rate of one cent per CCU, and the CCU quantity is reported hourly to Azure Marketplace. You are invoiced monthly in arrears on your normal Azure bill.

The arithmetic: 100 CCU equals 1 USD of Claude usage at list rates. A workload that consumes 2,000 USD of Claude tokens in a month shows up as 200,000 CCU on the invoice. Budget in dollars at Anthropic's published token prices, then divide by 0.01 to sanity-check the meter. Because the rate in effect at call time applies, Anthropic price changes flow through immediately rather than at contract renewal.

How this differs from Azure OpenAI billing is where cost planning gets interesting:

Meter type: Azure OpenAI is a first-party Azure service with per-token meters in the Azure price list. Claude is an Azure Marketplace metered offer at Anthropic's list prices. Both hit the same invoice, but they sit in different sections of your cost-management exports, so update your FinOps tagging and reports.
MACC treatment: CCU spend decrements your MACC like other Marketplace consumption. For organisations with committed spend to burn down, Claude usage now counts, which was the practical blocker for many Swedish enterprises using Claude at all.
No provisioned capacity: Azure OpenAI offers provisioned throughput (PTU) reservations for predictable high-volume workloads. Claude in Foundry at GA is pay-as-you-go only, with no prepaid CCU credits and no reserved-capacity equivalent. If your workload profile justifies PTUs today, that economics comparison does not yet exist on the Claude side.
Discount mechanics: Azure OpenAI pricing is negotiated within your Microsoft agreement. Claude discounts come from Anthropic, typically via an Azure Marketplace private offer, and are applied before the CCU conversion. Two vendors, two discount conversations.
Cost controls: prompt caching is the lever that changes the math most. Cache-friendly agent designs (stable system prompts, stable tool schemas, cache breakpoints ahead of the volatile suffix) cut effective input cost substantially on both platforms, but agents with large tool surfaces feel it most.

The Swedish and EU angle: residency, processor chain, procurement

There is no EU data zone at launch, and that is the fact to plan around. Azure-hosted Claude deployments offer Global and US data zones. Global Standard means processing can occur on Azure capacity anywhere in the world; the US data zone constrains processing to the United States, which helps American customers and does nothing for you. Data at rest stays in your selected Azure geography for Azure-hosted deployments, but inference processing is not confined to the EU. Compare Azure OpenAI, which has offered EU data-zone deployments since 2024. If your data classification requires EU-bounded processing, Azure OpenAI keeps that advantage today, and your Claude assessment becomes a transfer-impact analysis rather than a residency checkbox.

The processor chain changes, and your Article 28 paperwork with it. With Azure OpenAI, Microsoft processes model traffic under the Microsoft Products and Services Data Protection Addendum you have already assessed. With Claude in Foundry, Anthropic is the data processor for prompts and outputs, under Anthropic's DPA and commercial terms, even though Microsoft bills you and provides support. Concretely: your GDPR Article 30 records need a new processor entry, your DPO needs to review Anthropic's DPA rather than assume Microsoft's covers it, and any transfer assessment must consider that Anthropic is a US company. Anthropic's Trust Center documents its compliance posture; the review is bounded work, but it is work, and it belongs before the pilot rather than after.

Mitigations exist and are meaningful. The zero-data-retention option removes provider-side persistence of prompts and completions, which shrinks the data-protection surface to in-flight processing. Entra ID authentication means no shared API keys, and access reviews run through your existing identity governance. For many workloads (internal productivity, code assistance, analysis of non-personal data) the Global data zone plus zero data retention plus a documented assessment is a defensible position. For workloads processing sensitive personal data under Swedish sectoral rules, wait for an EU data zone or keep those flows on an EU-bounded alternative.

Procurement gets dramatically simpler. For public-sector and regulated buyers, the fact that Claude now arrives through an existing Microsoft agreement, bills through Azure, counts against MACC and routes support through Microsoft removes most of the friction that made a separate Anthropic engagement hard to justify in an upphandling context. One caution: Marketplace metered offers have historically had restrictions on subscription types, and purchases through CSP partners are a common gap. If you buy Azure through a partner, verify offer eligibility for your subscription type before promising anyone a delivery date.

Decision framework: which path for which workload

Choose Azure-hosted Claude in Foundry when you want Claude quality inside Azure governance: Entra ID, RBAC, consolidated billing, MACC drawdown, and processing on Azure infrastructure. Accept the Global or US data-zone constraint consciously.
Choose Anthropic-hosted Claude through Foundry when you need API features or models not yet in the Azure-hosted version and can accept processing outside Azure. You keep the Azure billing and procurement benefits.
Stay on Azure OpenAI for workloads that require EU data-zone processing, provisioned-throughput economics, or where Microsoft-as-processor is a hard requirement from your DPO. Nothing about this GA forces a migration.
Mix deliberately. The realistic end state for most Azure estates is both model families behind one governance layer, with routing decided per workload by data classification first and model fit second. Foundry's router and Agent Service make that operationally cheap for the first time.

Rollout checklist

1. Confirm your subscription type can purchase the Claude Marketplace offer, and identify who holds Marketplace subscribe permissions on the billing account.
2. Run the data-protection review now: Anthropic DPA, Article 30 record update, transfer assessment for the Global data zone, and a written position on zero data retention.
3. Classify candidate workloads by residency requirement. EU-bounded processing stays on Azure OpenAI for now; everything else is eligible.
4. Deploy Haiku 4.5 first for a cost-safe pilot; move to Opus 4.8 where task quality demands it.
5. Design for the prompt cache from day one: stable system prompts and tool schemas, volatile content last.
6. Set up cost-management alerts on the CCU meter and reconcile the first invoice against your own token telemetry, remembering the 100-CCU-per-dollar conversion.
7. Decide your content-safety stance explicitly, since Azure's content filtering is not applied to Claude deployments by default.
8. Keep your code on the Anthropic API shape via the official SDKs so the portability you gained at procurement survives in the codebase.