What to Know Before Running Claude Code and Cowork on Amazon Bedrock

Running Claude Code and Cowork through Amazon Bedrock gives your organization data sovereignty, AWS compliance coverage, and consolidated billing. But there are operational details that can trip you up if you're not prepared. This post covers what matters: pricing, quotas, identity, team distribution, feature parity, and the setup decisions you'll need to make.

Sam Burton

Published Jun 24, 2026

Last modified Jul 9, 2026

Claude Code and Cowork are available on Amazon Bedrock as third-party inference today. Your developers get the same AI coding and research tools, but inference runs inside your AWS security boundary, bills through your existing account, and counts toward your EDP commitment. The migration is straightforward, but there are details worth understanding before your team starts. This is the guide I wish existed when we started deploying this at scale.

Many of the setup recommendations covered in this post are available 'out-of-the-box' at Guidance for Claude Code with Amazon Bedrock in the AWS Solutions Library Github.

7/9/26 Update: Some sections now reference the recently released Claude apps gateway for Claude Code integrations with Bedrock.

Pricing

Same Models, Same Rates, Different Billing

Per-token pricing is identical whether you use Bedrock, Claude Platform on AWS, or Anthropic direct:

Model	Input (per MTok)	Output (per MTok)
Claude Sonnet 4.6	$3	$15
Claude Opus 4.8	$5	$25
Claude Haiku 4.5	$1	$5
Claude Fable 5	$10	$50

On Bedrock, you pay per token only. No seat fee, no minimums. All spend counts toward your EDP/PPA commitment.

If your team is currently on Claude Enterprise ($20/seat/month + per-token usage), Bedrock eliminates the seat fee entirely while giving you the same per-token rates plus compliance controls.

If your team is on Claude Teams, the seat fee includes usage within weekly limits. Whether Bedrock is cheaper depends on whether your developers regularly hit those limits.

One thing to account for that most people miss: prompt caching creates four distinct token line items. Claude Code uses prompt caching heavily. When estimating costs from invocation logs, you need all four types:

Input tokens (standard rate)
Output tokens (standard rate)
Cache read tokens (up to 90% discount)
Cache write tokens (slightly higher than standard)

If you only count input + output, your cost estimates will be significantly wrong. In practice, including cache tokens can increase estimates by 5-7x compared to naive input/output-only counting.

The 5x Quota Burndown: Request Increases Before You Start

This is the most common first-day problem. Claude 4 models on Bedrock consume output tokens at 5x against your per-minute quota. This is a throttling concern, not a billing concern (you still pay for actual tokens only), but it means default quotas are far too low for interactive use.

What this looks like in practice:

Default Opus 4.8 output TPM quota: 25,000 tokens/minute
Effective actual output: 5,000 tokens/minute (25,000 / 5)
A single Claude Code response generating 2,000 output tokens burns 10,000 from your quota
Result: a single developer hits throttling within seconds on Opus with default quotas

What to do:

Request a quota increase via the AWS Service Quotas console before your team starts. Include "Claude Code for N developers, interactive coding use" in your justification.
Set CLAUDE_CODE_MAX_OUTPUT_TOKENS=4096 in your settings to cap per-request consumption.
Enable Haiku in model access. Claude Code uses it for background tasks internally.
Consider starting with Sonnet (2x the effective quota of Opus) for initial rollout.

Quota increases typically take hours to a few days depending on size and region.

Cross-Region Inference: Better Availability, No Extra Cost

Instead of hitting a single region, you can distribute requests across all US regions (or EU, or global) by using a model ID prefix:

Prefix	Routes across	Data stays within
`us.`	All US regions	United States
`eu.`	All EU regions	European Union
`global.`	All commercial regions	Worldwide
(no prefix)	Single region only	Your configured region

How to configure in Claude Code (edit ~/.claude/settings.json):

1
2
3
4
5
6
7
8
9
{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "us.anthropic.claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "us.anthropic.claude-opus-4-8",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "us.anthropic.claude-haiku-4-5-20251001-v1:0"
  }
}

For Cowork, set the model IDs in the 3P inference configuration screen.

Cross-region inference gives you higher effective quotas and failover if a single region has availability issues. There is no additional charge.

Important: Model pins must be set in settings.json, not exported as shell environment variables. Shell exports don't persist correctly for this configuration.

