> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Controlling Access to Bedrock Using IAM Part 3
> 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):
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowModelUsage",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet"
]
},
{
"Sid": "AllowKnowledgeBaseRAG",
"Effect": "Allow",
"Action": [
"bedrock:RetrieveAndGenerate"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:knowledge-base/kb-abc123"
]
}
]
}
```
Author these policies in the IAM JSON editor or via IaC to apply fine-grained restrictions.
Examples and guidance
1. 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.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeBedrockModels",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*"
}
]
}
```
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.
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.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyHighCostModels",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/us.meta.llama3-1-70b-instruct-v1:0",
"arn:aws:bedrock:us-east-1::foundation-model/us.meta.llama3-3-70b-instruct-v1:0"
]
},
{
"Sid": "AllowApprovedModelsOnly",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/us.meta.llama3-1-3b-instruct-v1:0",
"arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-micro-v1:0"
]
}
]
}
```
3. 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.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyBedrockOutsideApprovedRegions",
"Effect": "Deny",
"Action": "bedrock:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"us-east-1",
"eu-west-1"
]
}
}
}
]
}
```
Explanation: `StringNotEquals` on `aws:RequestedRegion` makes the deny apply when the requested region is not in the approved set.
4. 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.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRetrieveAndGenerateOnly",
"Effect": "Allow",
"Action": [
"bedrock:RetrieveAndGenerate"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:knowledge-base/kb-abc123"
]
},
{
"Sid": "DenyKnowledgeBaseManagement",
"Effect": "Deny",
"Action": [
"bedrock:CreateKnowledgeBase",
"bedrock:UpdateKnowledgeBase",
"bedrock:DeleteKnowledgeBase",
"bedrock:CreateDataSource",
"bedrock:UpdateDataSource",
"bedrock:DeleteDataSource"
],
"Resource": "*"
}
]
}
```
5. Deny direct Bedrock invocation entirely
For principals that should never interact with Bedrock, attach a deny policy that blocks invocation and RAG operations across the board.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyDirectBedrockInvoke",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:RetrieveAndGenerate"
],
"Resource": "*"
}
]
}
```
6. Allow runtime use of a guardrail but deny guardrail administration
Guardrails moderate or filter model usage at runtime. This pattern allows using a specific guardrail but prevents modifying or deleting it.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUsingGuardrailsAtRuntime",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:guardrail/gr-xyz789"
]
},
{
"Sid": "DenyGuardrailAdminActions",
"Effect": "Deny",
"Action": [
"bedrock:CreateGuardrail",
"bedrock:UpdateGuardrail",
"bedrock:DeleteGuardrail"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:guardrail/gr-xyz789"
]
}
]
}
```
Quick reference table
| Example | Purpose | Recommended pattern |
| - | -: | - |
| 1 — Wildcard invoke | Quick testing or POC | Avoid `Resource: "*"`. Scope to model ARNs. |
| 2 — Deny high-cost models | Cost control and risk reduction | 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 | `Allow` `RetrieveAndGenerate` 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
* [AWS Identity and Access Management (IAM) documentation](https://docs.aws.amazon.com/iam/latest/UserGuide/)
* [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/)
* IAM policy simulator: `https://policysim.aws.amazon.com/`
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.