Claude Code AWS Bedrock: Enterprise Setup Guide

Claude Code AWS Bedrock integration lets enterprises run Anthropic’s coding agent through their existing AWS account, with all traffic flowing through AWS infrastructure rather than Anthropic’s public API. The setup hinges on a single environment variable, CLAUDE_CODE_USE_BEDROCK=1, but the surrounding IAM, model-access, and regional considerations are where most teams stumble. This guide walks through a production-grade deployment end to end, including the IAM policies, region strategy, pricing implications, and the enterprise governance benefits that justify the extra setup over direct Anthropic API access.

Claude Code Bedrock: What You’ll Learn

This is a practical claude code bedrock deployment guide for engineers and platform teams who need to run Claude Code inside AWS governance boundaries. You will see the exact environment variables, the minimum IAM policy, region selection guidance, the pricing model differences versus direct Anthropic access, and the enterprise features (CloudTrail logging, SCP guardrails, data residency) that make Bedrock the right choice for regulated industries. By the end you will have a checklist that takes a fresh AWS account from zero to a working Claude Code deployment in under an hour.

We will also address where Bedrock genuinely falls short. Model access provisioning can take hours, not all Claude models are available in every region, and the per-token pricing on Bedrock is slightly higher than going direct. If you want a deeper grounding in Claude Code itself before reading further, the Getting Started with Claude Code guide is the right companion. For AWS-specific context on the broader serverless AI stack, the AWS Serverless Agentic AI guide covers how Bedrock fits alongside Lambda and AgentCore.

Why Run Claude Code Through Bedrock?

The decision to route Claude Code through AWS Bedrock rather than the direct Anthropic API is rarely about raw performance — the underlying Claude models are identical. The real drivers are procurement, governance, and compliance. Most enterprises already have an AWS spend commitment, a master services agreement with AWS, security review processes tuned for AWS services, and CloudTrail logging wired into a SIEM. Routing AI workloads through Bedrock slots Claude Code into that existing scaffolding without asking security or finance teams to evaluate a new vendor.

The most concrete benefit is consolidated billing. An enterprise with a $5 million annual AWS commit can apply that commit to Bedrock usage, effectively pre-paying for Claude Code tokens at negotiated rates. Going direct to Anthropic would require a separate contract, separate invoicing, and a separate budget line. For organizations above a few hundred developers, the procurement simplicity alone often justifies the switch.

Data residency is the second driver. Bedrock lets you pin inference to a specific AWS region, which matters for GDPR, HIPAA, and sector-specific regulations that require data to stay within a jurisdiction. Anthropic’s direct API runs in us-east-1 and a small number of regions, with limited control over where a given request lands. Bedrock gives you explicit region selection, and AWS continues to expand Claude model availability across regions.

The third driver is governance depth. AWS service control policies (SCPs) can restrict which AWS accounts, IAM principals, or regions may invoke Bedrock. Combined with IAM condition keys, you can build guardrails like “Claude Code may only run in the sandbox organizational unit” or “Bedrock invocations require a hardware MFA.” These are controls that simply do not exist on the direct Anthropic API.

The fourth, less-discussed benefit is auditability. Every Bedrock API call appears in CloudTrail with the caller’s IAM principal, source IP, region, and model ID. For regulated industries that must demonstrate who ran which AI workload when, this is table stakes. The direct Anthropic API offers usage dashboards but nothing equivalent to CloudTrail’s append-only, cryptographically verifiable log.

The Core Environment Variable

Activating Bedrock mode in Claude Code is a single environment variable. Everything else is AWS-side configuration. The variable tells Claude Code to use the AWS SDK for inference calls instead of the Anthropic SDK, which means credentials, region, and IAM resolution all flow through the standard AWS credential chain.

# Enable Bedrock mode
export CLAUDE_CODE_USE_BEDROCK=1

# Specify the AWS region (must have Claude model access)
export AWS_REGION=us-east-1

# Optional: pin a specific Claude model
export ANTHROPIC_MODEL=us.anthropic.claude-sonnet-4-6-20250610-v1:0