Per-User Usage Limits: What's Available Today

Bedrock has no native per-user budget cap like Anthropic's admin console. If this is a requirement, here are your options:

[UPDATE] Option 0 (Recommended): Claude Apps Gateway

The Claude apps gateway is Anthropic's official, self-hosted gateway built directly into the claude binary. It sits between your developers and Bedrock, handling auth, spend enforcement, model access, settings distribution, and telemetry in one component.

What it gives you for usage limits:

Native per-user and per-group spend limits enforced server-side at the gateway layer
Developers authenticate via corporate SSO (OIDC). No API keys or AWS credentials on developer machines.
Deprovisioning happens in your IdP and propagates within the session TTL (default 1 hour)
No custom Lambda, DynamoDB, or CloudWatch pipeline required

Prerequisites:

Claude Code v2.1.195 or later (both server and clients)
An OIDC-compliant identity provider (Okta, Microsoft Entra, Google Workspace, Keycloak, PingFederate)
PostgreSQL 14 or later (smallest managed tier is fine)
Linux server on a private network (hostname must resolve to private IPs only)
HTTPS termination (TLS cert or TLS-terminating ingress)

Limitations to be aware of:

Server-side web search is disabled through the gateway (use MCP-based web search instead)
Extended prompt cache TTL (1 hour) is not available; cache TTL is 5 minutes
No CI/unattended auth (the device flow always requires a browser, so CI jobs should go direct to Bedrock)
OIDC only (no SAML/LDAP natively; you need an OIDC bridge if your IdP only speaks SAML)
Single OIDC issuer per gateway instance (run multiple for multi-tenant)
No admin UI; configuration is YAML, changes require redeployment
Does not work for Claude Desktop

For teams that cannot deploy the gateway, three fallback options remain:

Option 1: AWS Guidance CDK Solution (Credential-Gating)

The Guidance for Claude Code with Amazon Bedrock is purpose-built for this problem. It enforces quotas at credential issuance time: when a user is over budget, they're denied new AWS credentials rather than having individual API calls blocked.

Supports daily + monthly limits with 80%/90% warning thresholds
Tunable enforcement interval (every request to every 60 minutes)
Provides clear user-facing notifications when quota is exceeded
Deployable via CDK in hours

Critical limitation: Quota enforcement currently requires OIDC mode (direct IdP federation). It is not yet available for IAM Identity Center's built-in directory. If your organization uses IdC without an external OIDC IdP, this approach is not available today (the IdC branch is in development).

Option 2: Log-Based Monitoring + IAM Revocation

This is what most teams actually build when they can't use the CDK guidance. Claude Code talks directly to Bedrock with no proxy. A control plane reads Model Invocation Logs from CloudWatch, tracks per-user token usage, and revokes Bedrock access when thresholds are crossed.

Works with any auth mechanism (IdC, OIDC, API keys)
No proxy in the call path, nothing on developer machines changes
Enforcement latency: 1-15 minutes depending on your polling interval
User experience when capped: Claude Code fails with auth errors (no graceful notification)

Option 3: Inline Gateway

Route all Bedrock requests through a gateway that checks budgets before forwarding. Real-time enforcement, but requires CLAUDE_CODE_SKIP_BEDROCK_AUTH=1 because Claude Code signs requests with SigV4 against the Bedrock hostname. Your gateway must re-sign requests to Bedrock with its own credentials.

More complex to build and maintain. Most teams reject putting a proxy in the inference path.

[UPDATE] Accelerating Enforcement with OpenTelemetry Metrics

If you set up the CloudWatch + OpenTelemetry monitoring described later in this post , you can use those metrics as a faster data source for enforcement. OTel metrics arrive in CloudWatch in near-real-time from the client side, whereas Model Invocation Logs have ingestion latency. Set a CloudWatch alarm on the per-user token metric (using PromQL with the user.id label), and when the threshold is breached, trigger a Lambda that revokes access via IAM Deny or IdC permission removal. This gives you enforcement in 1-2 minutes instead of the 5-15 minute lag of log-based approaches, without requiring a proxy in the inference path.

If you are using the Claude apps gateway, this workaround is unnecessary. The gateway handles spend limits natively.

Identity: Which IdPs Work

For Claude Code on Bedrock:

