Claude Code Bedrock Setup: IAM, Regions, and Trade-offs

A claude code bedrock setup points the CLI at Claude models hosted in your own AWS account instead of the Anthropic API. You enable Anthropic models in the Bedrock console, grant four IAM actions, then set CLAUDE_CODE_USE_BEDROCK=1 and a region. Your traffic and billing stay inside AWS.

Environment variables and IAM actions verified 31 July 2026 against Anthropic's Claude Code on Amazon Bedrock guide.

Most teams reach for this for one of three reasons: a compliance boundary that says model traffic must stay inside their AWS account and region, an existing AWS committed-spend agreement they would rather draw down than add a new vendor invoice, or the fact that IAM, SSO, and VPC controls already exist and nobody wants to manage a second set of credentials. If you are new to the CLI itself, start with what Claude Code actually is before wiring up a provider. Everything below was tested by hand, so you are following a path we have actually walked rather than a theory.

This guide covers the real setup: the environment variables, how AWS credentials resolve, the IAM policy, choosing a region and inference profile, and the handful of errors that account for most failed rollouts.

Why teams choose a Claude Code Bedrock deployment

It changes who you buy from, not what Claude can do. Requests go to a regional AWS endpoint signed with your own credentials, with no Anthropic account in the path. The costs: per-token billing, model freshness that can lag, and a few missing features.

The honest pitch is that Bedrock changes who you buy from, not what Claude can do. Requests go to a Bedrock endpoint in the region you name, signed with your AWS credentials. There is no Anthropic account in the path, no separate API key to rotate, and no new procurement cycle — a claude code bedrock rollout lands on infrastructure your security team has already signed off on.

The trade-offs are just as real, and you should know them before you migrate a team:

• You pay per token, not a flat fee. A Pro or Max subscription is a fixed monthly cost with usage limits. Bedrock bills per input and output token at AWS Bedrock rates. Heavy agentic sessions can cost more than a subscription would.
• Model freshness can lag. New Claude releases reach the Anthropic API first, then Bedrock, then your specific region and account. The docs warn that unpinned aliases resolve to Claude Code's built-in Bedrock default, "which can lag the newest release."
• Some features differ by provider. The WebSearch tool is not available on Bedrock, /logout is unavailable because AWS handles auth, and prompt caching is not supported in every Bedrock region.

Compare that against the alternatives before committing. If flat-rate pricing and same-day model access matter more than the data boundary, the Claude API or a managed enterprise plan may fit better.

Setting up Claude Code Bedrock step by step

Four moves: enable the models in the Bedrock console once per account, let the standard AWS credential chain resolve, export CLAUDE_CODE_USE_BEDROCK=1 with a region, then move the whole block into a settings file so a team inherits one configuration.

There are two paths. Interactively, run claude, pick 3rd-party platform, then Amazon Bedrock, and the wizard detects your AWS profiles, resolves your region, checks which Claude models your account can actually invoke, and writes the result to ~/.claude/settings.json. You can reopen it any time with /setup-bedrock. That is the fastest route for one developer.

For CI or a scripted rollout, configure it manually.

1. Enable model access in Bedrock

This is the step people skip. Open the Amazon Bedrock console, pick an Anthropic model from the Model catalog, and complete the use case form. Access is granted immediately after submission, and it is done once per AWS account. If you run AWS Organizations, submit it once from the management account via the PutUseCaseForModelAccess API (requires the bedrock:PutUseCaseForModelAccess permission) and approval extends to child accounts automatically.

Model access is per model, per region. Enabling Sonnet in us-east-1 does not enable Opus, and does not enable anything in eu-west-1.

2. Let AWS credentials resolve

Claude Code uses the default AWS SDK credential chain, so whatever already works for aws works here — aws configure, an SSO profile, environment access keys, or an instance role on a build box. For SSO:

aws sso login --profile=your-profile-name
export AWS_PROFILE=your-profile-name

There is also a simpler option: Bedrock API keys, set through AWS_BEARER_TOKEN_BEDROCK, which skip full AWS credentials entirely. Note that the credential chain resolve times out after 60 seconds by default, and resolved credentials are cached in memory until five minutes before they expire (or one hour if they carry no expiration).

3. Turn on the provider

# Enable Bedrock integration
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1   # optional if your AWS profile already sets a region
 
# Pin models so a whole team gets the same behavior
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-5'
export ANTHROPIC_DEFAULT_SONNET_MODEL='us.anthropic.claude-sonnet-5'
 
# Optional: run the small/fast model in a different region
export ANTHROPIC_SMALL_FAST_MODEL_AWS_REGION=us-west-2

AWS_REGION is now only needed to override your profile. Claude Code resolves the region in this order: AWS_REGION, then AWS_DEFAULT_REGION, then the region on your active AWS profile, then a fallback of us-east-1. Run /status to see which one won — it even tells you the source.

4. Share it through settings.json