# Optional: use a named AWS profile
export AWS_PROFILE=claude-code-prod

The CLAUDE_CODE_USE_BEDROCK=1 flag is the on switch. Without it, Claude Code calls api.anthropic.com directly, which requires an ANTHROPIC_API_KEY environment variable instead. The two modes are mutually exclusive: pick one, configure its prerequisites, and do not mix credentials from both.

The model ID format differs between direct Anthropic and Bedrock. Direct uses identifiers like claude-sonnet-4-6, while Bedrock uses inference profile IDs like us.anthropic.claude-sonnet-4-6-20250610-v1:0. The us. prefix denotes a cross-region inference profile that AWS routes intelligently across regions within the US for resilience. Without the prefix, the model ID targets a single region only.

Region selection matters because not every AWS region has every Claude model. As of mid-2026, Claude Sonnet 4.6 is available in us-east-1, us-west-2, eu-west-1, eu-central-1, ap-northeast-1, and a handful of others. Claude Opus 4.8 has narrower availability. Always check the Bedrock model catalog in your target region before committing to a region for production.

IAM Permissions: The Minimum Viable Policy

Claude Code needs two Bedrock permissions: invoke the model, and (if you use cross-region inference profiles) invoke against the inference profile ARN. The minimum IAM policy below covers both. Attach it to the IAM user or role that Claude Code runs as.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeClaudeModels",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-*",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-*",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-*"
      ]
    },
    {
      "Sid": "UseCrossRegionInferenceProfiles",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1:*:inference-profile/us.anthropic.claude-*"
      ]
    },
    {
      "Sid": "ListFoundationModels",
      "Effect": "Allow",
      "Action": "bedrock:ListFoundationModels",
      "Resource": "*"
    }
  ]
}

The wildcards (anthropic.claude-sonnet-*) let the policy cover new model versions without requiring an IAM edit each time Anthropic ships a refresh. If your security team prefers explicit version pinning, replace the wildcards with the exact model IDs you intend to use. The trade-off is operational: every model upgrade becomes a ticket.

The InvokeModelWithResponseStream permission is required for streaming responses, which Claude Code uses for interactive sessions. Without it, Claude Code falls back to one-shot invocation, which works but feels sluggish on long responses.

The ListFoundationModels permission is technically optional but useful. Claude Code calls it during startup to validate that the configured model exists in the configured region, producing a helpful error if the model is unavailable. Grant it to make failure modes debuggable.

Never grant bedrock:* or wildcard resource permissions to a Claude Code IAM principal. Bedrock also hosts non-Anthropic models, third-party marketplace models, and provisioned throughput resources that have cost and security implications. Scope the policy to the Anthropic foundation model ARNs only.

Model Access: The Hidden Gotcha

The single most common Bedrock deployment failure is not IAM, networking, or credentials — it is model access. New AWS accounts do not have Claude models enabled by default. You must explicitly request access to each model in each region you intend to use, and the request can take anywhere from a few minutes to several hours to be approved. Plan for this delay before scheduling a rollout.

To request model access, navigate to the Bedrock console in your target region, open the Model access page, select the Anthropic models you need, accept the end-user license agreement, and submit. Most accounts get auto-approved within minutes, but brand-new accounts or accounts in sensitive industries may undergo manual review. Status appears in the console as “Access granted” or “In progress.”

Enterprise accounts with an active AWS Connect or Enterprise Support plan can open a support case to expedite access if the auto-approval stalls. Quote your account ID, the region, and the specific model IDs requested. Support engineers can usually push a stalled approval through within a business day.

Always request access to all three Claude tiers you might use — Haiku for low-latency, Sonnet for general work, Opus for heavy reasoning — even if you only intend to use Sonnet today. Switching models later requires another access request, and you do not want a model upgrade blocked by a multi-hour provisioning delay.

Cross-Region Inference Profiles

Cross-region inference profiles are the AWS-recommended way to run Claude on Bedrock in production. A profile like us.anthropic.claude-sonnet-4-6-20250610-v1:0 looks like a single model ID from your code, but behind the scenes AWS routes each invocation across multiple US regions to maximize availability and absorb traffic spikes. The pricing is identical to single-region invocation, and you gain resilience for free.

