Skip to main content
In this lesson we show how to control access to Amazon Bedrock using AWS Identity and Access Management (IAM). You’ll learn how to decide who can use Bedrock, which foundation models they can call, and how to restrict access to guardrails and knowledge bases used for retrieval-augmented generation (RAG).
A dark blue presentation slide with the KodeKloud logo at the top and the title "Controlling Access to Bedrock Using IAM" centered.
This lesson covers the problem of unrestricted Bedrock access, the IAM-based solution, example policies (comprehensive and minimal), how those policies behave when attached to principals, and the recommended next steps.
A slide titled "Lecture Flow" shows a horizontal flowchart of rounded blue boxes (Problem → Solution → Workflow → Results) with a lower row for Key Takeaway and What's Next. The content explains using AWS IAM to control Bedrock access, reduce unrestricted access risks, and assign policies to principals.

​
Problem: Unrestricted Bedrock Access Creates Security and Governance Risks

Different users and applications will have different Bedrock needs. Typical Bedrock resources include foundation models, knowledge bases, and guardrails. Granting broad Bedrock permissions without constraints can lead to multiple risks:
  • Uncontrolled invocation of any model, including costly or sensitive models.
  • Access to private or sensitive knowledge bases used for RAG.
  • The ability to bypass guardrails if their use is not enforced.
  • Inconsistent or unsafe usage patterns across your organization.
A lack of fine-grained controls introduces both security and governance problems that IAM can help mitigate.
A slide titled "Problem: Unrestricted Access Creates Security and Governance Risks" showing two user icons and a stack of colored boxes labeled Knowledge Base, Guardrails, and Foundation Models. Bullet points list risks like uncontrolled model invocation, expensive usage, accidental access to sensitive data, bypassed guardrails, and inconsistent usage.

​
Solution: Use IAM to Apply Least Privilege for Bedrock

IAM is the recommended mechanism to:
  • Define who can call Bedrock APIs.
  • Restrict which foundation models can be invoked.
  • Limit RAG operations to specific knowledge bases.
  • Enforce guardrail usage and prevent modification of approved guardrails.
  • Apply the principle of least privilege so each principal gets only the permissions it needs.
Below are example policies and explanations showing how to tighten Bedrock access.

​
Example IAM policy (comprehensive)

This policy demonstrates common controls:
  • Allow a single foundation model.
  • Explicitly deny all other models.
  • Allow RAG operations on a specific knowledge base.
  • Allow applying one approved guardrail while denying any guardrail create/update/delete actions.
Key takeaways from this example:
  • The AllowSpecificFoundationModel statement grants bedrock:InvokeModel only for the specified Claude 3 Sonnet model.
  • The DenyAllOtherModels statement uses NotResource and an explicit Deny to prevent invocation of any other model — an explicit Deny always overrides Allow.
  • AllowSpecificKnowledgeBase limits RAG operations (bedrock:Retrieve, bedrock:RetrieveAndGenerate) to a single knowledge base.
  • Combining AllowSpecificGuardrail with DenyGuardrailModification permits the application of a tested guardrail but prevents creating, editing, or deleting guardrails.
Always prefer narrowly scoped policies (by action and by resource) and use explicit Deny statements when you need to make sure a capability cannot be used.

​
Minimal IAM policy (focused example)

A smaller, focused policy that covers two common needs: allowing one model and permitting RAG against one knowledge base.

​
IAM concepts for Bedrock — quick reference

  • A policy Statement can Allow or Deny one or more actions and can be scoped with Resource or NotResource.
  • Use bedrock:InvokeModel to grant or prevent generation from foundation models.
  • Use bedrock:Retrieve and bedrock:RetrieveAndGenerate to control knowledge-base retrieval and RAG operations.
  • Use bedrock:ApplyGuardrail to allow applying an approved guardrail; use bedrock:CreateGuardrail, bedrock:UpdateGuardrail, and bedrock:DeleteGuardrail to control guardrail lifecycle.
  • An explicit Deny always overrides Allow. Use Deny to enforce strict prohibitions.

​
Mapping common SDK calls to IAM actions

When using an AWS SDK, high-level methods map to Bedrock IAM actions. Test policies by attaching them to a representative principal (role or user) and validating allowed and denied behaviors. Note: Both InvokeModel and Converse map to the same underlying IAM action (bedrock:InvokeModel). Controlling bedrock:InvokeModel in a policy will affect both SDK methods.
  • Attach example policies to test roles and users in a sandbox account.
  • Verify allowed operations succeed and that explicit Deny statements prevent the prohibited actions.
  • For stricter enforcement, combine resource-level restrictions with IAM policy conditions (future content will cover forcing guardrail usage via request attributes and additional policy condition examples).
  • Document which principals require access to which foundation models and knowledge bases — then codify those requirements into least-privilege IAM policies.
Next lesson: policy conditions and enforcement patterns — how to require the use of a specific guardrail or disallow certain model parameters via IAM conditions.

Watch Video