AWS Bedrock Error: Cross-Account Bedrock Access Denied

#aws#bedrock#devops#cloud

A diagnostic guide to resolving Bedrock invocation failures caused by missing cross-account IAM trust and permissions.

Problem

An AWS Bedrock invocation fails when called from a different AWS account than the one where the model access is enabled.

Common symptoms:

• AccessDeniedException during invocation
• IAM permissions appear correct in both accounts
• The same code works when run inside the model-owning account
• Cross-account role assumption appears to succeed, but Bedrock still fails

---

Clarifying the Issue

This error is not a Bedrock service outage and not a model availability issue.

It occurs when cross-account authorization is incomplete.

In cross-account Bedrock usage, all of the following must align:

1. The caller account must be allowed to assume a role in the target account
2. The target account role must trust the caller account
3. The assumed role must allow bedrock:InvokeModel
4. Model access must be enabled in the target account and region

If any layer is missing, Bedrock returns AccessDeniedException.

---

Why It Matters

Cross-account patterns are common in:

• Centralized AI platforms
• Shared inference accounts
• Multi-account AWS Organizations
• Security-separated prod/dev setups

When this fails, teams often debug Bedrock or IAM policies in isolation, missing the trust boundary between accounts.

---

Key Terms

• Cross-account role – IAM role assumed from another AWS account
• Trust policy – Policy that allows an external account to assume a role
• Source account – Account initiating the Bedrock request
• Target account – Account that owns Bedrock model access

---

Steps at a Glance

1. Identify source and target accounts
2. Verify role trust policy in the target account
3. Confirm role assumption succeeds
4. Check Bedrock permissions on the assumed role
5. Validate model access and region in the target account

---

Detailed Steps

1. Identify the Account Boundary

Confirm:

• Source account → where the code runs
• Target account → where Bedrock model access is enabled

Bedrock invocation always executes in the target account context.

---

2. Verify the Role Trust Policy (Target Account)

In the target account, open the role being assumed.

The trust policy must allow the source account to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<SOURCE_ACCOUNT_ID>:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

If the source account is not trusted, the role assumption will fail or behave unexpectedly.

---

3. Confirm Role Assumption Succeeds

From the source account, validate role assumption explicitly:

aws sts assume-role \
  --role-arn arn:aws:iam::<TARGET_ACCOUNT_ID>:role/<role-name> \
  --role-session-name bedrock-test

If this fails, Bedrock is not the problem.

---

4. Verify Bedrock Permissions on the Role

The assumed role must include:

{
  "Effect": "Allow",
  "Action": [
    "bedrock:InvokeModel",
    "bedrock:InvokeModelWithResponseStream"
  ],
  "Resource": "*"
}

Permissions in the source account do not matter after the role is assumed.

---

5. Confirm Model Access and Region (Target Account)

In the target account:

• Open Bedrock → Model access
• Ensure the model is Enabled
• Confirm access is enabled in the same region used by the SDK or CLI

Model access is per-account and per-region.

---

Pro Tips

• Bedrock always evaluates permissions in the assumed role’s account
• Successful AssumeRole does not imply Bedrock permission
• Model access must exist in the target account, not the source
• SCPs in either account can block Bedrock silently

---

Conclusion

Cross-Account Bedrock Access Denied is almost always a trust boundary failure, not a model or SDK issue.

Once:

• The role trust policy allows the source account
• The assumed role permits Bedrock invocation
• Model access is enabled in the correct account and region

AWS Bedrock invocation works reliably across accounts inside Amazon Web Services.

Fix the trust.
Verify the role.
Confirm the region.
Retry the call.
Move on.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.