Skip to main content
AI-Implement supports AWS Bedrock as a provider, letting you invoke Claude models through your AWS account using GitHub OIDC — no static AWS credentials required. When Bedrock is configured, the orchestrator passes provider=bedrock and your chosen AWS region to the workflow at dispatch time, and the workflow assumes an IAM role via OIDC before invoking Claude. This page walks through the full setup.
provider=bedrock is not compatible with executionMode=fly-machines. If your repo mapping uses Fly Machines execution, you must switch to github-actions before enabling Bedrock.

​
How authentication works

The workflow uses GitHub OIDC to assume an IAM role — there is no static AWS key path. Once per run, before the containerized implementation step starts, the workflow calls aws-actions/configure-aws-credentials to exchange the GitHub OIDC token for a short-lived STS session, requesting a 4-hour session so it comfortably outlasts the job and covers both implementation and its post-push review pass.
Only OIDC is supported. Static AWS access keys (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY) are not read or used by the workflow.

​
Configuration steps

1

Edit the repo mapping in the admin UI

Navigate to your orchestrator’s /admin page, find the team/repo mapping, and open the edit form.Set these two fields:
  • Provider → bedrock
  • AWS Region → the AWS region where your Bedrock inference profile is available (e.g. us-west-2)
Save the mapping. The orchestrator will now pass provider=bedrock and your region to the workflow on each dispatch.
2

Add the IAM role ARN as a repository secret

In your target GitHub repo, go to Settings → Secrets and variables → Actions → Secrets and add:The role must be created in the same AWS account as your Bedrock inference profiles.
3

Add repository variables for comment-triggered runs

When someone comments /ai-implement on a PR, the orchestrator dispatches the gap-fill run itself using the mapping’s Provider and AWS Region fields, so no extra configuration is needed for repos synced to the current workflow templates. If your repo is still on the older, pre-sync workflow (comment-trigger.yml present in .github/workflows/), that workflow reads its provider settings from repository variables instead — add two repository variables (not secrets) so it stays consistent with the admin UI mapping.In your target repo, go to Settings → Secrets and variables → Actions → Variables and add:Without these variables, comment-triggered gap-fill runs will fall back to the Anthropic provider.
4

Set the model in WORKFLOW.md (and PLANNING.md)

Update the model: key in your repo’s WORKFLOW.md to a Bedrock model ID or inference-profile ARN. If planning is enabled, update PLANNING.md as well.
Or use an inference-profile ARN:
model: is required for Bedrock — the IDs include date stamps and are specific to your account and region, so there is no safe default.Nothing validates the model against the provider. Omit it and the run substitutes an Anthropic model ID, which fails when that model is invoked rather than up front as a configuration error.

​
IAM role configuration

Create an IAM role in your AWS account with the following trust policy. Use the StringLike condition on sub to restrict the role to a specific GitHub repo:
Replace <account-id>, <owner>, and <repo> with your actual values. For the role’s permissions policy, grant bedrock:InvokeModel on the inference profiles your repo will use:
The credential exchange happens once per run and requests a 4-hour session — long enough to cover implementation and the post-push review pass without a second STS round-trip.

​
Model IDs

Bedrock model IDs follow the pattern anthropic.<model-name>-<date>-v<version>:0. You can also use a cross-region inference-profile ARN. Both are passed verbatim to claude-code --model — the workflow does not validate the format. Example model IDs for Bedrock:
The post-push review pass uses the same model: value as implementation — there is no separate, cheaper model for it on either provider.