How We Use Claude Code Across 100+ Customer AWS Accounts with Bedrock

The problem

A typical day for our team involves touching multiple different customer accounts. Each has a dedicated git repo, a unique IAM role for AWS access, and specific infrastructure we need Claude’s help reasoning about.

Claude Code supports AWS Bedrock as a model provider — you set a few environment variables and it routes requests through the customer’s own Bedrock endpoint instead of Anthropic’s hosted API. But the setup is manual: assume the right role, grab temporary credentials, export a handful of env vars, and then launch claude. Do that 10 times a day across different accounts and it becomes the kind of toil that devops teams are supposed to eliminate.

We wanted something where you cd into a customer repo, run one command, and Claude Code is automatically using that customer’s Bedrock. No credential files in repos, no copy-pasting ARNs, no forgetting which account you’re in.

The toolchain

We built three scripts that chain together:

1. clc-sso.sh — Role selection from 1Password

Every customer role ARN lives in 1Password, tagged clcop_automation. The script fetches all tagged items, lets you pick one via fzf or a numbered menu, assumes the role via STS, and exports the credentials into your shell.

source clc-sso.sh              # Interactive role selectionsource clc-sso.sh --fuzzy      # fzf search across all rolessource clc-sso.sh --listroles  # Just list what’s available

We store about 200 role ARNs across multiple 1Password vaults. The key design decision was making 1Password the single source of truth for role ARNs — no config files, no .env files, no spreadsheets.

2. clc-bedrock-setup — One-time per-repo configuration

Someone on the team runs setup once per customer repo:

cd ~/git/customer-repo
clc-bedrock-setup
--region us-east-1

This lists roles from 1Password, verifies Bedrock access in the target region, and writes a .claude-bedrock config file containing just the 1Password item ID and region — nothing sensitive on disk, safe to commit.

3. claude-bedrock — The daily launcher

This is the command you actually use day-to-day:

cd ~/git/customer-repo
claude-bedrock


Any flags you pass are forwarded directly to Claude Code:

claude-bedrock --model opus

Running team and customer sessions in parallel

You can run your regular Claude Code session alongside customer Bedrock sessions — the Bedrock env vars are set per-process, not globally:

# Terminal 1: team account, internal workclaude# Terminal 2: Customer A via Bedrockclaude-bedrock# Terminal 3: Customer B via Bedrock (different repo)claude-bedrock

You can verify which provider is active inside Claude Code with /status.

Provisioning Bedrock access in new accounts

When we onboard a new customer, the flow is:

1. Add the customer’s role ARN to 1Password with the clcop_automation tag
2. cd into the customer repo
3. Run clc-bedrock-setup
4. If Bedrock isn’t provisioned, accept the CloudFormation deployment

The CloudFormation template creates a single IAM role with scoped Bedrock permissions:

bedrock:InvokeModel
bedrock:InvokeModelWithResponseStream
bedrock:ListFoundationModels


The whole thing takes about 30 seconds.

What we use Claude Code for

Infrastructure debugging. When a customer reports an issue, we cd into their repo, launch claude-bedrock, and ask Claude to investigate. It can read the Terraform state, check CloudFormation drift, and parse CloudWatch logs — all scoped to that specific customer’s account.

Terraform and CloudFormation authoring. We use Claude Code to write and review IaC. Because it’s running against the customer’s Bedrock, the customer’s data governance policies apply.

Runbook execution. We have operational runbooks that Claude Code can follow step-by-step, running commands against the right account.

Packaging and distribution

# macOSbrew install clc-sso-tools


# Linuxdpkg -i clc-sso-tools.deb


# Eithermake install PREFIX=$HOME/.local

What made this work

1Password as the credential backbone. Every role ARN lives in 1Password. Team members only access vaults for customers they work with — the tooling naturally enforces least-privilege.

No credentials on disk. The .claude-bedrock file stores a 1Password item ID, not an ARN or secret. Safe to commit — credentials are resolved at runtime through 1Password and STS, scoped to a single terminal session.

Explicit over automatic. You choose claude-bedrock when you want Bedrock, and claude when you want the team account. Being explicit about which identity you’re operating under is worth the extra keystroke.

This article was written by Mark Painter and co-created with Claude, Anthropic’s AI assistant. The technical content, experiences, and opinions are Mark’s own.

‍

This article was written by Mark Painter and co-created with Claude. The technical content, experiences, and opinions are Mark's own.