Without a cross-region profile, a regional Bedrock outage takes Claude Code down for the duration. With a profile, AWS transparently fails over to another region in the profile’s footprint. For any production deployment, prefer the us., eu., or apac. prefixed inference profile IDs.

The trade-off is data residency. A us. profile guarantees data stays within the United States but does not pin to a single state. A eu. profile stays within the EU but may move between Ireland, Frankfurt, and Paris. If your regulator requires a single-country residency (Germany-only, for example), you cannot use a cross-region profile and must invoke the foundation model directly in eu-central-1.

For most enterprises, the cross-region profile is the right default. The resilience gain outweighs the minor residency trade-off, and the pricing is identical. Reserve direct single-region invocation for the regulated workloads that genuinely require it.

Pricing: Bedrock Versus Direct Anthropic

Bedrock pricing for Claude models is per-token, denominated in USD, and billed through your standard AWS invoice. The per-token rates are set by Anthropic and AWS jointly, and as of mid-2026 they run approximately 2-3% higher than the equivalent direct Anthropic API rates. This premium funds the AWS infrastructure layer — CloudTrail logging, IAM integration, regional isolation, and the operational burden of running inference inside AWS boundaries.

The token rates themselves are now typically identical between direct and Bedrock — AWS and Anthropic aligned pricing in early 2026 to remove friction. The real cost difference comes from negotiated discounts. Enterprises with AWS Edison or Franklin discount programs can apply negotiated Bedrock discounts that beat Anthropic’s published rates, especially for high-volume commitments above $100K per year in inference spend.

Cache tokens are billed at the same discount as non-cache tokens on Bedrock, which is significant because Claude Code’s prompt caching can cut effective input token costs by 90% on repeat-heavy sessions. If your team runs Claude Code heavily against a single codebase, prompt caching combined with a Bedrock discount can produce real per-developer costs well below the headline token rates.

Beyond token costs, factor in data transfer. Bedrock inference within an AWS region is free of cross-region data transfer fees. If your developers run Claude Code from on-premises or non-AWS cloud environments, standard AWS data transfer rates apply to the API traffic. For a 200-engineer team, this is usually negligible but worth noting in the cost model.

Token Economics and Cost Optimization

The headline token rate is the ceiling, not the floor, of what Claude Code on Bedrock actually costs per session. Three levers drive effective cost well below the published rates: prompt caching, model routing, and context-window discipline. Treating them as deployment concerns rather than developer tricks is the difference between a Claude Code rollout that costs $4 per developer-hour and one that costs $40.

Prompt caching is the biggest lever, and it works identically on Bedrock and direct Anthropic. When Claude Code re-uses parts of a prompt across turns (which it almost always does, since the system prompt and CLAUDE.md are constant within a session), the cached tokens are billed at roughly 10% of the normal input rate. For long sessions against a stable codebase, prompt caching routinely cuts effective input costs by 80-90%. Bedrock reports cache hits via the response metadata, so you can verify caching is actually happening rather than assuming.

To maximize cache hits, ensure your CLAUDE.md and project context are stable across sessions, avoid unnecessary restarts that invalidate the cache, and structure your prompts so the variable portions come at the end. Claude Code does most of this automatically, but a CLAUDE.md that changes frequently (because it includes dynamic timestamps, build IDs, or other churn) defeats caching. Treat CLAUDE.md as a stable contract, not a living document.

Model routing is the second lever. Claude Code lets you pin different models for different task types: Haiku for lightweight lookups, Sonnet for general work, Opus for heavy reasoning. The cost differential is dramatic — Haiku input is $0.80 per million tokens versus Opus at $15. A team that runs every task on Opus when Sonnet would do spends 5x more than necessary, and a team that runs quick file edits on Opus when Haiku suffices spends 20x more.

