SSD Nodes Learn 🎉 VPS from $5.50/mo
Guides Matt ConnorBy Matt Connor

Run Claude Code on Bedrock or Vertex AI

Point Claude Code at Amazon Bedrock or Google Vertex AI: the environment variables, where credentials come from, who gets billed, and what you give up.

What changes when Claude Code runs on your own cloud account

You can run Claude Code on Amazon Bedrock or Google Vertex AI, and the switch is two or three environment variables plus the cloud credentials your team already has. Everything local behaves the same: the CLI, subagents, hooks, skills, MCP servers and your CLAUDE.md files. Only the model call moves, and four things move with it: the network the request crosses, the account that pays for it, the Claude models you are allowed to invoke, and the server-side features that exist at all.

The question is rarely whether it works. It works. The question is which of those four you care about most.

The three routings, and what each one costs you

Anthropic direct with a subscription. You sign in with a claude.ai account on the Pro, Max, Team or Enterprise plan. Requests go to Anthropic's API. You pay per seat, and usage is capped by the plan's limits rather than metered per token. This is the only routing that reaches the surfaces built on top of the account, such as Claude Code on the web, the mobile app, Desktop and Remote Control. For a team, the Claude Enterprise plan adds single sign-on and managed policy settings on top of that.

Anthropic direct with an API key. You create a key in the Anthropic Console and pay per token. Same infrastructure and same regions as the subscription, no seat, and usage appears in Anthropic's own dashboard. Which of the two is cheaper depends on how many hours a day the agent actually runs, which is the whole subject of the API against subscription cost comparison and of what Claude Code costs in practice.

A third-party endpoint on Bedrock or Vertex. Your own AWS or Google Cloud account serves the model. Anthropic is not in the request path at inference time. The tokens land on a bill you already receive, under IAM (identity and access management) policies and audit logs you already run. Two further third-party options exist, Microsoft Foundry and Claude Platform on AWS, and they follow the same shape: one environment variable selects the provider, and the cloud account pays.

Naming note, as of August 2026: Google renamed Vertex AI to Google Cloud's Agent Platform. Anthropic's documentation uses the new name, the Claude Code login prompt still says Google Vertex AI, and the environment variables still say VERTEX.

Data residency is the real reason teams do this

On Bedrock the request goes to a Bedrock endpoint in an AWS region you choose, inside your own account. Data at rest is encrypted with AES-256 under AWS-managed keys, and you can supply your own key through AWS KMS (key management service). On Vertex the equivalent is Google-managed encryption keys, with CMEK (customer-managed encryption keys) available. Access is governed by the IAM roles you already use, and the calls appear in CloudTrail or Cloud Audit Logs like any other API call. For a regulated team, that is the whole argument, and it is a good one.

Two details make it less absolute than the marketing suggests.

A cross-region inference profile is not a single region. On Bedrock, Claude Code resolves its built-in default models to cross-region inference profile IDs, and the prefix it prefers comes from the region it resolved: us. in a us-* region, eu. in an eu-* region, apac. in an ap-* region, and us-gov. in GovCloud. A cross-region profile can serve a request from another region inside that geography, so the guarantee you get is a geography, not a city. If your requirement names one region, route through an application inference profile you control and set ANTHROPIC_MODEL to its ARN.

Some traffic still reaches Anthropic, and none of it is your code. Telemetry, error reporting and the /feedback command are off by default on both Bedrock and Vertex, and /feedback writes an archive under ~/.claude/feedback-bundles/ on your own machine instead of uploading anything. Two exceptions run on every provider. Before fetching a URL, the WebFetch tool sends the hostname, and only the hostname, to api.anthropic.com to check a safety blocklist. Session quality surveys also still appear. Switch the first off with skipWebFetchPreflight in your settings file and the second off with CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1, or disable all non-essential traffic at once with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC.

On training: under commercial terms Anthropic does not train models on the code or prompts sent through Claude Code, and third-party platform usage is commercial. The Development Partner Program, the opt-in that does allow training, is not offered to Bedrock or Vertex users at all. Zero data retention on these endpoints is a matter for your agreement with AWS or Google.

Point Claude Code at Amazon Bedrock

