Claude Code can run through AWS, Google Cloud or Azure — but model pinning matters

Anthropic’s coding tool can use existing cloud billing, identity and access controls, but teams need to configure permissions, regions and exact model versions to avoid unexpected costs or failed requests.

Claude Code can be routed through a company’s existing cloud estate rather than through a direct Anthropic login, which makes it easier for teams that already centralise billing, identity and policy in AWS, Google Cloud or Azure. Anthropic’s own documentation says Amazon Bedrock, Google Cloud’s Agent Platform, formerly Vertex AI, and Microsoft Foundry are all supported, with the main difference being where authentication and metering occur rather than how developers use the tool once it is running. For organisations already operating under cloud governance, that can simplify cost allocation and access control, provided the setup is handled carefully.

The practical choice is usually the cloud the organisation already uses. Anthropic provides interactive setup wizards for Bedrock and Google Cloud’s platform, while Foundry is configured entirely through environment variables. In all three cases, the first step is to select the provider, then point Claude Code at the right account, project or resource, and finally confirm the setup with the status command. That distinction matters because the cloud platform changes the sign-in method, region handling and permission model, but not the core editing workflow.

For Amazon Bedrock, Anthropic says users need Bedrock access, model approval for the Claude variants they plan to use, and IAM permissions that allow model invocation and inference-profile lookups. The guide supports both the guided wizard and manual configuration, including AWS profiles, temporary credentials and Bedrock API keys. It also allows cross-region inference profiles and service-tier selection, which can be important when a region does not expose the exact model a team wants. AWS’s own guidance on temporary credentials aligns with Anthropic’s advice to prefer short-lived access over long-lived IAM keys for production work.

The Bedrock documentation also places unusual emphasis on model pinning. Anthropic notes that Claude Code can fall back to built-in defaults if a team does not pin exact versions, and that those defaults may not match what developers expect or what a given account can actually use. The company also warns that the primary model choice affects cost, since Opus tiers are more expensive than Sonnet. For large deployments, that makes version pinning a control measure rather than a cosmetic preference: it reduces rollout surprises, stabilises billing and gives administrators a clear change-management point.

Google Cloud’s Agent Platform follows a similar pattern, but with Google’s identity and regional model access rules. Anthropic’s documentation says users need billing enabled on the project, the relevant API switched on, Claude model access approved in Model Garden, and quota in the chosen region. The setup can be driven either through the wizard or through Google Application Default Credentials, a project identifier and the region variables. Anthropic also notes that model access requests may take 24 to 48 hours, which means access planning should happen before the rollout window rather than during it.

Region selection is more flexible on Google Cloud than many teams expect. Anthropic says Claude Code can use a global endpoint, a multi-region such as eu or us, or a specific region, and that some model and endpoint combinations require their own region variables. The official guide also states that the roles/aiplatform.user role is enough for the basic workflow because it includes the predict permission needed for inference and token counting. For administrators, that means a relatively small permission set can be enough for day-to-day use, although access to the model itself still depends on approval and regional availability.

Microsoft Foundry is the most manual of the three integrations. Anthropic says users must create a resource, deploy the Claude models they want to expose, and choose the hosting option for each deployment. Authentication can then be handled through an API key, Microsoft Entra ID with the Azure credential chain, or a bearer token, with the bearer token taking precedence if multiple methods are present. The documentation also recommends assigning either Azure AI User or Cognitive Services User, or building a narrower custom role if the organisation wants tighter control.

Foundry also stands out because Anthropic says it does not perform the same startup model check used elsewhere. If a deployment is missing or unavailable, requests can fail rather than quietly shifting to a different model. That makes exact version pinning especially important, because a team that relies on auto-selection is more likely to encounter runtime failures. Anthropic’s model configuration documentation reinforces the point across all third-party providers: aliases are convenient, but exact identifiers are the safer choice when predictable behaviour matters.

Across all three clouds, the common operational lesson is the same: set the provider switch, keep the account or resource reference precise, and pin model versions before wider use. Anthropic’s settings documentation also makes clear that environment variables and user-level settings are often the best place to store cloud-specific configuration, especially in team environments where a value may need to persist across sessions. For organisations already paying for AWS, Google Cloud or Azure, that can turn Claude Code into a governed internal tool rather than a separately managed service, so long as administrators verify access, region and model selection before the first serious rollout.