Terraform is the most common multi-cloud infrastructure-as-code tool: you declare resources in HCL files, Terraform compares them against a state file recording what actually exists, and terraform plan shows the exact create/update/destroy actions before terraform apply makes them. Azure resources are managed through HashiCorp's AzureRM provider. For teams already running Terraform, managing Foundry this way beats a second, portal-driven process: one review pipeline, one drift-detection mechanism, one audit trail across clouds.
Microsoft's supported starting point
Microsoft's Claude-on-Foundry documentation points to the Claude on Foundry starter kit (github.com/Azure-Samples/claude), which provisions a Foundry account, project, and Claude deployments with a single azd up and ships in both Bicep and Terraform variants. The Terraform variant is the authoritative reference for which AzureRM resources and arguments Microsoft currently uses for Claude — consult it (or the AzureRM provider registry documentation) rather than hand-writing resource blocks from memory, because provider schemas and API versions change and neither Microsoft's nor Anthropic's Claude docs publish a frozen resource reference. The starter kit also configures the Anthropic SDK and Claude Code CLI to authenticate via Microsoft Entra ID with no API keys — a pattern worth keeping in your own modules.
What to encode, and what it maps to
Foundry's two-level hierarchy translates naturally into Terraform: a module that creates the Foundry resource (security, billing, and networking configuration) and, inside it, one or more Claude deployments (the callable model instances). The parameters that matter are the same ones the portal asks for:
| Decision | Why it belongs in code |
|---|---|
| Resource region | Only specific regions are supported (Global Standard: East US2, Sweden Central); wrong region fails with "Region not available" |
| Deployment name | Immutable after creation and doubles as the model parameter apps call — changing it in code means destroy-and-recreate, so name deliberately |
| Deployment type | Global Standard vs Data Zone Standard (US) changes where inference runs and applies a documented pricing multiplier for the US data zone |
| Hosting version | Hosted on Azure (version 2) vs Hosted on Anthropic (version 1) changes data boundaries and feature availability |
| Network access | Public network access and Private Link endpoints are resource-level settings, reviewable in the plan diff |
prevent_destroy) on production deployments and treat plan output showing a replace as a red flag in review.Operational realities Terraform does not manage
- Marketplace terms. Claude models are third-party Azure Marketplace offerings requiring subscription and terms acceptance; make sure this account-level prerequisite is handled before first apply, or deployments fail.
- Pipeline identity permissions. The identity running Terraform needs Contributor or Owner on the resource group — the same requirement as the portal flow — and Network Contributor on the VNet if it creates private endpoints.
- Quota. Rate limits (RPM/ITPM) are subscription-level and shared across deployments of the same model and version; creating deployments does not create capacity, and increases go through Microsoft's quota request form, outside Terraform.
- Secrets and state. If you use API keys, remember that resource attributes and outputs can land in the state file. Prefer Entra ID auth; otherwise mark outputs sensitive, restrict state-backend access, and rotate keys on personnel changes.
- Subscription eligibility. Claude requires a paid pay-as-you-go Azure subscription — free trial, student, and credit-only subscriptions are not supported, which surfaces as deployment failures no amount of Terraform will fix.
A sane workflow
Keep one module, one parameter set per environment, and let promotion be a variables change. Model upgrades fit cleanly: add the new deployment resource, apply, test in staging via the versioned-deployment pattern, flip the application's deployment name, and remove the old deployment in a later, deliberate change. Run terraform plan on a schedule to catch portal-made drift — the surest sign someone bypassed the pipeline.
Where to go next
Prefer Azure-native tooling? See ARM templates and Bicep. For what the automation is automating, read Foundry resource setup; for wiring IaC into pipelines, Foundry with Azure DevOps.