How to Manage Amazon Bedrock Access With Terraform

Teams often start with Amazon Bedrock by clicking through the console: enabling a model, attaching a broad policy to a role and testing from a notebook. That's fine for an afternoon. For anything a customer will depend on, access should be defined in code, reviewed and reproducible across accounts.

Step 1: Decide who calls which models

List the applications that will call Bedrock, the models each one needs and the environments they run in. A production support agent might need one model in one region, while a data science sandbox needs several. Writing this down first keeps the policies narrow.

Step 2: Write a narrow IAM policy

Grant invoke permissions only for the models an application uses:

data "aws_iam_policy_document" "support_agent_bedrock" {
  statement {
    actions = ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"]
    resources = [
      "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*",
    ]
  }
}

resource "aws_iam_role_policy" "support_agent_bedrock" {
  role   = aws_iam_role.support_agent.id
  policy = data.aws_iam_policy_document.support_agent_bedrock.json
}

If the application uses cross-region inference profiles, the policy also needs the inference profile ARNs and the underlying models in each region the profile can route to. Check the documentation for the exact resources your models require.

Step 3: Turn on invocation logging

Bedrock can log requests and responses to CloudWatch Logs or S3, and the aws_bedrock_model_invocation_logging_configuration resource sets this up for each region. Agree with the customer whether full prompts may be stored, and set log retention to match their policy.

Step 4: Separate accounts per environment

Run development, staging and production in separate AWS accounts, using the same Terraform modules with different variables. An access mistake in development then can't reach production data.

Step 5: Record the one-time steps

Depending on the model and account, some models still need access enabled or terms accepted before the first call. Note these steps in the runbook next to the Terraform code, so a new account doesn't fail on day one.

Things to watch

• Wildcards grow quietly. bedrock:* on every resource is common in examples. Replace it before production.
• Quotas are per account and region. Request increases through Service Quotas in each production account and add them to your launch checklist.
• Guardrails. If the customer requires Bedrock Guardrails, define them in Terraform as well and pass their IDs to the application as configuration.

Import any roles created in the console into Terraform before changing them, so code becomes the only way access changes.