Two things happen once per AWS account before any client config matters. Open the Amazon Bedrock console, select an Anthropic model from the model catalog, and submit the use case form: access is granted immediately after submission. Then attach an IAM policy that allows the calls Claude Code makes.

  • bedrock:InvokeModel
  • bedrock:InvokeModelWithResponseStream
  • bedrock:ListInferenceProfiles
  • bedrock:GetInferenceProfile

ListInferenceProfiles is what lets Claude Code check at startup which models your account can really invoke. GetInferenceProfile lets it resolve an application inference profile ARN back to the foundation model behind it, so it can choose the right request shape. Without that one, requests still succeed, because Claude Code retries once with the other shape. The symptom is an extra round trip per new model, not an error.

The quickest client path is the wizard. Run claude, choose 3rd-party platform and then Amazon Bedrock, or type /setup-bedrock in a session that is already signed in. It reads the profiles in your ~/.aws directory, verifies which models you can invoke, and writes the result into the env block of ~/.claude/settings.json, so nothing depends on your shell profile.

For a scripted rollout, set the variables yourself.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1

Credentials come from the standard AWS SDK credential chain, so whatever already works for the aws CLI works here: aws configure, an SSO profile, an assumed role, or a Bedrock API key.

aws sso login --profile=your-profile-name
export AWS_PROFILE=your-profile-name
export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key

The bearer token is the simplest option and the one to handle carefully, because it is a long-lived secret sitting in an environment variable. On a shared build box, prefer a role that expires. The same reasoning covers every other credential the agent can read, which is the subject of keeping secrets out of an AI agent's reach.

The region trap. Claude Code resolves the region in this order: AWS_REGION, then AWS_DEFAULT_REGION, then the region on your active AWS profile, then us-east-1. That last step is a default, not an error, so a team that set no region anywhere and assumed European routing sends its requests to a US region with no warning printed. Run /status inside Claude Code to see the resolved region and the source it came from. To confirm what your account can call in a region, run aws bedrock list-inference-profiles --region your-region.

Run Claude Code on Google Vertex AI

Enable the API and pick up credentials.

gcloud config set project YOUR-PROJECT-ID
gcloud services enable aiplatform.googleapis.com
gcloud auth application-default login

Request access to the Claude models you want in Model Garden. Approval is not instant, so allow 24 to 48 hours. Grant roles/aiplatform.user, which carries the aiplatform.endpoints.predict permission used for both model invocation and token counting.

Then select the provider.

export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=global
export ANTHROPIC_VERTEX_PROJECT_ID=YOUR-PROJECT-ID

CLOUD_ML_REGION takes global, a multi-region location such as eu or us, or a single region. The global endpoint gives the best availability and the least control over where a request is served, so a residency requirement usually means naming a location instead. Model coverage differs across the three forms. When one model you need is missing from the global endpoint, pin that model alone to a location with its VERTEX_REGION_CLAUDE_* variable and leave everything else global. Check the current Vertex AI locations page rather than trusting a list that ages.

The project trap. ANTHROPIC_VERTEX_PROJECT_ID is the lowest-priority source of the project ID. GCLOUD_PROJECT, GOOGLE_CLOUD_PROJECT and the credential file named by GOOGLE_APPLICATION_CREDENTIALS all take precedence over it. On a machine where one of those is already exported, the charges land on that other project, and nothing in the session says so.

Verify after any provider change. Run /status: the API provider line reads Google Vertex AI, and the GCP project, Default region and Model lines show what Claude Code actually resolved. If the provider line is missing, the variables are not reaching the process, because they were exported in a different shell than the one that launched claude. Move them into the env block of the settings file, which is also how you keep a value like AWS_PROFILE out of every other process you start.

Which models you get, and how late they arrive

Aliases such as sonnet and opus do not mean newest. On a third-party endpoint they resolve to Claude Code's built-in default for that provider, which can lag the current release and may not be enabled in your account at all. When the default is unavailable, Claude Code falls back to an earlier or lower-tier model for that session and prints a notice. The fallback is not saved, so the next session tries again and prints it again.

For a rollout across a team, pin the versions.

