Why might my Bedrock request be failing with an AccessDenied or unauthorized error, even though I've set up what I believe are the correct permissions?

If your AWS Bedrock request is failing with an AccessDenied or unauthorized error despite configuring permissions, the issue likely stems from one of three areas: misconfigured IAM policies, missing resource-based policies, or incorrect credentials or region settings. Let’s break down each possibility.

First, review the IAM policies attached to the user, role, or service account making the request. Bedrock requires explicit permissions for actions like bedrock:InvokeModel or bedrock:ListFoundationModels. For example, if your policy only grants bedrock:* on all resources (Resource: "*"), but your organization enforces resource constraints, the policy might be too broad and blocked by service control policies (SCPs). Alternatively, the policy might lack necessary permissions for specific model IDs. Check for typos in action names or ARNs. A common mistake is forgetting to include the model ARN (e.g., arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2) in the Resource field. Use the IAM Policy Simulator to validate whether the policy grants the intended access.

Second, Bedrock models may require resource-based policies if they’re shared across accounts or have access restrictions. For instance, if you’re invoking a custom model owned by another AWS account, the model’s resource policy must explicitly allow your account or IAM principal. Similarly, if the model is in a different region, ensure cross-region permissions are configured. For example, a policy allowing bedrock:InvokeModel in us-west-2 won’t apply to requests sent to us-east-1. Also, check for conflicting deny rules in SCPs or permission boundaries that override your IAM policies. These higher-level policies can silently block access even if the IAM policy appears correct.

Finally, verify credential and configuration issues. If you’re using temporary credentials (like AWS STS tokens), ensure they haven’t expired and that the associated IAM role trusts the service assuming it (e.g., Lambda or EC2). For SDKs or CLI tools, confirm the AWS region in your configuration matches the region where the model is available. For example, invoking anthropic.claude-v2 in us-west-2 while your SDK defaults to us-east-1 will fail. Additionally, if you’re using MFA or session tags, ensure requests include required parameters. Tools like AWS CloudTrail can help trace the exact error by filtering AccessDenied events, which often include details like missing permissions or mismatched resource ARNs.