The default Claude Code model selection is usually correct, but review your team’s actual model mix via Bedrock request metrics after 30 days of usage. If you see Opus dominating, that often indicates either a CLAUDE.md that lacks the structure Sonnet needs to perform well, or a workflow where developers have manually overridden the default to Opus because they prefer its quality. The latter is fine if intentional; the former is a fixable configuration issue.

Context-window discipline is the third lever, and it is the one most under developer control. A Claude Code session that loads the entire monorepo into context will consume tokens aggressively even with caching, because any change to the active file set invalidates the relevant cache entries. Train developers to scope their sessions tightly: start Claude Code from the subdirectory they are working in, use subagents for cross-cutting investigations, and clear context between unrelated tasks. The Token Management and Costs guide covers these patterns in depth.

For CI-based headless runs, set a hard per-pipeline budget using --max-budget-usd. A reasonable default is $5 per pipeline for routine tasks like code review or test generation, with a higher limit for deliberate refactoring jobs. Without a budget cap, a runaway agent loop in CI can run up hundreds of dollars in a single failed pipeline, which is the most common cost-overrun story we hear from teams early in their adoption.

Finally, build a cost dashboard in CloudWatch or your existing observability stack that breaks down Bedrock spend by IAM principal, model, and region. Visibility drives accountability: when individual teams can see their own spend, they self-correct usage patterns that no central mandate could enforce. Tag Bedrock invocations with cost allocation tags tied to team or project for finer-grained attribution.

Authentication and Credential Chain

Claude Code on Bedrock uses the standard AWS SDK credential chain. This means it works with environment variables, shared credentials files, IAM roles attached to EC2 instances, IAM roles for service accounts in EKS, SSO, and every other standard AWS authentication mechanism. Pick the mechanism that matches your deployment model and do not invent custom credential handling.

For developer workstations, AWS SSO is the recommended pattern. Developers run aws sso login --profile claude-code-prod once per day, and Claude Code picks up the short-lived credentials from the shared credentials file. No long-lived access keys to leak, and access revocation is a single SSO disablement rather than a key rotation exercise.

For CI/CD pipelines, use an IAM role assumed via OIDC. GitHub Actions, GitLab CI, and Jenkins all support OIDC federation with AWS, which lets the pipeline assume a role with the Claude Code IAM policy attached without any static credentials stored in secrets. This is the same pattern you should already be using for AWS deployments in general.

For EC2 or ECS deployments, attach an IAM role to the instance or task. Claude Code automatically uses the instance metadata service to retrieve credentials. Never bake access keys into AMIs or container images — this is a basic AWS hygiene rule that applies equally to Claude Code.

# Example: ~/.aws/config with SSO profile
[profile claude-code-prod]
sso_start_url = https://myorg.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789012
sso_role_name = ClaudeCodeAccess
region = us-east-1
output = json

# Then in shell
export AWS_PROFILE=claude-code-prod
export CLAUDE_CODE_USE_BEDROCK=1
aws sso login --profile claude-code-prod
claude

For environments where you must use long-lived access keys (legacy CI systems, air-gapped networks with credential proxies), scope the key’s IAM user to the minimum policy above, rotate the key quarterly via IAM credential rotation, and alert on any use outside expected source IPs through CloudTrail and GuardDuty. Long-lived keys are a persistent security debt, and any Claude Code credential leak grants the holder the ability to run inference billed to your account until the key is rotated. Treat key rotation as a scheduled operational task, not an ad-hoc emergency response. Automated rotation via AWS Secrets Manager plus a Lambda rotator function eliminates the human-error gap that manual rotation always produces.

Enterprise Governance: SCPs and Guardrails

AWS Organizations service control policies (SCPs) are the right tool for governing Claude Code access across an enterprise. SCPs let you restrict which AWS accounts may invoke Bedrock at all, which regions are permitted, and which model ARNs are allowed. The example below shows a typical SCP that permits Bedrock use only in approved accounts, only in us-east-1 and eu-west-1, and only for Anthropic models.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
        }
      }
    },
    {
      "Sid": "DenyNonAnthropicBedrockModels",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "arn:aws:bedrock:*:*:foundation-model/*",
      "Condition": {
        "StringNotLike": {
          "bedrock:FoundationModelArn": "arn:aws:bedrock:*:*:foundation-model/anthropic.claude-*"
        }
      }
    }
  ]
}