Exporting variables in every developer's shell does not scale. Put them in the env block of a settings file instead so the whole team inherits one claude code bedrock configuration:

{
  "awsAuthRefresh": "aws sso login --profile myprofile",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_PROFILE": "myprofile",
    "AWS_REGION": "us-east-1",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "us.anthropic.claude-opus-5",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "us.anthropic.claude-sonnet-5"
  }
}

awsAuthRefresh runs only when Claude Code detects expired credentials, then retries. Settings files are also the right place for values like AWS_PROFILE that you would rather not leak into other processes. The same file is where you'd normally change which model Claude Code uses, and the mechanics are identical here — only the model IDs change shape.

IAM permissions you actually need

Four Bedrock actions — InvokeModel, InvokeModelWithResponseStream, ListInferenceProfiles and GetInferenceProfile — plus a marketplace-subscription condition. Requests still succeed without GetInferenceProfile, but every new model then costs an extra round-trip while the CLI retries the alternate request shape.

Four Bedrock actions plus a marketplace condition. Take these verbatim from the docs rather than guessing:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowModelAndInferenceProfileAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetInferenceProfile"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:application-inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    },
    {
      "Sid": "AllowMarketplaceSubscription",
      "Effect": "Allow",
      "Action": ["aws-marketplace:ViewSubscriptions", "aws-marketplace:Subscribe"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:CalledViaLast": "bedrock.amazonaws.com" }
      }
    }
  ]
}

bedrock:GetInferenceProfile deserves a note: it lets Claude Code resolve an application inference profile ARN to its backing foundation model so it can pick the right request shape. Without it, requests still succeed — Claude Code retries once with the alternate shape — but every new model costs an extra round-trip. That matters most for AWS_BEARER_TOKEN_BEDROCK deployments, where token policies are usually narrower than a full role. You can tighten Resource to specific inference profile ARNs if a wildcard won't pass review.

Anthropic's docs suggest creating a dedicated AWS account for Claude Code to keep cost tracking and access control clean — good advice if you're rolling this out across a team, and it pairs well with how Claude for business deployments are usually structured.

Regions, model IDs, and inference profiles

Address models through inference profiles, not bare names. The us. prefix means cross-region inference across US regions; GovCloud uses us-gov.. Leave an alias unpinned and it resolves to a built-in default that can lag the newest release.

On Bedrock you address models through inference profiles, not bare model names. The us. prefix marks a cross-region inference profile, which spreads traffic across US regions for capacity. Use a different prefix if your traffic must stay elsewhere; AWS GovCloud regions use the us-gov. prefix.

For example, us.anthropic.claude-opus-5 is currently the ID the opus alias resolves to on Bedrock when you set nothing — and Claude Opus 5 is the newest Opus release, so an unpinned deployment is billed at Opus rates. If you want Sonnet as the primary model, set ANTHROPIC_MODEL to its full ID explicitly.

We don't run this site on Bedrock, but that model-freshness caveat maps directly onto something we hit constantly in our own Claude work: which model actually answers a request matters enormously. We route by task every day — Sonnet as the default, Opus only when a job earns it, Haiku for cheap bulk passes — so an unpinned alias quietly resolving to a lagging default is exactly the kind of surprise that would wreck that discipline. If we did move onto a claude code bedrock setup, we'd pin every model ID explicitly for that reason alone; reverse-engineering which version a team is really calling is not a debugging session anyone enjoys.

Organizations that front models with their own application inference profiles can map versions to ARNs with the modelOverrides setting, using a placeholder like <application-inference-profile-arn> until your platform team hands you real ones. The full variable list lives in the Claude Code environment variables reference.

How to verify and troubleshoot the setup

Run /status — it names the provider and the resolved region, which answers most questions in one line. Failures cluster into five causes: the model not enabled in that region, a bare model ID, expired SSO, the wrong region winning, or a trimmed IAM action.

Verifying a claude code bedrock setup takes under 30 seconds. Start Claude Code and run /status. It shows the provider and the resolved region — that single command answers most "is it even using Bedrock?" questions. Then send a trivial prompt and watch it return.

When a claude code bedrock setup fails, it's almost always one of these:

1. Model not enabled in this region. Run aws bedrock list-inference-profiles --region your-region to see what your account can actually invoke.
2. "On-demand throughput isn't supported." You passed a bare foundation model ID. Specify an inference profile ID instead.
3. Expired SSO credentials. Run aws sso login --profile=your-profile manually. If browser tabs spawn in a loop behind a corporate proxy, remove awsAuthRefresh and sign in by hand.
4. Wrong region. Your profile's region silently won. Check /status, then override with AWS_REGION.
5. Missing IAM action. Compare against the four Bedrock actions above; ListInferenceProfiles is the one most often trimmed.

If you're weighing this against other routes to Claude — signing in through the terminal normally, or going through OpenRouter — the deciding factor is rarely technical. It's whether your data has to stay in your account. If it does, Bedrock is the answer, and the full reference is the official Claude Code on Amazon Bedrock guide.