# Copy the exact IDs from your provider's own model catalog.
export ANTHROPIC_DEFAULT_OPUS_MODEL='<provider model id>'
export ANTHROPIC_DEFAULT_SONNET_MODEL='<provider model id>'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='<provider model id>'

Take the IDs from the models overview and from your provider's catalog, because the format differs by provider: Bedrock expects an inference profile ID or an ARN, Vertex expects a plain model name. Do not copy them out of an article, this one included. Pinning is also a cost control, since the default primary model is an Opus-class model and Opus costs more per token than Sonnet, so a deployment that pins nothing is billed at the higher rate. To fix one model as the session default instead, set ANTHROPIC_MODEL to its full ID.

Model arrival is the clearest trade in this comparison. On Anthropic's own API a model works the day it launches. On Bedrock and Vertex it works once your cloud provider has enabled it in your region and your account has been granted access, which is days later at best and sometimes much longer. If some work must run on the newest model, keep one routing that can reach it. That is the practical case for routing different models to different jobs.

What you give up on Bedrock and Vertex

Everything local works on every provider: subagents, hooks, slash commands, skills, plugins, checkpoints, sandboxing, the managed settings file and OpenTelemetry metrics. The gaps are all server-side.

Unavailable on both endpoints: fast mode, Advisor, Channels, cross-session messaging, the analytics dashboard and server-managed settings. Also unavailable is everything that needs a claude.ai account, which includes Claude Code on the web, the mobile app, Desktop, Remote Control, routines and artifacts.

Bedrock only: the WebSearch tool does not exist there, so Claude cannot run a search from a session routed to Bedrock. It can still read a page with WebFetch when you give it a URL. On Vertex web search does work, for Claude 4 generation models and later.

Partial on both: auto mode runs only on a restricted set of newer models, and /loop needs an explicit interval because it cannot choose one for itself. Check Anthropic's feature availability page before you promise a feature to your team, because this list moves.

Whose bill does it land on

A subscription and a third-party endpoint are separate purchases. Neither one substitutes for the other.

That is worth stating plainly, because the mistake is silent. Set CLAUDE_CODE_USE_BEDROCK=1 on a machine where you are also signed in with a Max seat, and every token is metered by AWS at Bedrock's rates. The seat keeps charging monthly and pays for none of that traffic. There is no combined view either: spend moves to AWS Cost Explorer or Google Cloud Billing, and the Anthropic analytics dashboard is not available on either provider. The /logout command disappears too, because there is no Anthropic session to end. The credential is the cloud credential.

Rates live on the provider's own page and change, so read Amazon Bedrock pricing or Vertex AI pricing rather than any figure in an article. One structural point does not change: on these endpoints you buy per-token inference, so an agent left running all day costs what it costs, with no plan cap to stop it.

Rate limits and quotas work differently on each routing

On a subscription, limits belong to the account, reset on a schedule, and hitting one means waiting. That behaviour is covered in how the usage limits work.

On an Anthropic API key, limits belong to the organization, are expressed as requests and tokens per minute, and rise with your usage tier.

On Bedrock and Vertex, the limits are cloud quotas, scoped per account or project, per model and per region, with no relationship to any Anthropic plan. A 429 means that account hit its quota for that model in that region, so the fix lives in the provider's console: request an increase, or move to a location with headroom. Bedrock charges quota against a token burndown rule rather than a flat request count, and reserved capacity is bought as provisioned throughput. On Vertex, 429s often mean your single-region endpoint does not serve both the primary model and the small fast model, which is why CLOUD_ML_REGION=global is the documented starting point. Google's quotas page covers the increase request.

Failure modes, with the strings you will see

Could not load the default credentials, on Vertex. Application Default Credentials are missing or expired. Run gcloud auth application-default login, or point GOOGLE_APPLICATION_CREDENTIALS at a service account key file.

A 404 naming the model, on Vertex. The model is not enabled in Model Garden for that project, or it is not offered in the location you set. Some models are served only on the global endpoint or on a multi-region location such as eu, never in a specific region.

on-demand throughput isn't supported, on Bedrock. You passed a bare foundation model ID for a model that is only served through an inference profile. Use the inference profile ID instead.

