If you're using Bedrock in a Control Tower environment, make sure to leverage region deny controls at the OU level

Hello! I'm Yoshida from the Cloud Business Division.

When I tried to use Amazon Bedrock's cross-region inference in a Control Tower environment, I encountered an issue where access was denied by the region deny SCP.

In this article, I'll introduce a method to use Bedrock's cross-region inference while maintaining region deny settings, by combining the OU-level managed region deny control (CT.MULTISERVICE.PV.1) with a custom SCP.

The Problem

When trying to use Bedrock from SageMaker Unified Studio, the following error occurred:

User: arn:aws:sts::123456789012:assumed-role/AmazonSageMakerBedrockModelConsumptionRole-xxxx/xxxx
is not authorized to perform: bedrock:InvokeModelWithResponseStream on resource:
arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0
with an explicit deny in a service control policy

Looking at the error message, access to the us-east-2 (Ohio) region is being explicitly denied by an SCP.

How Cross-Region Inference Works

Bedrock's cross-region inference is a feature that automatically routes requests to multiple regions to improve availability and maximize throughput. ※1

When using a global inference profile, users cannot explicitly specify the destination region for routing.
Since AWS automatically determines the routing destination, API calls to regions outside of management may occur.

In this environment, region deny settings were enabled at the landing zone level, restricting access to regions other than the managed regions (Tokyo, Osaka, Northern Virginia, London).
As a result, SCP denied access to the Ohio region that cross-region inference attempted to route to.

Types of Region Deny Controls

In Control Tower, you can configure "region deny controls" that deny API actions outside of managed regions.
There are two types of region deny controls. ※2

The cause of this problem was that we were using the landing zone region deny control.
Since the landing zone region deny control cannot configure exceptions, it cannot handle cases like cross-region inference.

To resolve this issue, migration to the OU-level region deny control (CT.MULTISERVICE.PV.1), which supports exception API configuration, is required. ※3

Examining the Approach

We considered two approaches for this problem.

Approach 1: OU Separation Method

This method creates a dedicated OU for Bedrock-using accounts and applies CT.MULTISERVICE.PV.1 with ExemptedActions set only to that OU.

This approach has the following disadvantages:

• OU-level region deny control settings differ per OU, making management complex
• Accounts that later need to use Bedrock will require OU migration
• CT.MULTISERVICE.PV.1 can only be applied to OUs and cannot be configured at the account level

Approach 2: OU-Level Region Deny Control + Custom SCP Combined Method (Adopted)

This method applies both the OU-level region deny control and a custom SCP to the first-tier OU.

• OU-level region deny control (CT.MULTISERVICE.PV.1)
  • Add Bedrock inference actions to ExemptedActions
• Custom SCP
  • Manage accounts permitted for Bedrock inference in a list

The advantages of this approach are as follows:

• No need to change the OU structure
• When adding accounts, simply add to the custom SCP list
• If AWS updates exception actions for the OU-level region deny control, they are automatically reflected

We adopted Approach 2 this time.

Solution

OU-Level Managed Region Deny Control

Configure the OU-level region deny control (CT.MULTISERVICE.PV.1) from the Control Tower console.

Add the following Bedrock inference actions to ExemptedActions:

• bedrock:InvokeModel
• bedrock:InvokeModelWithResponseStream

With this configuration, Bedrock inference actions are added to the NotAction (exception actions) of the OU-level region deny control, making them exempt from region deny.

Custom SCP

With only the OU-level region deny control, Bedrock inference would be permitted for all accounts.
To permit Bedrock inference only for specific accounts, apply the following additional custom SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockInferenceExceptAllowRegionSpecificAccounts",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "ap-northeast-3",
            "us-east-1",
            "eu-west-2"
          ],
          "aws:PrincipalAccount": [
            "<permitted account ID>",
            "<permitted account ID>"
          ]
        }
      }
    }
  ]
}

Multiple keys in an SCP Condition are evaluated with AND logic.
This statement behaves as follows:

• Access from permitted regions → Deny is not applied (allowed)
• Access from specified accounts → Deny is not applied (allowed)
• Outside permitted regions AND outside specified accounts → Deny is applied (denied)

When a new account wants to use Bedrock, the operation is to add the account ID to the aws:PrincipalAccount list.

Security Service Considerations

Is it necessary to enable security services for non-managed regions that are only used for cross-region inference?

In conclusion, we believe that introducing and operating security services is unnecessary for regions that are limited to cross-region inference use.

The reasons are as follows:

• Config
  • Since no resource changes occur with inference-only usage, there are no monitoring targets
• CloudTrail
  • Bedrock API call history is recorded in the calling region (such as Tokyo), so it can be captured by the managed region's CloudTrail
• GuardDuty
  • Valid use cases are limited for environments that only use cross-region inference

Additionally, there is no need to expand the Control Tower landing zone managed regions to all commercial regions.
Since Control Tower currently has no controls (preventive or detective) related to cross-region inference, expanding the managed regions would not apply any effective controls.

If it becomes necessary in the future to operate resources in non-managed regions, it would be appropriate to expand the landing zone target regions at that time and enable security services.

Closing

I explained how to make Control Tower's region deny settings and Bedrock's cross-region inference coexist.

The key point is to use the OU-level managed region deny control (CT.MULTISERVICE.PV.1) together with a custom SCP, and manage accounts permitted for Bedrock inference in a list.

Going forward, services that require access to non-managed regions may increase, not limited to cross-region inference.
I hope this design pattern serves as a useful reference.

That's all from Yoshida of the Cloud Business Division!

References

• ※1 Cross-region inference - Amazon Bedrock
• ※2 Two types of region deny controls configurable in Control Tower (per landing zone or per OU) | DevelopersIO
• ※3 OU-level region deny control - AWS Control Tower
• Regions and models supported by inference profiles - Amazon Bedrock
• Enable Amazon Bedrock cross-region inference in multi-account environments | AWS Blog