The first statement enforces region pinning, which is essential for data residency commitments. The second statement prevents developers from invoking non-Anthropic Bedrock models (Meta Llama, Mistral, AI21, Amazon Nova) using their Claude Code credentials, even if those models are technically accessible. This keeps the blast radius of a Claude Code credential leak limited to Anthropic models only.

Combined with IAM permission boundaries, you can build layered controls: an SCP governs the organization, a permission boundary governs what IAM roles developers can create, and an inline IAM policy governs what Claude Code itself can invoke. This three-layer model matches how mature AWS shops already govern high-risk services like IAM itself or KMS.

CloudTrail and Audit Logging

Every Bedrock invocation appears in CloudTrail as a InvokeModel or InvokeModelWithResponseStream event. The event includes the caller’s IAM principal ARN, source IP, requested model ARN, region, and a unique request ID. For regulated industries, this is the audit trail you need to answer questions like “which developer ran Claude Code against the customer PII codebase last Tuesday.”

The token counts and prompt contents are not in the CloudTrail event by default — AWS deliberately excludes them to keep event sizes manageable. If you need token accounting for cost attribution, use AWS Cost Explorer with the Bedrock service filter, broken down by IAM principal or tag. If you need prompt logging for compliance, configure Bedrock’s model invocation logging feature, which writes request and response payloads to S3 or CloudWatch Logs at additional storage cost.

Model invocation logging is a significant compliance feature but has cost and privacy implications of its own. The logs contain the full prompt text, which may include source code, secrets, or PII if your developers are not careful. Apply S3 lifecycle rules to age out logs on a schedule, restrict log bucket access to the security team only, and enable S3 Object Lock if your regulator requires write-once audit trails.

For SIEM integration, CloudTrail events flow into Splunk, Datadog, Elastic, or whatever log aggregation you already run for AWS. A useful alert to set up: any Bedrock invocation outside business hours from a developer IAM principal, which may indicate credential compromise or unauthorized side-work.

Provisioned Throughput Versus On-Demand

Bedrock offers two pricing models for Claude: on-demand (pay per token) and provisioned throughput (pay for a fixed token rate per hour). On-demand is the default and the right choice for almost all Claude Code workloads. Provisioned throughput makes sense only for very high, very steady volumes where you can predict token usage well in advance.

A typical Claude Code session consumes between 50K and 500K input tokens per hour of active use, depending on context size and codebase complexity. For a 100-developer team using Claude Code intensively, that works out to perhaps 5-50 million tokens per hour. At Sonnet 4.6 rates, that is $15K-150K per hour of inference — a range where provisioned throughput starts to become economical.

Provisioned throughput is purchased in model units, with each unit committing to a specific token-per-minute rate for a minimum commitment term (typically one month). The break-even point depends on your steady-state utilization. If your team uses Claude Code 24/7 with consistent volume, provisioned throughput can cut effective costs by 30-50%. If usage is bursty with idle periods, on-demand remains cheaper.

For most teams, start with on-demand, monitor usage for 60-90 days via Cost Explorer, and only then evaluate provisioned throughput if you can demonstrate consistent utilization above 70%. Premature commitment to provisioned throughput is a common cost-optimization mistake.

Network Configuration and VPC Endpoints

For deployments where Claude Code runs from within a VPC — EC2 instances, ECS tasks, EKS pods, or developer jump hosts in a private subnet — use a VPC endpoint for Bedrock to keep traffic on the AWS network rather than traversing the public internet. VPC endpoints for Bedrock are interface-type endpoints backed by AWS PrivateLink, and they are free to provision (you pay only for the endpoint hours and data processing, both modest for typical Claude Code volumes).

The VPC endpoint policy can further restrict access, for example requiring that invocations come from a specific IAM role or VPC subnet. Combined with SCPs and IAM policies, this gives you three independent layers of control over which network paths may reach Bedrock.

