What AWS IAM permissions or roles are required to be able to use Amazon Bedrock in an application?

To use Amazon Bedrock in an application, you need to configure AWS Identity and Access Management (IAM) permissions that grant your application access to Bedrock’s API operations. The core requirement is an IAM policy that allows actions like bedrock:InvokeModel, which lets your application send requests to Bedrock’s foundation models (FMs). For example, if your app uses Claude v2 for text generation, you’d need permission to invoke that specific model. You might also need permissions for related actions, such as bedrock:ListFoundationModels to discover available models or bedrock:GetFoundationModel to retrieve details about a model. These permissions are attached to an IAM role (e.g., an EC2 instance role or Lambda execution role) that your application assumes, ensuring it can authenticate and interact with Bedrock.

A basic policy might include a Statement allowing bedrock:InvokeModel on a specific model ARN. For instance:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "bedrock:InvokeModel",
 "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2"
 }
 ]
}

This restricts access to Claude v2 in the us-east-1 region. If your app needs broader access, you could use wildcards (e.g., * for all models), but it’s better to follow the principle of least privilege. You can also add conditions, such as limiting access to specific AWS regions or requiring encryption. If your app lists models before invocation, include bedrock:ListFoundationModels with a broader resource scope (e.g., arn:aws:bedrock:*).

Finally, ensure the IAM role is correctly configured. For example, if your app runs on AWS Lambda, the role’s trust policy must allow lambda.amazonaws.com to assume it. No Bedrock-specific service-linked roles are required, but your application might need additional permissions if it interacts with other services (e.g., reading input from S3). Always test permissions using tools like the IAM Policy Simulator or by running minimal code snippets in a development environment. This ensures your policy works as intended without overprovisioning access.