Claude Code with Amazon Bedrock: Setup, IAM, and Cost Control

Why run Claude Code on Amazon Bedrock

For most individual developers, pointing Claude Code at Anthropic's API or a subscription is the simplest path. Enterprises on AWS often choose Bedrock instead for reasons that have nothing to do with the model and everything to do with where it runs:

• Data residency and contracts. Inference happens in your AWS account, in a region you choose, under the agreement and data-handling terms you already have with AWS.
• Consolidated billing. Claude Code spend lands on the same AWS invoice as the rest of your platform, rather than a separate Anthropic bill.
• Existing guardrails. Your VPC, logging and IAM model already wrap Bedrock, so the agent inherits controls you have already built. For the trade-offs of the platform itself, see our honest review of Amazon Bedrock.

The trade-off is that the per-developer accounting Anthropic builds into its own plans stops at the AWS boundary. Everything below is about keeping the platform benefits without losing that visibility.

Pointing Claude Code at Bedrock

Claude Code talks to Bedrock through the standard AWS credential chain — there is no separate API key to distribute. You switch the backend with environment variables and let the AWS SDK resolve credentials as it normally would (an SSO profile, an instance role, or a federated session):

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-west-1
export ANTHROPIC_MODEL='<bedrock-model-id-for-sonnet-5.5>'
# credentials come from your usual AWS profile / SSO / instance role

Because authentication is just AWS credentials, access follows your identity provider and short-lived sessions rather than a long-lived token sitting in a config file — which is already a meaningful security win over a shared API key. If you would rather not set variables by hand, the CLI also ships an interactive wizard: run claude, pick the third-party-platform option and then Amazon Bedrock, or run /setup-bedrock from an existing session. The wizard detects your AWS profile, asks for a region, verifies which Claude models your account can actually invoke, and writes the result into your settings file — handy for a laptop, while the explicit variables above are better for CI and scripted fleet rollouts.

A few variables carry the whole configuration. These are the ones worth knowing before a rollout:

One behaviour catches teams out: if you do not pin a primary model, the opus alias resolves to the current default Opus tier — so you are quietly billed at the Opus rate for everyday coding that Sonnet would handle at roughly a fifth of the output cost. Pin ANTHROPIC_MODEL to a Sonnet ID and reserve Opus for the work that needs it. For how the tiers compare, see the Opus, Sonnet and Haiku routing guide.

The IAM model: least privilege for an agent

Claude Code on Bedrock needs very little — the ability to invoke specific models, nothing more. Scope the policy to the exact model and inference-profile ARNs your team is approved to use, in the regions you run, and keep streaming and non-streaming invoke together.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream"
    ],
    "Resource": [
      "arn:aws:bedrock:eu-west-1::foundation-model/<approved-claude-model-id>",
      "arn:aws:bedrock:*:*:inference-profile/<approved-profile>"
    ]
  }]
}

The table below is the minimum an agent should hold, and the permissions it should never be granted.

The ARN list is a model policy: restrict it to Sonnet and Haiku, and a developer cannot quietly run Opus all day. That is cost control enforced in IAM rather than asked for in a wiki. Two practical notes: current Claude tiers are invoked through cross-region inference profiles, so your resource list usually needs the inference-profile ARNs alongside the bare foundation-model ARNs, and the first invocation in an account may also require a one-time Bedrock Marketplace subscription — scope any such permission with a condition so it can only be called via Bedrock. A clean pattern is a dedicated AWS account for Claude Code, which makes both the cost line and the access boundary trivial to reason about.

Choosing a region and model ID

Before any of this works, someone has to enable the Claude models in the account. In the Amazon Bedrock console you open the model catalog, select the Anthropic models you want, and submit the short use-case form once per account; access is granted immediately. On AWS Organizations you can submit it once from the management account and have approval flow to child accounts, so a platform team can enable models fleet-wide in a single step.

Region and model availability are tied together, and this is where a rollout most often stumbles. A model ID valid in one region may not exist in another, and most current Claude tiers are served through cross-region inference profiles rather than as plain on-demand foundation models. Those profile IDs carry a region prefix, and Claude Code picks the prefix from the region you resolve to:

Claude Code resolves the region in a defined order — AWS_REGION, then AWS_DEFAULT_REGION, then the region on your active AWS profile, then a built-in fallback — so set AWS_REGION explicitly in a fleet rollout rather than relying on whatever each laptop's profile happens to carry. A common error, "on-demand throughput isn't supported," almost always means you pinned a bare foundation-model ID that the region only serves through a profile: pin the inference-profile ID (the prefixed form) instead. Confirm availability in the exact region you intend to pin before a fleet-wide rollout — enabling a model in one region does not enable it everywhere.

The cost-visibility gap

Here is the part teams discover after rollout. On Bedrock, Claude Code is billed per token to your AWS account, and Anthropic does not see that traffic — so the analytics dashboards and the Claude Code Analytics API that work on subscription and Console plans do not cover Bedrock usage at all. Cost Explorer shows you a Bedrock line item, but not which developer, which repository, or which model drove it.