Auth method	Setup complexity	Quota enforcement available
IAM Identity Center (SSO)	Low	Not yet (IdC branch pending)
OIDC federation (Okta, Entra, Cognito) via CDK Guidance	Medium	Yes
Bedrock API keys	Lowest	No
AWS access keys	Low	No

For Cowork on Bedrock 3P:

Auth method	How
Named AWS profile	SSO login, reference profile name in Cowork config
Bedrock API key	Paste key in Cowork's 3P config screen
In-app AWS sign-in	Cowork walks through SSO flow
Gateway with OIDC SSO (Entra, Okta)	Cowork authenticates to your IdP, gateway handles Bedrock auth

If you want a single IdP (like Microsoft Entra) working for both tools without a gateway, federate Entra into IAM Identity Center. Both Claude Code (aws sso login) and Cowork ("Sign in with AWS") work natively with IdC.

UPDATE: When using Claude Code, see Claude apps gateway as a recommended method of authenticating.

Distributing Configuration to Teams

You don't need each developer to configure Bedrock manually.

Claude Code

managed-settings.json deployed via MDM to system paths:
- macOS: /Library/Application Support/ClaudeCode/managed-settings.json
- Windows: C:\Program Files\ClaudeCode\managed-settings.json
- Linux: /etc/claude-code/managed-settings.json
managed-mcp.json for forcing specific MCP servers on all users (same paths)

Both take highest precedence and cannot be overridden by users.

Cowork

macOS: Export a .mobileconfig from the Configure 3P Inference screen, deploy via Jamf/MDM
Windows: Export a .reg file, deploy via Intune/Group Policy

The exported config includes provider, region, auth method, and model pins. Users open the app and it just works.

UPDATE: Gateway-Managed Configuration Distribution

If you deploy the Claude apps gateway , most of the MDM-distributed configuration described above is handled server-side instead.

Restoring Feature Parity via MCP

Bedrock doesn't include some cloud-hosted features that exist on Anthropic's platform (web search, Claude Skills, Managed Agents). The core Claude Code functionality (local tools, bash, editor, hooks, subagents, plan mode, extended thinking) works identically.

Features that need restoration and how:

Feature	MCP Server	Setup time
Web search	AgentCore Web Search (AWS native)	15 min
Web search (alternative)	Brave Search MCP	2 min
Web page reading	Fetch MCP (`@modelcontextprotocol/server-fetch`)	2 min
Knowledge base RAG	`awslabs.bedrock-kb-retrieval-mcp-server`	10 min
GitHub integration	`@modelcontextprotocol/server-github`	5 min
Database access	`@modelcontextprotocol/server-postgres`	10 min

MCP servers run locally on the developer's machine as subprocesses. Claude Code/Cowork spawns the process, communicates over stdin/stdout, and kills it when the session ends. No hosting, no infrastructure.

AWS Web Search via AgentCore: The First-Party Option

As of June 17, 2026, AWS provides a fully managed web search connector through Bedrock AgentCore. It uses Amazon's own web index (the same infrastructure behind Alexa+, Amazon Quick, and Kiro).

Why this over Brave Search:

Queries never leave your AWS environment (zero data egress)
No third-party API key needed
No per-query cost beyond standard Gateway data transfer
Same quality as Amazon's consumer search products

Setup:

