There are a few ways to run Claude Code today, and the right choice depends on what matters most to your team. This post covers the trade-offs between Anthropic direct, Amazon Bedrock, and a gateway approach I've been building as an open-source project.
Anthropic vs Bedrock: the real decision
Before getting into gateways, it's worth understanding why teams choose Bedrock over Anthropic's API in the first place, since it's not just about price.
Data sovereignty. With Bedrock, all your data, logs, and metrics live inside your AWS account. You control retention, encryption, and access. Your prompts and responses don't leave your infrastructure boundary. For regulated industries or companies with strict data handling policies, this is often the deciding factor.
Region and routing control. You pick the AWS region. You control which accounts the traffic flows through. If you need inference to stay in eu-west-1 or ap-southeast-2, which is a Bedrock configuration you can self-service.
Existing security controls. If your org already has IAM policies, SCPs, VPC configurations, CloudTrail logging, and governance tooling set up in AWS, Bedrock slots into all of that.
Pricing. Bedrock is fully on-demand. You pay per token with no commitments. Anthropic's enterprise plans recently moved to on-demand token rates too, but on top of a $20/user/month base with a 1-year commitment. For teams that are still evaluating or scaling up, the flexibility of pure on-demand matters.
The trade-off is that Bedrock gives you Claude Code only. You can't use co-work, claude.ai, or other Anthropic products that come bundled with their subscriptions. If your team uses those, Anthropic direct is the way to go.
What Bedrock mode leaves on the table
When Claude Code connects to Bedrock with CLAUDE_CODE_USE_BEDROCK=1, it detects the Bedrock backend and turns off a few features on the client side. Extended thinking, web search, and some tool use capabilities get skipped. This isn't a Bedrock limitation per se. Bedrock supports extended thinking fine. Claude Code just doesn't send those requests when it knows it's on Bedrock.
| Feature | Direct Bedrock | Anthropic API |
|---|---|---|
| Extended thinking | Disabled (client-side) | Enabled |
| Web search | Disabled | Enabled |
| Tool use | Partial | Full |
Extended thinking is probably the biggest loss. It's what lets Claude reason through complex problems, like refactoring across multiple files or debugging something subtle. Without it, you're getting less out of the model than you could be.
Web search matters too. Claude's training data has a cutoff, so for anything recent, a recently updated library, a new error message, having web search available makes a real difference.
The gateway approach
The workaround is to put something in front of Bedrock that speaks the Anthropic Messages API. Claude Code connects to it, behaves as if it's talking to Anthropic directly, and the gateway handles translating requests to Bedrock format.
There are a few options for this. LiteLLM is a popular general-purpose proxy that supports this approach. AWS has also published a guidance solution, though that's more of a reference architecture for deploying Claude Code in an AWS account rather than a gateway.
I've been building another option called Claude Code AWS Gateway (CCAG), purpose-built for this specific use case.
CCAG
CCAG is a self-hosted gateway that sits between Claude Code and Bedrock. It presents as the Anthropic Messages API so Claude Code enables all its features, then translates and forwards everything to Bedrock. It handles the things that trip up generic proxies: model ID mapping with region-aware inference profiles, cache_control field sanitization, beta header filtering, and SSE stream normalization.
It's a single Rust binary (~15 MB) with a Postgres database. MIT licensed, every feature included, no enterprise tier.
The idea is to keep all the benefits of running on Bedrock (data sovereignty, region control, existing AWS security controls, on-demand pricing) while getting closer to the feature set you'd have on Anthropic's API.
Team management
Beyond the feature restoration, CCAG adds a layer for managing Claude Code across a team:
- Budget controls - per-user and per-team spend limits. You can set it to notify, throttle, or hard-block when limits are reached. Alerts go out via webhook, SNS, or EventBridge.
- OIDC SSO - developers log in with your existing IdP (Okta, Entra ID, Google, whatever you use). No AWS credentials to distribute.
- Multi-account/region routing - add Bedrock endpoints across different AWS accounts and regions, then assign them to specific teams. You can isolate workloads by account or country, pool quota to reduce 429 errors, or set up primary/fallback routing.
- Admin portal - built-in dashboard with spend analytics, team management, and a Connect page that generates a one-command setup for developers.
- SCIM 2.0 - auto-provision users and teams from Okta or Entra ID.
Where it goes beyond Bedrock or Anthropic
Some of these features aren't available in either Bedrock direct or Anthropic's enterprise offering. The cross-account/region endpoint routing is a good example: you can create endpoint pools across multiple AWS accounts and regions, then attach specific endpoints to specific teams. If you need your ML research team running in us-west-2 and your platform team isolated in eu-west-1, that's a configuration in the portal. This kind of routing-level team isolation doesn't really exist elsewhere.
The roadmap has more of this kind of thing planned. Web search domain allow/deny lists (so you can restrict which sites Claude can search). Custom guardrails for LLM input/output vetting, to apply company-specific security policies at the gateway layer. The gateway sits in a useful position for controls like these since all traffic flows through it anyway.
Getting started
Docker Compose, about 5 minutes:
git clone https://github.com/antkawam/claude-code-aws-gateway.git
cd claude-code-aws-gateway
cp .env.example .env
# Edit .env: set AWS_REGION and AWS credentials
docker compose up -d
Gateway starts at http://localhost:8080. Log in at /portal with admin/admin.
Connect Claude Code:
# Remove the Bedrock flag if you had it set
unset CLAUDE_CODE_USE_BEDROCK
# Point to the gateway
export ANTHROPIC_BASE_URL=http://localhost:8080
export ANTHROPIC_API_KEY=sk-proxy-your-key-here
For teams, the portal's Connect page generates a one-liner that sets everything up for each developer.
You can also deploy to AWS with the included CDK stack (ECS Fargate + RDS), or run it on any infrastructure that can host a container and a Postgres database.
Being honest about trade-offs
It's a new open-source project. The contributor base is small and there will be bugs. If you need something battle-tested and/or vendor support, the AWS guidance solution or LiteLLM are more established.
It's self-hosted. You're running a container and a database (albeit small). Direct Bedrock has no operational overhead at all.
It's Claude Code only. This isn't a general-purpose LLM proxy. It doesn't support other models or providers. If you need to route OpenAI, Azure, and Anthropic through one proxy, LiteLLM does that.
First-party solutions will keep improving. If Anthropic and AWS close the feature gap in direct Bedrock mode, the core reason for the gateway narrows. The team management and gateway-layer controls have their own value, but the feature restoration is what brings most people here today.
It's community-driven. There's no company behind this, no paid support tier, no SLA. It's an open-source project with the benefits and limitations that come with that. It may never match the overall polish of first-party or well-funded solutions, but it's free, ambitious and you can see exactly what it does.
Top comments (0)