Cloud
Claude Code on Bedrock, Google Cloud and Microsoft Foundry
August 202613 min read
Set the Bedrock environment variable to switch the provider, then supply AWS credentials or a Bedrock API key and a region prefix for cross-region inference. You can also run Claude Code and pick the third-party platform option at the login prompt for an interactive wizard. Confirm the result with the status command.
Everything that needs a claude.ai subscription: Claude Code on the web and mobile, Slack, the desktop app in its normal form, routines, Remote Control, the Chrome extension, voice dictation, ultrareview, Code Review, artifacts and computer use. Fast mode, the Advisor, channels and cross-session messaging are also unavailable on every cloud provider.
No. Web search is unavailable on Amazon Bedrock. It works on Claude Platform on AWS, on Google Cloud's Agent Platform for Claude 4 models and later, and on Anthropic-hosted Microsoft Foundry deployments. Where it is missing, the WebFetch tool with a specific URL is the documented alternative.
Without pinning, the model aliases resolve to Claude Code's built-in default for that provider, which can lag the newest release and may not be enabled in your account. Pinning with the default-model environment variables also lets you decide when your team moves to a new model rather than finding out on the day it lands.
A proxy routes outbound traffic through a server for monitoring or policy and is configured with the standard proxy environment variables. A gateway sits between Claude Code and the provider to centralise authentication, usage tracking and budgets, and is configured with a base URL variable. They are separate configurations and can be used together.
Key Takeaway
Choosing Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry or Claude Platform on AWS changes where inference runs, not what the CLI can do locally. Skills, hooks, subagents, plugins, MCP, checkpoints and sandboxing all work everywhere. What you give up is a specific, knowable list of server-side and subscription features.
A platform team I worked with moved everyone to Bedrock for procurement reasons, told nobody what changed, and spent the following fortnight fielding reports that Claude had got worse. It had not. Web search was gone, so questions that used to be answered from the live web were now answered from training data — a real difference, invisible in the interface, and entirely predictable from a table nobody had read.
So this post is that table, plus the setup. It covers what the choice actually decides, the variable that selects each provider, the features that need a claude.ai subscription and are therefore gone on every cloud path, the ones that vary by provider, why you should pin model versions, how gateways and proxies fit, and how to pick.
Everything local is unaffected. The CLI and the Agent SDK, the VS Code and JetBrains extensions, subagents, hooks, commands and skills, CLAUDE.md memory, plugins and MCP servers, checkpoints, sandboxing, workflows, OpenTelemetry metrics and the managed settings file all work on every provider. If your reason for choosing a cloud provider is that inference must run inside your own account, none of that is at risk.
For most organisations, though, the recommendation is still a Team or Enterprise plan: one subscription covers Claude Code and Claude on the web, billing is centralised, and there is no infrastructure to stand up. Cloud providers earn their place when procurement, data residency or an existing committed spend makes them the answer — not because they are the more serious option.
A single environment variable selects the provider, and then the provider's own credentials apply. There is also an interactive path: run Claude Code, pick the third-party platform option at the login prompt, and a wizard walks you through Bedrock or Google Cloud.
# One variable selects the provider.
CLAUDE_CODE_USE_BEDROCK=1 # Amazon Bedrock
CLAUDE_CODE_USE_MANTLE=1 # (the Mantle endpoint)
CLAUDE_CODE_USE_ANTHROPIC_AWS=1 # Claude Platform on AWS
CLAUDE_CODE_USE_VERTEX=1 # Google Cloud's Agent Platform
CLAUDE_CODE_USE_FOUNDRY=1 # Microsoft Foundry
# Then the provider's own credentials and location:
AWS_BEARER_TOKEN_BEDROCK=… # or normal AWS credentials
ANTHROPIC_BEDROCK_REGION_PREFIX=eu # us | eu | apac | jp | au | global
ANTHROPIC_BEDROCK_SERVICE_TIER=… # default | flex | priority
ANTHROPIC_VERTEX_PROJECT_ID=my-gcp-project
ANTHROPIC_FOUNDRY_RESOURCE=my-resource
ANTHROPIC_FOUNDRY_API_KEY=… # or ANTHROPIC_FOUNDRY_AUTH_TOKEN
# Or skip all of it: run claude, pick "3rd-party platform" at the
# login prompt, and the wizard walks Bedrock and Vertex for you.
/status # confirm the provider, base URL and proxy in forceVerify with the status command rather than by inspecting your shell. It prints which provider, base URL and proxy the running session is actually using, which settles the recurring question of whether an environment variable set in one place is reaching the process. That check takes a second and has saved me from a long diagnosis more than once.
These need a claude.ai account and are unreachable with an API key or any third-party provider. Together they are the biggest single difference, and worth telling your team about before you migrate rather than after:
Below the subscription line, providers differ from each other. These are the rows that decide which cloud is least painful for the way your team already works, and a couple of them are surprising.
The differences worth checking before you commit:
| Feature | Where it stands |
|---|---|
| Web search | Not available on Amazon Bedrock. Available on Claude Platform on AWS, on Google Cloud for Claude 4 models and later, and on Anthropic-hosted Foundry deployments |
| Fast mode and the Advisor | Neither is available on any cloud provider. Both work on a subscription and on the Anthropic Console |
| Auto mode | Supported on a limited set of models, and the starting permission mode on these providers is Manual rather than auto |
| Channels and cross-session messaging | Unavailable on every cloud provider, including Claude Platform on AWS |
| CI integrations | GitHub Actions works everywhere except Claude Platform on AWS; GitLab CI/CD works everywhere except Microsoft Foundry |
One difference produces bug reports rather than complaints. The loop command cannot pick its own interval or supply its default maintenance prompt on these providers, so a prompt with no interval runs every ten minutes and the bare command prints usage. If a team relies on scheduled work, the migration plan needs explicit intervals written into every loop, not a note to check later.
This is the piece of advice most often skipped and most often regretted. Without pinning, the model aliases resolve to Claude Code's built-in default for that provider, which can lag the newest release and may not be enabled in your account at all. Pinning also means you decide when your engineers move to a new model.
# Pin the models, or your aliases resolve to Claude Code's
# built-in default for that provider — which can lag the newest
# release and may not even be enabled in your account.
ANTHROPIC_DEFAULT_OPUS_MODEL=…
ANTHROPIC_DEFAULT_SONNET_MODEL=…
ANTHROPIC_DEFAULT_HAIKU_MODEL=…
ANTHROPIC_DEFAULT_FABLE_MODEL=…
# Pinning is also how you control WHEN your engineers move to a
# new model, rather than finding out on the morning it lands.
# Routing a cloud provider through an LLM gateway:
ANTHROPIC_BEDROCK_BASE_URL=…
ANTHROPIC_VERTEX_BASE_URL=…
ANTHROPIC_FOUNDRY_BASE_URL=…
ANTHROPIC_AWS_BASE_URL=…
ANTHROPIC_BASE_URL=… # the Anthropic API itself
# A corporate proxy is a SEPARATE concern and composes with it:
HTTPS_PROXY=http://proxy.internal:8080A corporate proxy routes outbound traffic through a server for monitoring or policy, and is configured with the standard proxy variables. An LLM gateway sits between Claude Code and the provider to centralise authentication, usage tracking, rate limits or budgets, and is configured with a base URL variable. They compose, and conflating them is a common source of confusion when only one of the two is actually in play.
Feature availability through a gateway matches the underlying provider it forwards to. Anthropic-only capabilities work only if the gateway forwards requests to the Anthropic API intact — which is a good reason to check a gateway against your actual workflow rather than assuming it is transparent.
Start from the constraint that made you look. If it is data residency or an existing commitment on a particular cloud, that decides it, and the rest of this post is your migration checklist. If it is a vague preference for keeping things in one account, weigh it against the feature list above and against the fact that a Team or Enterprise plan also covers Claude on the web for the same people.
Two operational details are easy to miss. On Bedrock, Google Cloud, Foundry and Claude Platform on AWS, error reporting and telemetry to Anthropic are off by default, which is usually what a security team wants but means you should read the data-usage page rather than assume. And prompt caching works the same way on most providers, though on Bedrock support varies by model — worth checking, because it is a large part of what a long session costs.
Pick the provider your constraints already chose, then do the three things that stop the avoidable pain: pin the model aliases, write explicit intervals into any scheduled work, and tell your team which features are gone before they notice. The gap between providers is not a quality gap — it is a list, and a list can be planned around.
Sources & further reading