Create an AgentCore Gateway in us-east-1 with Web Search as the pre-configured target
Register with Claude Code:```bash
claude mcp add --scope user agentcore-web-search --
uvx mcp-proxy-for-aws@1.6.1
https://YOUR-GATEWAY-ID.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp
--service bedrock-agentcore
--region us-east-1``````````````````
Verify with /mcp in Claude Code

The Gateway can also serve as a centralized MCP hub. You can register multiple MCP servers (web search, Slack, internal tools) behind a single Gateway endpoint with centralized auth, audit logging, and policy control, then distribute one URL to your entire team instead of configuring N separate MCP servers per machine.

Monitoring: Per-Developer Usage Analytics with CloudWatch and OpenTelemetry

Claude Code emits OpenTelemetry metrics natively. As of June 2026, you can ship these directly to CloudWatch using bearer token authentication. No collectors, no sidecars, no IAM credential wiring on developer machines.

What you get:

Per-developer token consumption and estimated cost
Breakdown by model (Sonnet, Opus, Haiku) and token type (input, output, cache read, cache write)
Team and department level aggregation for chargeback
Session counts, cache hit rates, and API error tracking
PromQL-based alerting (spend spikes, runaway sessions, quota exhaustion)

How it works:

Create a CloudWatch metrics API key (bearer token) in the CloudWatch console under Settings > API Keys. This creates an IAM user scoped to CloudWatchAPIKeyAccess on your behalf.
Set environment variables for each developer (or distribute via managed-settings.json):

1
2
3
4
5
6
CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_METRICS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=http/json
OTEL_EXPORTER_OTLP_ENDPOINT=https://monitoring.<REGION>.amazonaws.com
OTEL_RESOURCE_ATTRIBUTES=user.id=jdoe,team.id=platform-eng,cost_center=CC-4200
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer <YOUR_TOKEN>

Deploy the pre-built dashboard:

1
2
3
4
5
6
7
curl -o claude-code-dashboard.json \
  https://raw.githubusercontent.com/aws-observability/aws-observability-accelerator/main/artifacts/cloudwatch-dashboards/claude-code/claude-code.json

aws cloudwatch put-dashboard \
  --dashboard-name claude-code-usage \
  --dashboard-body file://claude-code-dashboard.json \
  --region <REGION>

Token granularity options:

One token per developer: Attribution is inherent to the token. Cleanest offboarding (revoke one IAM user).
One token per team: Shared token, attribution via OTEL_RESOURCE_ATTRIBUTES. Less key management.
One token per org: Simplest to start. Split later as your security posture demands.

All three produce identical dashboards because attribution is driven by resource attributes, not the token itself. Start with a single shared token to validate the pipeline, then split as needed.

Metrics go directly from developer laptops to CloudWatch over HTTPS. No collector infrastructure required. Works regardless of which inference provider Claude Code is pointed at.

Reference: Analyzing Claude Code usage with CloudWatch and OpenTelemetry

UPDATE: Simplified Telemetry with Claude Apps Gateway

If you deploy the Claude apps gateway with Claude Code, the per-developer OTel configuration described above is unnecessary and can be obtained with the gateway implementation.

What You Won't Get on Bedrock (Today)

A few capabilities are only available through Anthropic's hosted platform:

Claude Design (visual canvas for prototypes and mockups)
Claude Skills (cloud-hosted, admin-console-managed) -- local SKILL.md files work as an equivalent
Managed Agents (cloud-hosted autonomous agents) -- Bedrock Agents available for API workloads
Fast Mode (lower-latency streaming)
Same-day new features -- Bedrock typically gets new capabilities within days to weeks of Anthropic's release (though Fable 5 launched same-day)

For most development workflows, these gaps have minimal day-to-day impact. The local Claude Code experience (tools, MCP, subagents, hooks, extended thinking) is identical on Bedrock.

Getting Started: The Sequence That Works

Request quota increases (do this days ahead, not day-of)
Enable model access in Bedrock console (Sonnet + Haiku + Opus)
Set up identity (IdC with your IdP federated in is the simplest path for both tools)
Configure Claude Code (interactive wizard or settings.json with cross-region model IDs)
Configure Cowork (Developer Mode, 3P Inference, Bedrock, or push via MDM)
Add MCP servers (AgentCore Web Search for Claude Code, Knowledge Bases for Cowork)
Pilot with 5-10 developers before broad rollout
Monitor costs via Cost Explorer with IAM Principal Cost Allocation (automatic since April 2026)

Resources

# claude-code # claude-cowork # claude # amazon-bedrock

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

What to Know Before Running Claude Code and Cowork on Amazon Bedrock

Sam Burton

Pricing

The 5x Quota Burndown: Request Increases Before You Start

Cross-Region Inference: Better Availability, No Extra Cost

Per-User Usage Limits: What's Available Today

[UPDATE] Option 0 (Recommended): Claude Apps Gateway

Option 1: AWS Guidance CDK Solution (Credential-Gating)

Option 2: Log-Based Monitoring + IAM Revocation

Option 3: Inline Gateway

Identity: Which IdPs Work

Distributing Configuration to Teams

Claude Code

Cowork

Restoring Feature Parity via MCP

AWS Web Search via AgentCore: The First-Party Option

Monitoring: Per-Developer Usage Analytics with CloudWatch and OpenTelemetry

What You Won't Get on Bedrock (Today)

Getting Started: The Sequence That Works

Resources