InnovationSandboxLimitRegionsScp blocks Amazon Bedrock cross-region inference

[chrisns]

Problem Description

The InnovationSandboxLimitRegionsScp Service Control Policy is blocking Amazon Bedrock's cross-region inference feature, which can cause confusing errors for users when Bedrock routes requests to regions outside the managed region list.

Background

Amazon Bedrock's cross-region inference feature automatically routes inference requests across AWS regions for improved throughput and availability. When using inference profiles (including the default profiles for Anthropic Claude and Amazon Nova models), Bedrock may route requests to regions like us-east-2 even when the user's request originates in an allowed region like us-east-1.

How the issue manifests

1. User makes a Bedrock InvokeModel request in an allowed region (e.g., us-east-1)
2. Bedrock routes the request to an optimal destination region (e.g., us-east-2)
3. The SCP evaluates aws:RequestedRegion as us-east-2
4. Since us-east-2 is not in the managed regions list, the request is denied
5. User receives an SCP error referencing us-east-2, which is confusing since they never explicitly requested that region

This was particularly difficult to debug as the error messages referenced regions that users hadn't intentionally accessed.

Current Workaround

I've had to patch the SCP to add an exception for Bedrock inference profiles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-west-2",
            "us-east-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/InnovationSandbox-ndx*",
            "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*AWSReservedSSO_ndx_IsbAdmins*",
            "arn:aws:iam::*:role/stacksets-exec-*",
            "arn:aws:iam::*:role/AWSControlTowerExecution"
          ],
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/*"
        }
      },
      "Action": "*",
      "Resource": "*",
      "Effect": "Deny",
      "Sid": "DenyRegionAccess"
    }
  ]
}

The key addition is the bedrock:InferenceProfileArn condition, which allows requests using inference profiles to bypass the region restriction.

Suggested Solutions

Option 1: Null condition (simplest)

Add a Null condition for bedrock:InferenceProfileArn to the limit regions SCP:

"Null": {
  "bedrock:InferenceProfileArn": "true"
}

This means "only apply this deny if the inference profile ARN is NOT present" - allowing cross-region inference while maintaining regional restrictions for all other services and direct model invocations.

Option 2: ArnNotLike condition (more flexible)

Add bedrock:InferenceProfileArn to the existing ArnNotLike block:

"ArnNotLike": {
  "aws:PrincipalARN": [
    "arn:aws:iam::*:role/InnovationSandbox-${namespace}*",
    ...
  ],
  "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/*"
}

This approach is more flexible because the pattern can be easily scoped to specific geographic regions if data residency is a concern:

• All profiles: arn:aws:bedrock:*:*:inference-profile/*
• US only: arn:aws:bedrock:*:*:inference-profile/us.*
• EU only: arn:aws:bedrock:*:*:inference-profile/eu.*

This allows administrators to permit cross-region inference while ensuring data stays within a specific geographic boundary (e.g., US regions only route to other US regions).

Benefits

• Enables Bedrock cross-region inference for improved throughput and availability
• Maintains regional restrictions for all other AWS services
• Preserves existing principal exemptions
• Approximately 10% cost savings available with global inference profiles
• Option 2 allows geographic scoping for data residency requirements

References

• Enable Amazon Bedrock cross-region inference in multi-account environments (AWS Machine Learning Blog)
• Cross-region inference documentation
• Bedrock condition keys

Thank you for considering this enhancement. Happy to provide any additional information or discuss alternative approaches.

[chrisns]

likely related to #29

[aws-khargita]

Thank you @chrisns for identifying this issue. Your suggested solutions here seem sound and should ultimately be added to the default SCPs.

The more general issue that we need to solve before we do this is around SCP update management. Currently any change we make to the default SCPs will cause manual customizations made on your deployment to be rolled back to the defaults which is undesirabl.

We are planning to implement a way to gracefully merge new default values customizations on update. That mechanism will be necessary before officially implementing this change to maintain backwards compatibility.

Will keep you updated on this!