The same conversation happens in every company that wants Claude Code. An engineer demos it, the room lights up, and then someone from security asks four questions in a row. Where does our code go? Who can reach the model? How do we audit the calls? Whose credit card is this on? Four questions. Four reasons the answer defaults to no.
I run Claude Code every day. Not in a sandbox, in my actual daily work. So when I started reading about the enterprise path, I wasn't asking "is this useful." I already knew. I was asking a narrower question: what changes when the model calls route through AWS Bedrock instead of straight to Anthropic? Because that routing choice is the entire difference between a personal tool and something a security team will sign off on.
Prasad Rao, an AWS Principal Solutions Architect, documented the technical answer back in May 2026, in a LinkedIn write-up that made the rounds. His framing stuck with me because it maps one-to-one onto those four security questions. Bedrock doesn't add features to Claude Code. It answers objections. That's a different thing, and it matters more.
The four no's, and what actually flips them
Let me take the questions in the order security usually asks them, because the order is itself the story. Each one sounds like a wall. Each one has a control your AWS team already runs for a dozen other services.
"Our code can't leave our VPC." This is the first wall and usually the tallest. With Claude Code pointed at the public Anthropic API, requests go out to the internet. Full stop. On Bedrock, inference runs inside your chosen AWS region, and you can add a VPC interface endpoint so the traffic never touches the public internet at all. The data stays where your other regulated workloads already live. Same region, same residency story you already told your auditors.
"We don't know who can reach the model." On the direct API, access is an API key. Keys get shared, keys leak, keys are hard to scope. Bedrock replaces the key with IAM. That means access is a role, not a secret. You grant bedrock:InvokeModel per team, per project, per environment, with the same condition keys and boundaries you use everywhere else. Revoking access becomes a policy change, not a key rotation scramble.
"We have no audit trail." Every inference call through Bedrock lands in CloudTrail. Timestamp, principal, which model, request metadata. Your SIEM already ingests CloudTrail, so the model calls show up next to your S3 reads and your Lambda invocations with no new pipeline to build. The auditor asking "who called Claude at 2am on the payments repo" now has a real answer.
"We can't manage another subscription." This one sounds like procurement whining. It isn't. A separate Anthropic bill means a new vendor, a new card, a new line item outside the AWS budget your finance team already approved. On Bedrock it's pay-as-you-go inside the account you already have. No new contract, no new card, no new vendor review. The spend lands under tags you already track.
That's the flip. Four no's become four yeses, and none of the yeses required anyone to invent a new control. They required moving the same call through a door your security team already trusts.
The routing choice, not the model, is what unblocks the enterprise.
What Bedrock does NOT fix (the honest part)
The announcement posts skip this part. Routing through Bedrock is a trade, and you pay for it.
You pay in tokens, same as anywhere else. Bedrock's per-token pricing for Claude matches the direct Anthropic API dollar for dollar in standard commercial regions, but there's no Claude Pro flat rate hiding on the other side. If you're a solo developer comparing a $20/month Pro plan to metered Bedrock inference, Bedrock will usually lose on raw cost, because a flat rate beats metering for light, steady use. That comparison is real, and if someone tells you Bedrock is free, they're selling.
The point is that the comparison changes shape at the enterprise level. When the alternative to Bedrock isn't "$20 Pro plan" but "we can't use the tool at all because security blocked it," the total cost of ownership math inverts. You're not paying extra for tokens. You're paying for the audit trail, the IAM boundary, and the VPC residency that make the tool legal to run in the first place. That's cheaper than a compliance finding.
You also pay in regions. Not every Claude model lands in every AWS region on day one, and the model identifiers you point Claude Code at are cross-region inference profile IDs, not just model names — us.anthropic.claude-opus-5 in a US region, eu. or apac. elsewhere. If your compliance story requires a specific region, check model availability there first (aws bedrock list-inference-profiles --region your-region answers it in one call). I've watched teams design a whole IAM setup and then discover the model they wanted wasn't in the region they needed.
Latency has a real answer now, and it comes with a fix. I benchmarked Claude Haiku 4.5 and Claude Sonnet 5 on Bedrock against the direct API, same prompt, same account, over 100 calls total. Pointed at us-east-1, Bedrock added roughly a full second on top of Haiku's ~700ms direct-API response. Pointed at sa-east-1 instead, the AWS region closest to South America, that gap cut in half.
Pick the region nearest you, and the routing tax shrinks — or disappears with a bigger model.
| Setup | Bedrock (median) | Direct API (median) | Gap |
|---|---|---|---|
| Haiku 4.5, us-east-1 (n=30) | 1,723 ms | 727 ms | +996 ms |
| Haiku 4.5, sa-east-1 (n=20) | 1,241 ms | 826 ms | +415 ms |
| Sonnet 5, us-east-1 (n=15) | 2,254 ms | 2,353 ms | −99 ms (even) |
I tried closing the sa-east-1 gap further with a custom inference profile pinned to that single region. AWS rejected it: Haiku only ships on Bedrock through the cross-region pool, no way around it for this specific model — aws bedrock create-inference-profile returns ValidationException: The provided foundation model does not support On Demand inference. With Sonnet 5, none of this mattered. Bedrock and the direct API landed within 100ms of each other, dead even.
A small, fast model makes routing overhead visible; a bigger one buries it. AWS gives you one real lever to pull: point your client at the region nearest you, even one that still routes through a global pool. If you're outside the US and picking Bedrock for a latency-sensitive small-model workload, that's the first thing to test, not the last.
The setup, roughly
The seed's raw notes sketch a minimum viable path, and I want to show it while being honest that IAM policies and model IDs drift faster than any blog post can keep up. Treat this as the shape of the work, not a copy-paste script.
# 1. Enable Claude models in the Bedrock console for your region
# (us-east-1 / us-west-2 are common starting points; check model
# availability in YOUR compliance region first)
# 2. Attach an IAM policy. Start least-privilege, not FullAccess.
# You want InvokeModel on the specific model ARNs you approved,
# not a blanket grant. The scoped policy is the whole security story —
# don't undo it with a wildcard.
# 3. Add a VPC interface endpoint for Bedrock so inference traffic
# stays off the public internet. This is what lets you tell the
# auditor "it never leaves the VPC" and mean it.
# 4. Confirm CloudTrail is on for the account. It usually is.
# Now every model call is logged with principal + timestamp.
# 5. Point Claude Code at Bedrock instead of the direct API:
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export ANTHROPIC_MODEL='us.anthropic.claude-opus-5'
# the "us." prefix is a cross-region inference profile — swap for
# eu./apac./global. depending on where you run, or us-gov. in GovCloud
# plus standard AWS credentials (role, SSO, or profile)
Why least-privilege in step 2 and not the managed full-access policy? Because the IAM boundary is the entire reason security said yes. A BedrockFullAccess grant is the fast path in a demo and a finding in an audit. Scope bedrock:InvokeModel to the specific model ARNs you approved and nothing more. The scoped policy is the thing you're actually selling to the security team. Don't hand it back to them broken.
Here's the decision I'd write down as an ADR if I were setting this up for a team:
ADR: Route Claude Code through Bedrock, not the direct Anthropic API
Status: Accepted
Context: Security blocks direct-API tools that egress to the public
internet, use shared API keys, and bill outside AWS.
Decision: Point Claude Code at Bedrock via VPC endpoint + scoped IAM.
Consequences:
(+) IAM access control, CloudTrail audit, in-VPC residency,
unified AWS billing — the four blockers resolved.
(-) No flat-rate plan, pure metered spend from token one;
region-limited model availability; small-model latency tax outside
the US, mitigated by pointing at the nearest AWS region.
Trade accepted because: the alternative is not "cheaper Claude Code,"
it's "no Claude Code."
The stack is actually complete now
The timing is the part I'd underline. AWS MCP Server reached general availability on May 6, 2026, the same month as Rao's write-up. There's no extra charge for the MCP server itself. You pay for the model usage underneath it, same pay-as-you-go meter. That closes the loop: you get Claude Code, sub-agents, and MCP-based tool access, all inside the AWS boundary your security team already governs.
That's why "when do we start" is a fair reaction and not hype. The pieces that were missing six months ago are shipped. What used to be a roadmap reads like a setup guide now.
If you want the concrete on-ramps, Rao points at four, and they're the right four in the right order. Start with the Anthropic Academy course to get the fundamentals of API calls, tool use, RAG, and MCP servers before you touch any AWS config. Then the Claude Code documentation for the Bedrock-specific IAM setup and troubleshooting. Then the AWS Solutions GitHub sample for real auth patterns, deployment, and usage monitoring you can actually run. Then AWS Workshop Studio for hands-on practice with the Bedrock integration, MCP servers, and sub-agent deployment. The catalog itself is open to browse, but plenty of individual workshops need an access code from an AWS event, so check that before you plan your afternoon around one. Fundamentals, then docs, then runnable code, then hands-on. That sequence saves you from configuring things you don't yet understand.
What I'd actually tell a team lead
If you're the person who has to walk into the security review, don't lead with the model. Lead with the controls. The security team doesn't care that Claude Code is good, they care that it's governable. Bedrock lets you answer their four questions with four services they already run.
And keep the trade honest on your side of the table too. You lose the flat-rate plan and pay metered from the first token. You may hit a region limit. If your workload leans on a small, fast model and your users aren't in the US, budget for the routing tax and point your client at the nearest region before you promise a latency number. Say all of that in the review. The credibility you build by naming the downsides is what makes the approval hold up three months later, when finance looks at the bill.
Documentation isn't overhead. It's thinking made visible. Writing that ADR before the meeting is how you turn "we can't" into a decision someone can actually sign.
Pick the depth that fits where you are right now:
Low: Open the Claude Code Bedrock docs and check whether the model you want is available in your compliance region. Five minutes, and it's the fact most likely to sink a setup later.
Medium: Run the AWS Workshop Studio lab or the AWS Solutions GitHub sample in a scratch account. Wire up the scoped IAM policy and watch a real inference call show up in CloudTrail. That single log line is the whole security pitch in one screenshot.
High: Take the four-objection framing into your next architecture review and write the ADR first. Then come back and tell me where it broke. Which of the four no's was hardest to flip at your company? Did the token cost land where you expected? I read every comment, and the wrong turns other people hit are the most useful thing in this whole thread.
Build. Document. Share. Repeat.
Top comments (0)