# VPC endpoint policy restricting to a specific role
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "*",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/ClaudeCodeRunnerRole"
      }
    }
  ]
}

DNS resolution for the VPC endpoint is handled automatically by AWS via private hosted zones. No application-side configuration changes are needed beyond setting AWS_REGION and the credential chain. Claude Code uses the standard Bedrock endpoint DNS name, which resolves to the VPC endpoint’s private IP addresses when the endpoint is present in the VPC.

A Worked Example: Enterprise Rollout

Imagine a 300-engineer financial services company rolling out Claude Code via Bedrock. The engineering org has developers across three AWS accounts: a sandbox account for experimentation, a development account for shared workloads, and a production account for customer-facing systems. The security team requires all AI workloads to use Bedrock rather than direct vendor APIs, both for audit and data residency reasons.

The platform team starts by requesting Claude Sonnet 4.6, Haiku 4.5, and Opus 4.8 model access in us-east-1 across all three accounts. While that processes (it took four hours for their account type), they write the IAM policy and SCP described above and validate them against a test IAM user in the sandbox account. They discover that InvokeModelWithResponseStream was missing from the first IAM draft, causing Claude Code sessions to fail with a streaming-not-allowed error; adding it resolves the issue.

For developer authentication, they configure AWS SSO with a dedicated permission set named ClaudeCodeAccess, scoped to the minimum IAM policy. Developers run aws sso login --profile claude-code as part of their morning routine, and the resulting short-lived credentials are valid for eight hours. The platform team documents this in an internal wiki with copy-paste shell snippets.

For CI/CD, they configure GitHub Actions with OIDC federation to assume a role in the development account that has the Claude Code IAM policy attached. Pipelines use CLAUDE_CODE_USE_BEDROCK=1 alongside the standard AWS_WEB_IDENTITY_TOKEN_FILE mechanism, with no static credentials stored anywhere. CI-based Claude Code runs use headless mode with the --max-budget-usd flag to cap per-pipeline spend at $5.

The security team configures Bedrock model invocation logging to a dedicated S3 bucket with a 90-day lifecycle and Object Lock enabled. CloudTrail events flow into their existing Splunk SIEM, with an alert wired for any Bedrock invocation outside the three approved AWS accounts or outside business hours. The data residency story — all inference in us-east-1 — satisfies the company’s US-only data commitment to regulators.

The procurement team applies the company’s existing AWS Edison discount to Bedrock usage, which reduces effective token costs by 18% versus published rates. Combined with prompt caching, the all-in cost per developer-hour of Claude Code usage lands at roughly $4, well within the budget the engineering leadership had approved.

The rollout completes in two weeks from kickoff to general availability. The biggest surprise was the model-access provisioning delay — four hours rather than the console’s “typically minutes” estimate — which they now plan for in advance of any new model rollout.

Claude Code Bedrock: Common Mistakes to Avoid

Bedrock deployments fail in predictable ways. These five mistakes account for the vast majority of support tickets we see from teams adopting Claude Code on Bedrock.

• Skipping model access request: A fresh AWS account cannot invoke Claude models until access is explicitly requested and approved in the Bedrock console. This approval can take hours. Always request access to all three Claude tiers in every region you might use, before you need them.
• Using the wrong model ID format: Direct Anthropic uses claude-sonnet-4-6. Bedrock uses us.anthropic.claude-sonnet-4-6-20250610-v1:0 (cross-region) or anthropic.claude-sonnet-4-6-20250610-v1:0 (single-region). Mixing them produces cryptic “model not found” errors. Check the Bedrock console for the exact model ID in your region.
• Missing InvokeModelWithResponseStream: Streaming responses require this separate permission. Without it, Claude Code falls back to one-shot mode or fails outright. Always include both InvokeModel and InvokeModelWithResponseStream in the IAM policy.
• Wildcard IAM resources: Granting Resource: "*" on Bedrock invoke permissions lets the principal invoke any Bedrock model, including non-Anthropic ones, marketplace models, and any new models AWS adds later. Scope to anthropic.claude-* ARNs to keep the blast radius predictable.
• Forgetting region pinning: Without an SCP enforcing region, developers can (and will) invoke Bedrock from any region their IAM principal allows, breaking data residency commitments. Pin regions explicitly at the SCP layer, not just in developer documentation.
• Ignoring prompt caching cost savings: Claude Code’s prompt caching can reduce effective input token costs by up to 90% on repeat-heavy sessions. Cache token billing is identical on Bedrock and direct, so the savings are real either way, but you must verify caching is actually happening via Bedrock’s request metrics.

