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.
We built three scripts that chain together:
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. Each vault corresponds to a customer or internal group - you can filter by vault to see just one customer's roles, or by tag to show only readonly access.
The key design decision was making 1Password the single source of truth for role ARNs. No config files, no .env files, no spreadsheets. When someone onboards a new customer account, they add the role to 1Password with the right tag, and it immediately appears for everyone with access to that vault.
Someone on the team runs setup once per customer repo:
cd ~/git/customer-repoclc-bedrock-setup --region us-east-1
This:
.png)
.claude-bedrock config file (just the 1Password item ID and region)If Bedrock isn't provisioned in the customer's account yet, the tool offers to deploy a CloudFormation stack that creates the necessary IAM role. It's a one-click provision step.
The .claude-bedrock file references a 1Password item ID rather than storing the ARN directly. This means credentials are resolved at runtime through 1Password - nothing sensitive sits on disk, and the file is safe to commit. Once one team member runs setup, everyone else on the repo gets the config automatically.
This is the command you actually use day-to-day:
cd ~/git/customer-repoclaude-bedrock
It finds the .claude-bedrock config by walking up parent directories (so it works from any subdirectory), resolves the role ARN from 1Password, assumes the role via SSO, and execs claude with the Bedrock environment variables set. Any flags you pass are forwarded to Claude Code, for example claude-bedrock --model opus.
The experience is: cd into a repo, type claude-bedrock, and you're in Claude Code with that customer's Bedrock. No other steps. If your SSO session expires, it tells you. If 1Password needs re-auth, it prompts. There is no silent failure mode.
One thing we explicitly designed for: you can run your regular Claude Code session (using the team Anthropic account) alongside customer Bedrock sessions. They don't interfere - the Bedrock env vars are set per-process, not globally.
Terminal 1: claude - team account, internal work
Terminal 2: claude-bedrock - Customer A via Bedrock
Terminal 3: claude-bedrock - Customer B via Bedrock (different repo)
You can verify which provider is active inside Claude Code with /status.
When we onboard a new customer, the flow is:
clcop_automation tagcd into the customer repoclc-bedrock-setupThe CloudFormation template creates a single IAM role with scoped Bedrock permissions (bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:ListFoundationModels). It trusts our SSO role as the principal. The whole thing takes about 30 seconds.
For customers who manage their own IAM, we hand them the template and they deploy it via their own pipeline or Service Catalog.
With the access plumbing solved, Claude Code becomes a core part of our devops workflow:
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, parse CloudWatch logs - all with access 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. The model invocations stay within their account boundary.
Runbook execution. We have operational runbooks that Claude Code can follow step-by-step, running commands against the right account. The credential context is always correct because claude-bedrock handles it before Claude even starts.
Cross-account auditing. The --switchroles flag generates a config file for the AWS Extend Switch Roles browser extension, so we can quickly jump between customer consoles while Claude Code handles the CLI side.
The tools are packaged for easy team distribution:
# macOSbrew install clc-sso-tools via a Homebrew tap
# Linuxdpkg -i clc-sso-tools.deb
# Eithermake install PREFIX=$HOME/.local
All three methods install shell completions (bash and zsh) automatically, so tab-completion works for flags like --listroles, --switchroles, and --fuzzy out of the box.
A few design decisions that were worth the effort:
1Password as the credential backbone. Instead of config files or environment variables per customer, every role ARN lives in 1Password. This gives us access control, audit logging, and team sharing for free. Team members only get access to the vaults for the customers they work with, so the tooling naturally enforces least-privilege - you can only assume roles you can see. When someone leaves the team or moves off an account, revoking their vault access revokes their ability to assume those customer roles.
Shell scripts, not a compiled tool. The scripts work on macOS (bash 3.2 + zsh) and Linux without compilation. They're easy to audit, easy to debug (DEBUG=3 shows every step), and easy to extend. The tradeoff is performance - shell scripts aren't fast - but for an interactive tool that runs once per terminal session, it doesn't matter.
No credentials on disk. The .claude-bedrock file stores a 1Password item ID, not an ARN or secret. It's safe to commit - anyone who clones the repo gets the config, but they still need 1Password vault access to resolve the actual role. Credentials are obtained 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. There's no magic detection of which account to use. We found that being explicit about which identity you're operating under is worth the extra keystroke.
The architecture is straightforward: a credential store (we use 1Password), a per-repo config file that references it, and a launcher that resolves credentials at runtime. The CloudFormation template for Bedrock IAM roles is minimal - under 60 lines. If your team manages multiple AWS accounts and wants to use Claude Code via Bedrock, this pattern scales well.
This article was written by Mark Painter and co-created with Claude. The technical content, experiences, and opinions are Mark's own.
Join 1,000+ engineers and CTOs building smarter