AWS default-chain credential resolve timed out. A step in the AWS credential chain stalled, most often a credential_process helper waiting for input it can never receive. Each resolve of the chain times out after 60 seconds. If your chain honestly needs longer, for example a browser SSO flow with MFA (multi-factor authentication) behind a wrapper, raise the limit in milliseconds with CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS.

An error starting Bedrock streaming response has content-type. Something between Claude Code and Bedrock is rewriting the stream. Bedrock streams in a binary event-stream format with the content type application/vnd.amazon.eventstream, so a gateway that re-emits it as server-sent events hands back a body Claude Code cannot decode. Fix the gateway so it passes the response body and its Content-Type header through unchanged.

Browser tabs opening in a loop during AWS SSO. A corporate VPN or a TLS-inspecting proxy interrupts the sign-in, Claude Code reads the broken connection as an authentication failure, re-runs the awsAuthRefresh command, and repeats forever. Remove awsAuthRefresh from your settings file and run aws sso login by hand before starting Claude Code.

Choosing a routing

Choose Anthropic direct when you want new models on launch day and the complete feature set. Choose an API key when you want per-token billing without buying seats. Choose Bedrock or Vertex when the requirement is that inference happens inside a cloud account you already govern, and you accept a slower model pipeline and a shorter feature list as the price of that. The setup pages worth bookmarking are Anthropic's own, for Amazon Bedrock and for Google Vertex AI, along with the AWS list of models by region.

None of the three changes where the agent itself executes. Claude Code is a local process reading your files and running your commands, whichever endpoint answers it. That is why teams who want it running somewhere other than a laptop put the coding agent on a VPS and export these same variables there.

FAQ

Does my Claude subscription pay for Claude Code on Bedrock or Vertex?

No. A Pro, Max, Team or Enterprise seat and a third-party endpoint are separate purchases, and neither covers the other. With CLAUDE_CODE_USE_BEDROCK=1 or CLAUDE_CODE_USE_VERTEX=1 set, every token is metered by AWS or Google Cloud at their rates and lands on that cloud bill, while the seat keeps charging monthly for the surfaces it covers. Spend tracking moves with it, to AWS Cost Explorer or Google Cloud Billing, because the Anthropic analytics dashboard is not available on either provider.

Which region does Claude Code send my requests to on Amazon Bedrock?

The region it resolved, which /status will show you. Claude Code checks AWS_REGION, then AWS_DEFAULT_REGION, then the region on your active AWS profile, and falls back to us-east-1 when none of those is set. Its built-in default models then resolve to cross-region inference profiles whose prefix follows that region, such as us. or eu., and a cross-region profile can serve a request from another region inside the same geography. When one named region is a hard requirement, use an application inference profile you control and set ANTHROPIC_MODEL to its ARN.

Why is the newest Claude model missing in my Bedrock or Vertex account?

Because each cloud provider enables models on its own schedule, and your account has to be granted access on top of that. On Vertex you request access in Model Garden and approval can take 24 to 48 hours. Until then, aliases such as sonnet and opus resolve to Claude Code's built-in default for that provider, and when that default is not available in your account Claude Code falls back to an earlier or lower-tier model for the session and shows a notice. Pin ANTHROPIC_DEFAULT_SONNET_MODEL and its siblings to IDs you have confirmed are enabled.

Is web search available in Claude Code on Amazon Bedrock?

No. The WebSearch tool is not available on Bedrock, so Claude cannot run a search from a session routed there. It can still read a specific page with WebFetch when you supply the URL. On Google Vertex AI web search does work, for Claude 4 generation models and later, which is one of the few capability differences that runs in Vertex's favour.

Do I need an Anthropic account to run Claude Code on Bedrock or Vertex?

No. Authentication is your AWS or Google Cloud credential, which is why /logout is unavailable on both providers. One connection to Anthropic remains whatever provider you use: before fetching a URL, the WebFetch tool sends the hostname, and only the hostname, to api.anthropic.com to check it against a safety blocklist. Set skipWebFetchPreflight in your settings file to turn that off, and pair it with WebFetch permission rules if you still want to limit which domains Claude can reach.