Least-Privilege IAM for Bedrock — Access, Regions, and IAM
Least-Privilege IAM for Bedrock
Identity Boundaries First
Use dedicated IAM roles for Bedrock callers and grant only the actions and model resources required. A leaked credential with bedrock:* on * can silently run up enormous token bills or exfiltrate data through model calls - least privilege is your first cost control and your first security control.
A Production-Shaped Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeApprovedModelsOnly",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-lite-v1:0",
"arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0"
]
}
]
}Note what this policy does not include: no bedrock:CreateGuardrail, no customization jobs, no ListFoundationModels. The application role invokes exactly two pinned models and nothing else. Platform/admin roles get the control-plane actions separately.
Common IAM Mistakes with Bedrock
| Mistake | Risk | Fix |
|---|---|---|
"Resource": "*" on invoke actions | Any newly enabled model becomes instantly callable | Pin foundation-model ARNs per environment |
| One shared role for app + admin | App compromise grants policy/config mutation | Separate runtime and management roles |
| Long-lived access keys in code | Key leakage = unlimited token spend | Use role assumption (IRSA, instance profiles, Lambda execution roles) |
| No CloudTrail review for bedrock events | Silent misuse goes unnoticed | Alert on anomalous InvokeModel volume and denied calls |
Defense in Depth
Combine IAM with application-side allowlists so business logic cannot invoke unapproved models even if policy broadens later. IAM answers "what is this principal allowed to call?"; your config answers "what has this product approved?". Both should agree, and either alone should be enough to block a mistake.
bedrock:InvokeModel on any model ARN outside your approved catalogue. Individual account admins then cannot accidentally widen access.Verify that application IAM policies restrict model invocation strictly to permitted foundation models and guardrails.