Claude on Microsoft Foundry has a two-level structure that maps cleanly onto infrastructure-as-code: a Foundry resource holds security and billing configuration, and one or more deployments inside it are the model instances your applications actually call. Both levels are Azure resources, which means both can be provisioned from an Azure DevOps pipeline rather than by hand in the portal. This article walks through what that pipeline needs to do and where Claude-specific details can trip up an otherwise standard CI/CD setup.
What the pipeline provisions
A minimal pipeline stage creates (or updates) three things: the Foundry resource, the Claude deployment inside it, and whatever configuration your application reads at runtime — typically the endpoint and a key or identity assignment. Microsoft and Anthropic publish a "Claude on Foundry starter kit" (github.com/Azure-Samples/claude) that provisions a Foundry account, project, and Claude deployments with a single azd up, with both Bicep and Terraform variants. Even if you don't adopt it wholesale, it is a working reference for the resource shapes your templates need — and it wires the Anthropic SDK to authenticate with Microsoft Entra ID (Azure's identity service) so no API keys exist to manage at all.
A few prerequisites must be true of the subscription your service connection targets: a paid Azure subscription (free trial, student, and credit-only subscriptions are not supported for Claude), Azure Marketplace access, and Contributor or Owner role on the resource group. Claude models are third-party Azure Marketplace offerings from Anthropic, so the Marketplace terms must be accepted for the subscription — a one-time step that is easy to forget when a pipeline is promoting to a fresh subscription.
Claude-specific choices to encode in your templates
| Setting | What to know |
|---|---|
| Deployment name | Defaults to the model ID (e.g. claude-sonnet-5); it is the value applications pass as the model parameter, and it cannot be changed after creation. Treat it like a public API contract. |
| Region | Global Standard deployments are supported in East US2 and Sweden Central; a "Region not available" error means your template targeted an unsupported region. |
| Model version | Version 1 = Hosted on Anthropic infrastructure; version 2 = Hosted on Azure. Default settings auto-select Hosted on Azure. |
| Deployment type | Global Standard, or Data Zone Standard (US) for supported models when inference must stay within the United States. |
model value in every request, decide your naming convention before the first pipeline run — renaming later means creating a new deployment and migrating callers.Getting credentials to the application stage
After provisioning, your release stage needs to hand the application an endpoint and credentials. The endpoint follows a predictable shape — https://<resource-name>.services.ai.azure.com/anthropic — so it can be derived from the resource name your template already knows. For keys, the portal exposes them on the deployment's Details tab; in a pipeline you would retrieve them via your standard Azure tooling and push them into your secret store, never into pipeline variables in plain text. The cleaner pattern is to skip keys entirely: grant the application's managed identity a role such as Cognitive Services User and let the SDK authenticate with Entra ID. The Anthropic SDKs auto-read ANTHROPIC_FOUNDRY_API_KEY, ANTHROPIC_FOUNDRY_RESOURCE, and ANTHROPIC_FOUNDRY_BASE_URL environment variables, so app configuration reduces to setting those per environment.
A smoke test worth automating
A deployment that exists is not a deployment that works. Add a short post-deploy check that sends one real request:
import os
from anthropic import AnthropicFoundry
client = AnthropicFoundry(
api_key=os.environ["ANTHROPIC_FOUNDRY_API_KEY"],
resource=os.environ["ANTHROPIC_FOUNDRY_RESOURCE"],
)
msg = client.messages.create(
model="claude-sonnet-5", # your deployment name
max_tokens=32,
messages=[{"role": "user", "content": "Reply with OK."}],
)
assert msg.content, "empty response from Foundry deployment"Failures here catch the common post-provisioning problems: Marketplace terms not accepted, a missing RBAC role (403s usually mean a missing role such as Cognitive Services User), or quota — claude-fable-5 defaults to 0 requests per minute on pay-as-you-go subscriptions, so a pipeline that provisions it will succeed while every call fails until quota is granted.
Where to go next
For the template layer itself, see Foundry with ARM templates and Foundry with Terraform; for the identity-based pattern, Foundry and managed identity. The quickstart covers the first manual call if you haven't made one yet.