Setting Up Cross-Region Inference on Bedrock

Cross-region inference is a one-word change to your model id that moves your traffic onto a different, larger quota. It is also the change most likely to work in a notebook and fail in production, because the IAM policy that covered the foundation model no longer covers where the request ends up.

What an inference profile is

An inference profile is a Bedrock resource that names a foundation model and a set of AWS Regions requests may be routed to. You do not create the common ones; AWS publishes system-defined profiles per model per geography, and they show up in your account as ARNs of the form arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0.

Two things about that ARN are load-bearing. It carries your account ID, unlike a foundation-model ARN which has an empty account field — the profile is a resource in your account even though you did not make it. And the identifier is the base model id with a geography prefix: us., eu., apac., or global. for the worldwide profile. That prefix is the entire user-facing surface of the feature.

The profile decides where compute happens, not where your data lives. AWS states that with a geographic profile your data remains stored in the source Region by default, though prompts and outputs may move within the geography during inference, and that where a model requires storage for abuse detection, inputs and outputs are stored in the destination Region. Traffic between Regions stays on the AWS network and is encrypted in transit.

Calling one

There is no new API. You put the profile ID where the model ID went, for InvokeModel, InvokeModelWithResponseStream, Converse and ConverseStream alike:

# before
modelId = "anthropic.claude-sonnet-4-5-20250929-v1:0"

# after
modelId = "us.anthropic.claude-sonnet-4-5-20250929-v1:0"

The same substitution works in several places that are easy to forget because they are not runtime calls: modelId on CreateModelInvocationJob for batch inference, foundationModel on CreateAgent, the generation model on a knowledge base query, and model evaluation jobs. If you moved your synchronous path onto a profile and left a nightly batch job on the bare model id, the batch job is still competing for the smaller quota.

To see which Region actually served a request, read CloudTrail: AWS documents the field as additionalEventData.inferenceRegion, logged in your source Region. That is also the answer to “did cross-region inference actually engage”, which is otherwise invisible.

The IAM statement people miss

This is the failure. Allowing bedrock:InvokeModel on the profile ARN is necessary and not sufficient. AWS documents that you must also allow the action on the foundation model in the source Region and in every destination Region the profile can route to — three resources for a two-line change.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeTheProfile",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
    },
    {
      "Sid": "InvokeTheModelInEveryDestination",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
        "arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
        "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
      ],
      "Condition": {
        "StringEquals": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    }
  ]
}

The bedrock:InferenceProfileArn condition is what stops the second statement from being a blanket grant to call that model directly in three Regions. Without it you have widened access further than you meant to; with it, the foundation-model permission only applies when the call arrived through that specific profile.

Service control policies bite here for the same reason and are harder to see. An SCP that restricts aws:RequestedRegion to the Regions your organisation uses will break routing to any destination Region it excludes, even though your own call was made in an allowed Region. AWS is explicit that blocking any destination Region in the profile prevents cross-region inference from working. If the profile for your source Region lists three destinations, all three have to be permitted.

Why throughput goes up

The reason to do this at all is that profile traffic is measured against different quotas. AWS documents the geographic profile quotas as Cross-region model inference requests per minute for {Model} and Cross-region model inference tokens per minute for {Model}, separate entries in Service Quotas from the on-demand per-model limits your bare model id was hitting.

So the mechanism is not that AWS gives you a bigger number for the same pool. It is that you are drawing on the pooled capacity of several Regions instead of one, and the quota entry reflects that. It follows that cross-region inference helps with ThrottlingException caused by your own steady-state volume, and helps less with a spike that would blow through any per-minute limit.

Cost does not change for the routing itself. AWS states there is no additional routing charge and that the price is calculated from the Region you call the profile from — so a request served in us-west-2 because you called from us-east-1 is billed at us-east-1 rates. There is one exception, below. Provisioned Throughput and inference profiles do not combine: AWS documents that inference profiles do not support Provisioned Throughput.

Geographic or global

A geographic profile keeps processing inside a boundary — US, EU, APAC. A global profile may route to any supported commercial Region worldwide. AWS documents approximately 10% savings for global profiles against standard pricing, which is the only case where the prefix you chose changes what you pay.

• Pick geographic when a data-residency commitment exists. It is the only one of the two you can describe to an auditor as bounded.
• Pick global when there is no such commitment and you want the discount and the widest capacity pool.
• The SCP conditions differ. Geographic profiles need each destination Region allowed. AWS documents that global profiles need "aws:RequestedRegion": "unspecified" allowed instead, which is not something an existing region-lockdown SCP will have.

One last practical note: cross-region inference can route to Regions that are not enabled in your account, and AWS says manual Region enablement is not required. That surprises people who assume an opt-in Region has to be switched on first. It does not — but the SCP still has to allow it.