Claude Code on Amazon Bedrock uses AWS credentials, an AWS region and model access in the AWS account. Start by identifying which account and role the shell is using, then enable the Bedrock route in Claude Code. A successful AWS login and permission to invoke a model are separate checks.
This guide uses the documented SSO profile route. It does not require putting an AWS secret key in a project file. Commands below use the example profile name company-dev; replace it with the profile approved for your account.
On this page
Confirm the AWS identity first
AWS documents the IAM Identity Center workflow in its CLI authentication guide. Configure a named profile if your administrator has not already provided one:
aws configure sso
aws sso login --profile company-dev
aws sts get-caller-identity --profile company-dev
Complete the browser authentication that the CLI requests. The final command returns the calling identity, including its account and ARN, as documented in the STS command reference.
Check that identity before debugging Claude Code. If it belongs to an unexpected account or role, resolve the profile selection first. Do not paste the identity output into a public issue without considering what organisational information it reveals.
Select Bedrock in the launching shell
Anthropic’s Bedrock deployment guide documents these environment variables:
export AWS_PROFILE=company-dev
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
claude
Here us-east-1 is an example. Use the Bedrock region your organisation selected and where the intended model or inference profile is available.
Run the configuration and claude in the same shell. As a practical troubleshooting step, avoid changing credentials, region and model selection simultaneously: keep a known identity while checking each later stage.
Check access at the service layer
The Claude Code deployment guide lists Bedrock model access and appropriate IAM permissions as prerequisites. An STS identity response establishes which principal authenticated; it does not demonstrate that this principal can invoke a particular model.
| Observation | Next question |
|---|---|
| AWS login fails | Is the SSO profile and identity-provider session configured correctly? |
| Identity is unexpected | Did the shell select the intended profile? |
| Identity is correct, invocation is denied | Does this role have the required Bedrock access? |
| Model cannot be found | Is the model or inference profile available in the selected region? |
| Another terminal works | What differs in that terminal’s effective configuration? |
This table is a diagnostic workflow, not a substitute for the service’s actual error message. Keep the original error, requested region and selected model together when asking an administrator to investigate.
Keep the model choice explicit
Anthropic recommends pinning model versions for a team deployment. Take the full Bedrock model ID or inference-profile identifier from the official documentation and your account’s configuration rather than copying an old alias from another project.
Record that selection with the deployment instructions. When an administrator changes the permitted model, review the corresponding configuration deliberately. A login fix should not silently become an unreviewed model migration.
Know what to recheck when the session expires
AWS distinguishes renewable role credentials from the IAM Identity Center session used to obtain them. When the Identity Center session itself expires, the user must sign in again.
Begin with the same profile:
aws sso login --profile company-dev
aws sts get-caller-identity --profile company-dev
Only then restart the coding session if needed. Replacing a working SSO setup with a long-lived key adds a new credential-management problem instead of explaining the original failure.
For local execution permissions after authentication, see Claude Code sandbox boundaries. Authentication to a model provider and permission to modify a local project are different parts of the setup.