Claude Code Bedrock: Best Practices

• Use AWS SSO for developer authentication rather than long-lived access keys. Short-lived credentials limit blast radius if a developer laptop is compromised, and SSO integration with your identity provider gives you centralized access revocation.
• Always use cross-region inference profiles (us., eu., apac. prefixed model IDs) for production. The resilience gain is free, and the alternative — single-region invocation — means any regional Bedrock outage takes Claude Code down.
• Scope IAM resources to anthropic.claude-* ARNs only. Never grant Resource: "*" on Bedrock invoke permissions. This keeps the blast radius of a credential leak limited to Anthropic models and prevents unexpected cost surprises from non-Anthropic model use.
• Layer your controls: SCP at the organization level, permission boundary on IAM roles developers can create, inline IAM policy on the Claude Code role itself. Three independent layers make accidental over-permissioning much harder.
• Enable Bedrock model invocation logging for any regulated workload, and route the logs to a dedicated S3 bucket with Object Lock and a 90-day lifecycle. The cost is modest and the compliance benefit is significant for audit trails.
• Monitor Bedrock spend via AWS Cost Explorer with daily granularity and alert thresholds. Claude Code’s per-developer cost can swing wildly based on usage patterns, and an unexpected spike usually indicates either a runaway agent or a credential leak.
• Document the exact model IDs in use, including the AWS region, in your internal deployment runbook. Bedrock model IDs include version timestamps that change with each model refresh, and a future upgrade will require updating both the documented IDs and the IAM policy ARN wildcards.

Claude Code Bedrock: Frequently Asked Questions

Is Bedrock pricing higher than direct Anthropic API?

As of early 2026, per-token rates are identical between Bedrock and direct Anthropic for Claude models. The real differentiator is negotiated discounts — AWS Enterprise Discount Programs or Edison commits can beat Anthropic’s published rates, especially above $100K annual inference spend.

Do I need a separate Anthropic account to use Bedrock?

No. Bedrock handles authentication through your standard AWS credential chain. You never interact with api.anthropic.com or hold Anthropic API keys. Billing flows entirely through your AWS invoice, which is the procurement appeal for most enterprises.

Which AWS regions have Claude models?

Claude Sonnet 4.6 is in us-east-1, us-west-2, eu-west-1, eu-central-1, ap-northeast-1, and a few others. Opus 4.8 has narrower availability. Always check the Bedrock console model catalog in your target region before committing, and use cross-region inference profiles for resilience.

Does Bedrock log my prompt contents?

Not by default. CloudTrail events include the caller, model, and request ID but exclude prompt text. Bedrock’s model invocation logging feature writes full request/response payloads to S3 or CloudWatch if you explicitly enable it, which is required for some regulated workloads.

Can I run Claude Code headless in CI via Bedrock?

Yes. Set CLAUDE_CODE_USE_BEDROCK=1 alongside your CI’s standard AWS authentication (OIDC for GitHub Actions, instance roles for EC2 runners). Use headless mode with --max-budget-usd to cap per-pipeline spend and prevent runaway agent loops.

Claude Code AWS Bedrock is the right deployment pattern for enterprises that need to run AI coding workloads inside existing AWS governance. The single environment variable CLAUDE_CODE_USE_BEDROCK=1 switches Claude Code to AWS-native authentication, billing, and logging, while IAM policies, SCPs, and CloudTrail deliver governance controls that the direct Anthropic API cannot match. Plan for model-access provisioning delays, use cross-region inference profiles, scope IAM tightly, and treat Bedrock as a first-class AWS service rather than a vendor API shim.