So on Bedrock you have exactly two ways to attribute spend per developer: export OpenTelemetry metrics from each machine into your own observability stack, or route the traffic through an AI gateway that meters every request by key. The first instruments endpoints; the second gives you a control point as well. The difference matters: attribution without a control point tells you who overspent but cannot stop it, while a gateway resolves every request to a person and can refuse the one that would blow a budget. For a deeper treatment of accounting itself, see Claude observability and token accounting.

Want per-developer Claude Code spend on top of Bedrock — not one opaque Cost Explorer line?

TrueFoundry AI Gateway

Cost control at the gateway, on top of Bedrock

Routing Bedrock-backed Claude Code through the TrueFoundry AI Gateway keeps inference in your AWS account while adding the layer Bedrock does not give you:

• Per-developer attribution — every request resolves to a person, so spend reports and rate limits mean something, as in cost tracking for Claude Code.
• Model policy — cap which Bedrock models a developer can reach, reinforcing the IAM ARN list from the application side so the two layers back each other up.
• Spend limits that apply per developer or team and hold without their cooperation — a hard stop, not a dashboard warning.
• One cost view across Bedrock, other providers, and other coding tools — one dashboard instead of four.

The gateway sits in the request path, so overhead is a fair question: in practice it adds single-digit-millisecond latency per call and speaks OpenTelemetry, feeding the traces your platform team already watches. Because Claude Code reaches it through an endpoint override, pointing a fleet at the gateway is a configuration change, not a rewrite. For the governance side — usage policy, approvals and audit — see Claude Code governance with an AI gateway.

A worked example

Fifty engineers, Claude Code on Bedrock in eu-west-1, data required to stay in-region. The platform team ships an IAM policy that allows InvokeModel only on Sonnet 5.5 and Haiku 5.5 ARNs, so Opus is simply unreachable. They point Claude Code at the gateway, which forwards to Bedrock under the same account, and set a per-developer monthly spend limit. Two weeks in, Cost Explorer shows one Bedrock number — but the gateway dashboard shows that number split by developer and model, and flags the three engineers driving half the spend. Same inference, same account; the difference is attribution.

The honest limit: the gateway governs model choice, attribution and spend. It does not change Bedrock's per-token rates — see AWS Bedrock pricing explained — it just makes sure you can see and shape where those rates are paid. If the number itself is the surprise, the lever is routing cheaper tiers and caching more, not the gateway.

Gotchas worth knowing

• Anthropic's analytics do not cover Bedrock. If an exec asks for per-developer Claude Code spend and you are on Bedrock, the native dashboards will not have it — plan for OpenTelemetry or a gateway from day one.
• Cache lifetime is shorter off-subscription. Prompt-cache TTL is about five minutes on Bedrock and the API, versus one hour on a subscription, so cold-cache re-reads cost more often — keep sessions focused. Bedrock can be asked for a one-hour TTL, but it bills at a higher rate, so treat it as a deliberate choice, not a default.
• Wildcard IAM defeats the point. bedrock:* or an open ARN list turns your model policy into a suggestion. Pin the ARNs.
• Region and model availability vary. A model ID valid in one region may not exist in another; confirm availability in the region you pin before a fleet rollout, and expect to use inference-profile IDs rather than bare model IDs for current tiers.
• A few features differ on Bedrock. The built-in web-search tool is not available through Bedrock, and /logout is gone because auth is handled by AWS credentials — minor, but worth knowing before someone files it as a bug.
• Credentials still need hygiene. Short-lived SSO sessions are the goal; long-lived access keys in a shell profile reintroduce the very problem Bedrock's IAM model avoids.

Troubleshooting Claude Code on Bedrock

Most Bedrock rollout failures fall into a handful of buckets, and nearly all of them are a region, model-ID or IAM mismatch rather than anything in Claude Code itself.

The pattern across the table: pin explicit model and region values, scope IAM to exactly those ARNs, and make sure anything between Claude Code and Bedrock passes the response through untouched. Get those three right and most "it won't connect" tickets never get filed.

Related reading

• Cost Tracking Claude Code with the TrueFoundry AI Gateway — per-developer attribution in practice
• Centralising Cost Control for AI Coding IDEs — one cost view across tools and providers
• Claude Code Pricing Explained — plans, token costs and how to cut spend
• AWS Bedrock Pricing Explained — what Bedrock inference actually costs
• Our Honest Review of Amazon Bedrock — the platform's strengths and rough edges

Conclusion

Running Claude Code with Amazon Bedrock is the easy part: three environment variables and your existing AWS credentials. The half that decides whether it is actually governed is underneath — an IAM policy scoped to approved model ARNs, the right region and inference-profile IDs pinned, and a plan for the per-developer visibility that Bedrock, by design, does not provide. Those are configuration choices, each with a command you can run to check them.

Keep inference in your account with Bedrock; add attribution, model policy and spend limits with a gateway on top. That is the difference between a Bedrock line item you cannot explain and a Claude Code fleet you can actually account for.

Put Bedrock-backed Claude Code behind one control plane.

Book a demo