Guidance for using IAM policies to enforce least privilege and fine grained allow and deny controls for Amazon Bedrock model invocation, knowledge base access, region restrictions, and guardrails
AWS managed policies are intentionally broad and general-purpose. For production workloads, favor custom IAM policies that precisely state which actions are allowed and which specific resources they apply to.
Use the principle of least privilege: grant only the actions and resources an application truly needs. Prefer explicit denies for high-risk or unapproved operations to provide an additional safety net.
Below is a compact, real-world example that lets a principal invoke a single foundation model and use a specific knowledge base for retrieval-augmented generation (RAG):
Author these policies in the IAM JSON editor or via IaC to apply fine-grained restrictions.Examples and guidance
Allowing InvokeModel with a wildcard resource (not recommended)
This policy grants the ability to invoke any Bedrock model and supports response streaming (partial output as the model generates it). Using "Resource": "*" grants broad access and violates least privilege.
Best practice: scope policies to the specific model ARNs required by each application—for example, amazon.nova-micro-v1 for App 1 and anthropic.claude-* variants for App 2.
Deny high-cost models and allow approved models only
Explicitly deny high-cost models and then allow only approved models. A deny statement here prevents escalation if another attached policy accidentally grants broader access.
Deny Bedrock outside approved regions (using a condition)
Enforce regional restrictions with a deny plus condition. Deny statements combined with conditions are an effective mechanism for organization-wide constraints.
Explanation: StringNotEquals on aws:RequestedRegion makes the deny apply when the requested region is not in the approved set.
Allow RetrieveAndGenerate for a specific knowledge base, deny KB management
Allow runtime RAG against a single knowledge base, and explicitly deny knowledge-base management actions (create/update/delete). This prevents accidental or malicious changes even if other policies are permissive.
Use explicit Deny for expensive models, then Allow approved ARNs.
3 — Region restrictions
Enforce approved regions
Use Condition with aws:RequestedRegion in a Deny.
4 — RAG-only for KB
Runtime RAG without management
AllowRetrieveAndGenerate for KB ARN + Deny management actions.
5 — Block Bedrock entirely
Prevent any Bedrock access
Attach a Deny for all invoke/RAG actions.
6 — Guardrail runtime only
Use guardrails but prevent changes
Allow runtime ARN + Deny admin actions for that guardrail.
Outcome and operational benefits
Controlled, governed model usage: applications can only call the models and KBs you authorize.
Reduced blast radius from compromised principals: scoped allows and explicit denies limit what an attacker can do.
Enforced safety and compliance: conditions and guardrail controls enable centralized protections that applications cannot bypass.
IAM controls more than whether a principal can reach Bedrock: it governs which foundation model(s) they can call, in which region(s) they may operate, whether they can access knowledge bases, and which administrative actions are permitted or denied. Use narrow Allow statements to grant necessary capabilities and Deny statements where you need absolute restrictions.This concludes the lesson on using IAM to control access to Amazon Bedrock. For hands-on validation, run lab exercises that attempt operations your policies allow or deny—this is the most reliable way to confirm your configuration.
Use lab exercises to attempt operations that your policies allow or deny to validate your configuration.Links and references
