Claude Code on AWS Bedrock: An Enterprise Architecture Your CFO, CIO, and CISO Will All Sign Off On

Claude Code is a fantastic coding assistant. The problem in most enterprises isn't whether developers want it — they do. The problem is that the default setup (devs paying with their own keys, prompts traversing the public internet, no central visibility) makes finance, security, and compliance teams break out in hives.

Running Claude Code through AWS Bedrock fixes that. Same tool. Your cloud. Your rules.

This post walks through the architecture, then unpacks what it gives each seat at the leadership table: cost control per individual, real usage telemetry, locked-down ingress and egress, and an ROI story you can actually defend.

The architecture in one paragraph

Developers install Claude Code on their laptops as normal. But instead of calling Anthropic's API directly, the CLI is configured to call Amazon Bedrock in your AWS account. You set CLAUDE_CODE_USE_BEDROCK=1 and an AWS region, then authenticate with IAM (typically through AWS IAM Identity Center / SSO). Bedrock fronts the Claude models. From there, every prompt, completion, token count, and error becomes data inside your AWS account — logged, metered, billed, and governed exactly like any other AWS workload.

The diagram is short:

Developer laptop
   └── Claude Code CLI  (CLAUDE_CODE_USE_BEDROCK=1)
        └── AWS SSO / IAM credentials
             └── VPC Endpoint (PrivateLink) — optional but recommended
                  └── Amazon Bedrock (Claude Sonnet / Haiku / Opus)
                       ├── CloudTrail   → audit
                       ├── CloudWatch   → metrics & logs
                       └── Cost & Usage → tagged spend

Identity: who can call which model

Authentication is plain IAM. You give each developer (or each team's role) permission to call bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for the specific Claude model IDs you've approved. Different teams can be granted different model tiers — for example, the platform team gets Opus for hard refactors, while support engineering gets Sonnet for ticket triage.

This matters more than it sounds. It means you can:

• Onboard and offboard Claude Code access through your existing IdP (Okta, Entra ID, Google Workspace) instead of managing a separate vendor's user list.
• Apply session policies, MFA requirements, and conditional access exactly as you do for any other AWS workload.
• Revoke access in seconds when someone leaves — no race to rotate API keys before they walk out the door.

Cost control per individual

This is the part finance cares about most. With the default Anthropic API, a hot loop in someone's automation script can quietly burn five-figure sums before anyone notices. On Bedrock, you can prevent that structurally.

Three mechanisms work together:

The combination is what's new. Per-seat AI budgets, enforced by infrastructure rather than by hoping people read the email about being responsible.

Usage you can actually measure

CloudWatch surfaces Bedrock metrics natively: input tokens, output tokens, invocations, latency, throttles, errors — sliced by model, by region, and (with a small bit of plumbing) by user.

Most enterprises stand up a simple usage dashboard within a day:

• Tokens per developer per week.
• Most-invoked models by team.
• 95th-percentile latency (so you know if devs are waiting on you).
• Throttles and 4xx rates (so you know if your quotas need raising).

Pair the dashboard with model invocation logging, where Bedrock writes the full request and response to an S3 bucket or CloudWatch Logs group you own. This isn't required, but it's gold for two reasons. First, it lets your security team run DLP scans over outbound prompts to make sure nothing sensitive is being leaked into context windows. Second, it gives the platform team a corpus to study — which questions are devs actually asking? Where are they getting stuck? That's a feedback loop you cannot build with a vendor-hosted black box.

Security: ingress and egress, in detail

Most AI deals die on the egress conversation. "If we send code to a third party, what happens to it?" Bedrock removes that question almost entirely.

Egress. With a VPC endpoint for Bedrock (PrivateLink), traffic from your developer laptops — when routed through your corporate VPN or zero-trust agent — never traverses the public internet to reach Bedrock. It stays on the AWS backbone. You can layer endpoint policies on the VPC endpoint to restrict which models can be called, from which principals, and on which networks.

Ingress. Same story in reverse. Responses come back over the same private path. No model output is broadcast anywhere outside your AWS account. CloudTrail records every API call — who, what, when, from which IP. Your SIEM ingests it the same way it ingests every other AWS API call.

Data handling. This is the line that closes the deal: Bedrock does not use your inputs or outputs to train models. Full stop. Combine that with KMS encryption at rest on the S3 buckets you use for invocation logging, and you have a story that satisfies most regulated industries — financial services, healthcare, government — without bespoke contracts.

Guardrails. Bedrock Guardrails can sit in front of model calls to redact PII, block specific topics, or filter out content categories you don't want flowing through. For teams handling regulated data, this is a useful seatbelt.

ROI: stop guessing, start measuring

The question every CTO eventually asks is some version of "are we actually getting value from this?" With Bedrock, you can answer it properly.

You already have the inputs:

• Cost per developer per month, straight out of Cost Explorer via tagged invocations.
• Usage intensity, from CloudWatch — tokens consumed, sessions started, files edited.
• Productivity signal, from your existing DevOps tooling — PRs merged, cycle time, deployment frequency, ticket throughput, code review turnaround.

The interesting numbers come from joining these. Cost per merged PR. Cost per closed ticket. Cycle-time delta between heavy and light Claude Code users on comparable teams. These are the metrics that let you tell a real story to the board — not "developers say they like it" but "we're shipping 23% more features at a marginal AI cost of $40 per feature."

It also lets you spot the inverse: a team burning tokens but not shipping more. That's either a workflow problem, a training gap, or the wrong tool for that team's work — all things you'd want to know.

A sensible rollout

A pattern that works:

• Week one. Pick one team. Enable Bedrock in one region, grant access to one Claude model, tag everything, set a generous per-user budget.
• Week two-to-four. Stand up the dashboard. Watch the numbers. Talk to the developers. Iterate on which models and quotas are right.
• Month two. Expand to two or three more teams. Add PrivateLink. Turn on invocation logging. Pipe CloudTrail to your SIEM.
• Month three onward. Roll out broadly. Per-team budgets become per-individual budgets. Usage data starts feeding your engineering productivity reports.

This is not a six-month transformation. It's a series of small AWS configuration changes, most of which your platform team can do in an afternoon.

The summary you can take into a leadership meeting

Claude Code on AWS Bedrock is the same productivity lift developers already love, wrapped in the operational and security primitives your enterprise already trusts. Cost is controllable per individual and observable per team. Code and prompts never leave your AWS boundary. Audit trails are complete. ROI is measurable, not anecdotal.