Skip to main content
This guide explains how to use IAM policies and attach them to security principals so your application can call Amazon Bedrock securely. It focuses on recommended practices for applications running inside AWS (EC2, Lambda, ECS) and on how to give Bedrock the permissions it needs to act on your behalf for operations such as Retrieve and Generate (RAG) or knowledge-base access. If your application runs on an EC2 instance, in a Lambda function, or inside an ECS managed container, that compute environment is where your app will call Bedrock from. Rather than embedding long‑lived access keys into application code, use IAM roles — the preferred and secure approach. An IAM role can be attached to:
  • EC2 instances (via an instance profile),
  • Lambda functions (as an execution role),
  • ECS tasks/containers (as a task role).
The role is a security principal and can have an IAM policy attached to grant the necessary permissions. When your application calls Bedrock (for example using InvokeModel or RetrieveAndGenerate), whether the call succeeds depends on the permissions granted to the IAM role attached to the compute environment. We must also consider actions Bedrock might perform on our behalf. For example, when using Retrieve and Generate (RAG), Bedrock may need to access your S3 objects or query/ingest vectors in a vector store. For those operations, Bedrock itself needs a service role with policies that grant access to the underlying resources (S3, OpenSearch, Lambda, etc.). You explicitly configure this service role when setting up the integration so Bedrock can perform those tasks on your behalf.
A diagram showing an AWS Bedrock permissions workflow: an app running on EC2/Lambda/ECS uses an App IAM Role to call Amazon Bedrock, which in turn uses service roles to access other AWS services like S3 and a vector store.
What principals can a policy be attached to? App authentication and authorization (SDK usage) If you call Bedrock from an environment outside AWS, you might provide an access key and secret in your client configuration. Instead, when your code runs inside AWS, attach an IAM role to the compute resource (EC2 instance profile, Lambda execution role, or ECS task role). The AWS SDK automatically uses the temporary credentials (access key, secret key, and session token) provided by the role. These temporary credentials are rotated and refreshed automatically, reducing the risk compared to long‑lived credentials.
Prefer attaching an IAM role to your compute resource (instance profile, execution role, or task role) so the SDK uses temporary credentials that are rotated automatically.
Temporary credential concept (illustrative)
When does Bedrock need a service role? If Bedrock must perform actions in your account (for example, indexing documents in S3 for a knowledge integration or invoking Lambda in an automated workflow), you must provide Bedrock with an IAM service role that grants those specific permissions. You configure this role when you set up the integration; the role enables Bedrock to call other AWS services on your behalf (S3, OpenSearch, Lambda, etc.).
A flowchart titled "Workflow: When Do We Need a Service Role?" showing Amazon Bedrock at the top feeding into an IAM Service Role that grants permissions. The role is used by a Knowledge Base and Agents, which access resources like S3 Bucket, OpenSearch, and Lambda.
Principle of least privilege Always grant only the permissions your application actually needs. For example, if an application only needs to invoke Claude 3 Sonnet, create a policy that allows only bedrock:InvokeModel for that specific model ARN and attach it to the role used by your compute resource. Everything else should be implicitly denied. Remember:
  • IAM enforces an implicit deny: if a permission is not explicitly allowed, it is denied.
  • Explicit Deny statements take precedence over Allows. If you must ensure certain actions can never be performed by a role, add an explicit Deny.
Avoid wildcard permissions like bedrock:*. Wildcards can grant far more access than intended (e.g., creating agents, spinning up Marketplace deployments, or accessing training data). Use explicit actions and resource ARNs.
Special caution areas
  • Do not grant access to models or features your application will not use — e.g., don’t grant AgentCore or agent creation if unnecessary.
  • Knowledge integrations can expose sensitive organization data. Grant access only to principals that legitimately need to search or retrieve that data.
  • Scope permissions to the specific AWS Region(s) where your application runs. If your app runs only in eu-west-3 (Paris), do not grant Bedrock permissions in other Regions like us-east-1 or ap-southeast-1.
Creating a policy in the AWS Console In the IAM Management Console, go to Access management → Policies. AWS provides many Amazon‑managed policies out of the box; these are marked with a small orange icon. While convenient, Amazon‑managed policies can be broader than necessary for production. Best practice is to author custom policies tailored to your application’s exact needs. You can create a custom policy in two ways:
  • Use the visual policy builder (checkbox UI that generates JSON).
  • Write the JSON policy directly — knowing the JSON is valuable for troubleshooting and precise scoping.
A slide titled "Workflow: Creating an IAM Policy" showing the AWS IAM console with a list of policies and a highlighted callout warning that using built-in policy documents in production can grant more permissions than needed.
Example policy (JSON) This tightly scoped example:
  • Allows invoking a specific foundation model (Claude 3 Sonnet) using bedrock:InvokeModel.
  • Allows Bedrock RAG calls for a specific knowledge base using bedrock:RetrieveAndGenerate.
This policy demonstrates the approach: explicitly list only the actions and resources required (InvokeModel for the exact model ARN and RetrieveAndGenerate for the exact knowledge base ARN). Avoid wildcards in Action or overly broad resource ARNs in production. Quick checklist for production-ready Bedrock policies Summary
  • Attach policies to IAM roles for compute resources (EC2/Lambda/ECS) rather than embedding long‑lived credentials.
  • Provide Bedrock a custom service role when it must act on your behalf (knowledge bases, agents).
  • Follow the principle of least privilege: allow only the actions and resources your application needs, scoped to the required Region(s).
  • Prefer custom, narrowly scoped policies instead of Amazon‑managed or wildcard policies for production.
Links and references

Watch Video