Amazon Bedrock Cross-Region Inference and Data Residency Design - Geographic Inference Profiles, SCP and IAM Alignment, and Region-Contained RAG

First Published: 2026-07-13
Last Updated: 2026-07-13

Two production requirements that look unrelated actually meet at the same mechanism in Amazon Bedrock. The first is throughput: a single Region cannot always absorb bursty generative AI traffic, so you want Bedrock to spread inference across several Regions. The second is data residency: a regulator or an internal policy requires that processing for a given workload stay inside a defined geography, such as the European Union. Both of these are decided by the same object — the cross-Region inference profile — and getting one right without breaking the other is where most designs go wrong.

This is a Level 400 implementation guide. It defines one named reference architecture, an in-geography generative AI service platform, and follows a single request through it end to end: from an application inside an in-geography Region, through an interface VPC endpoint, into a geographic inference profile that routes only within that geography, past the two authorization layers that must agree (Service Control Policies and IAM), to a Region-contained knowledge base and a cross-Region guardrail profile. The hardest and least-documented part — the interaction between organization-wide SCP Region controls and IAM inference-profile permissions — gets a dedicated section, because a mismatch there produces AccessDenied errors that are notoriously hard to attribute.

A note on scope and honesty up front. This guide does not tell you that a particular configuration "makes you compliant" with any regulation. Compliance is a legal determination about your specific obligations. What this guide does is separate two things cleanly: what Amazon Bedrock's documentation actually guarantees about where data goes, and what you as the builder still have to verify and configure. Throughput optimization techniques beyond routing are delegated to a focused throughput guide, organization-wide governance to a security and governance guide, and guardrail policy internals to a guardrails deep dive. Prices are never discussed here; cost characteristics are described qualitatively and you are pointed to the official pricing page.

1. Introduction

Cross-Region inference (often abbreviated CRIS, for cross-Region inference service) is an Amazon Bedrock capability that distributes model inference across multiple AWS Regions so you can absorb traffic bursts and reach higher throughput than a single Region provides. You do not orchestrate the distribution yourself. Instead, you invoke an inference profile — a Bedrock resource that names a foundation model and the set of Regions it may route to — and Bedrock picks a destination for each request.

Two terms recur throughout this guide, so pin them down now:

Source Region — the Region from which you make the API call that specifies the inference profile. This is where your application, your CloudTrail trail, your knowledge bases, and your logs live.
Destination Region — a Region to which Bedrock may route the request for the transient work of inference.

The reason cross-Region inference intersects with data residency is that Bedrock offers two kinds of inference profile, and they answer the residency question differently:

Geographic cross-Region inference keeps routing within a defined geography — US, EU, APAC, Australia, Japan, and others. A request that originates in the EU is routed only to EU Regions. This is the profile type built for data-residency requirements.
Global cross-Region inference routes to supported commercial Regions worldwide for the highest available throughput, and carries a lower per-token rate than the in-geography path. It is built for workloads that do not have geographic-boundary requirements.

That single choice — geographic versus global — is the fork in the road for a residency-sensitive design, and it changes both the routing behavior and the SCP and IAM you must write. The rest of this guide is about building the geographic path correctly and understanding exactly what it does and does not promise.

For the components that surround inference — how a knowledge base is designed, how retrieval quality is engineered, how errors and throttling are handled — this guide links out rather than repeating. The retrieval and RAG architecture is covered in the Production RAG Architecture on Amazon Bedrock guide; throttling symptoms and retry design are covered in the Amazon Bedrock Errors and Exceptions Reference; guardrail policy design is covered in the Responsible AI and Guardrails Architecture on AWS guide.

2. The Reference Architecture at a Glance

The reference architecture in this guide is deliberately narrow: a service that must serve generative AI responses to users in a single geography while keeping stored data inside that geography and still surviving traffic spikes. Call it the in-geography generative AI service platform. Here is the shape of it.

In-geography generative AI service platform reference architecture on Amazon Bedrock

Reading the diagram from the application outward:

The application tier runs inside an in-geography source Region (for an EU deployment, a Region such as Frankfurt or Ireland). It holds no Bedrock model itself; it calls Bedrock.
The call leaves the application's private subnets through an interface VPC endpoint for bedrock-runtime (and, for retrieval, bedrock-agent-runtime), so the request to Bedrock never traverses the public internet from the source Region.
The application specifies a geographic inference profile (an eu.* profile for an EU deployment) as the model ID. Bedrock routes the transient inference to one of the destination Regions inside that geography.
Retrieval is served by a Region-contained knowledge base: an Amazon Bedrock knowledge base whose S3 data source and vector index live in the source Region. Response generation on top of the retrieved context can itself use the geographic inference profile.
Safety evaluation is served by a cross-Region guardrail profile so that guardrail policy evaluation also scales across the geography rather than bottlenecking in one Region.
The whole thing is fenced by AWS Organizations Service Control Policies and IAM working together: the SCP defines which Regions the organization permits at all, and IAM defines which principals may invoke which profiles and models.

The two control planes deserve emphasis because they are the source of most operational pain. The SCP is an organization-wide guardrail: it can deny actions in Regions your organization does not use. IAM is a per-principal grant: it says this role may invoke this profile and these models. For cross-Region inference these two must be reconciled deliberately, because the set of Regions a profile can route to is larger than the single Region your application calls from. Section 5 is entirely about that reconciliation.

Everything in this architecture is a managed capability. You are not running model servers, you are not building your own cross-Region router, and you are not operating a replication pipeline for inference. That is the design principle throughout: minimize operational surface by using managed routing, managed knowledge bases, and managed guardrails, and spend your engineering effort on getting the authorization and data-placement boundaries correct.

It helps to hold the whole thing in one table, mapping each component to what it does and where its data lives. This is the residency ledger for the architecture, and Section 4 justifies each row:

Component	Responsibility	Where its data lives
Application tier	Accepts user requests, calls Bedrock through a VPC endpoint	Source Region
Interface VPC endpoint	Private path from the app to Bedrock, off the public internet	Source Region
Geographic inference profile	Routes the transient inference within the geography	Source Region call; transient compute in an in-geography destination Region
Knowledge base + S3 source + vector index	Stores and retrieves the corpus for RAG	Source Region (at rest)
Cross-Region guardrail profile	Distributes guardrail policy evaluation across the geography	Source Region call; evaluation in in-geography destination Regions
SCP (Organizations) + IAM	Authorize the union of source and destination Regions	Control plane (no request data)
CloudTrail + invocation logs	Audit record of every request	Source Region

3. How Cross-Region Inference Profiles Work

3.1 System-defined profiles and the geography prefix

The profiles you use for cross-Region inference are system-defined: Amazon Bedrock creates them, names them after the model and the geography they serve, and fixes their destination-Region set. You reference one by passing its ID as the modelId in your inference call. The ID carries the geography as a prefix:

A US geographic profile looks like us.anthropic.claude-sonnet-4-5-20250929-v1:0.
An EU geographic profile looks like eu.anthropic.claude-sonnet-4-5-20250929-v1:0.
A global profile looks like global.anthropic.claude-sonnet-4-5-20250929-v1:0.

The examples in this guide use Claude Sonnet 4.5 (anthropic.claude-sonnet-4-5-20250929-v1:0), which is the model ID that AWS's own cross-Region inference documentation uses in its worked examples. Substitute the profile ID for whichever current-generation model you actually run — the us./eu./global. prefix rules and the SCP/IAM patterns in this guide apply unchanged to current-generation models such as Claude Sonnet 5 and Claude Opus 4.8 (for example, us.anthropic.claude-opus-4-8). The exact profile IDs, supported source Regions, and destination Regions for any model are documented on that model's detail page in the Bedrock console and API; do not copy a Region matrix from a blog post, because that data moves.

There is an important stability difference between the two profile types. A geographic profile's destination-Region list never changes — once a profile is tied to a geography, AWS does not silently add a Region outside that geography to it. A global profile's destination set can grow over time as AWS adds commercial Regions. If your design depends on knowing exactly which Regions can process a request, that stability guarantee is a reason to prefer the geographic profile, independent of the throughput and rate differences.

It is worth naming the full taxonomy, because a model's detail page lists it as three scopes and you will choose among all three. A model's Regional availability table shows In-Region, Geographic (Geo), and Global inference profiles. An In-Region profile gives you the inference-profile interface but routes only within a single Region — there is no cross-Region hop, so it is the profile-shaped way to express "process in exactly this Region." Geographic keeps routing within a geography, and Global routes worldwide. Mapping these back to residency: In-Region is the strictest (single Region), Geographic is the geography-boundary choice this guide builds on, and Global trades the boundary for maximum throughput. Choosing a scope is therefore choosing a residency posture, and the profile ID prefix (or its absence, for In-Region) tells you at a glance which one a piece of code is using.

3.2 What routing actually does, and why it raises throughput

When you invoke a geographic inference profile, your request originates in the source Region and Bedrock automatically routes it to one of the destination Regions defined in that profile, choosing for performance. The routed work is the inference computation itself — the transient forward pass through the model. It travels over the AWS global network managed by Bedrock, encrypted in transit, and the encrypted response returns to your application in the source Region.

The throughput benefit follows directly. A single Region has finite serving capacity for a given model, and a burst that exceeds it produces ThrottlingException. By letting Bedrock spread requests across several Regions' capacity for the same model, a cross-Region profile smooths bursts that would throttle a single Region. This is the mechanism, not a tuning knob: you get the benefit simply by invoking the profile instead of invoking the model directly in one Region. Provisioned Throughput, latency-optimized inference, and prompt caching are separate throughput and latency levers and are covered in the throughput optimization guide; here the relevant point is only that routing itself is a throughput mechanism.

Some profiles route to a different destination set depending on which source Region you call them from. For example, a US profile called from Ohio may be able to route to us-east-1, us-east-2, or us-west-2, while the same profile called from Oregon may route to only us-east-1 and us-west-2. This matters for both your SCP and your IAM, because the exact destination set you must authorize depends on your source Region.

3.3 Where you can use an inference profile

A cross-Region inference profile is not limited to a raw model call. You specify the profile ID in place of a model ID across Bedrock:

On-demand inference — pass the profile ID as modelId to InvokeModel, InvokeModelWithResponseStream, Converse, or ConverseStream.
Batch inference — pass the profile ID as modelId to CreateModelInvocationJob; output files land in the S3 bucket in your source Region.
Agents — set the profile ID in the foundationModel field of CreateAgent.
Knowledge base response generation — use the profile when generating an answer from retrieved context.
Model evaluation, Prompt management, and Prompt flows — the profile can serve as the model in each.

This breadth is what makes the geographic profile a residency control surface and not just a throughput trick: the same in-geography routing applies whether the request is a chat completion, a batch job, an agent step, or a RAG answer.

3.4 Confirming a profile's destination Regions

Because the destination set drives your SCP and IAM, you should confirm it rather than assume it. Two reliable ways:

Read the model's detail page (its Regional availability table lists the In-Region, Geo, and Global profile IDs and the Regions each covers).
Call GetInferenceProfile against a Bedrock control-plane endpoint from your source Region, passing the profile ARN or ID; the models field in the response lists model ARNs from which you can read each destination Region.

aws bedrock get-inference-profile \
  --region eu-central-1 \
  --inference-profile-identifier eu.anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --query 'models[].modelArn'

Treat the output of that call as the authoritative destination list for the profile in your source Region, and write your SCP and IAM against it.

3.5 Choosing between geographic and global

The decision between the two profile types is the single most consequential one in this design, because it sets both your residency posture and the shape of your policies. AWS frames the trade-off directly, and the residency requirement usually decides it:

Dimension	Geographic cross-Region inference	Global cross-Region inference
Data residency	Processing stays within a geographic boundary (US, EU, APAC, and others)	Any supported commercial Region worldwide
Throughput	Higher than a single Region	Highest available
Per-token rate	Standard rate	Lower than the in-geography path (see the pricing page)
Destination stability	Fixed — the destination list never changes	Can grow as AWS adds commercial Regions
SCP requirement	Allow all destination Regions in the profile	Allow `aws:RequestedRegion: "unspecified"`
Best suited for	Workloads with data-residency requirements	Workloads prioritizing cost and maximum throughput

Read that table as a rule, not a menu: if you have a residency requirement, choose geographic and accept the standard rate; if you do not, global gives you the most headroom at a lower rate. There is also a third option that this guide keeps in view precisely because it is sometimes the right answer — not using cross-Region inference at all. If your obligation names one specific Region and forbids processing anywhere else, then even the in-geography routing of a geographic profile is too broad, and you should invoke the model directly in that single Region (accepting that single-Region capacity is your throughput ceiling). Cross-Region inference is the tool for "stay within a geography," not "stay in exactly one Region."

4. What Data Goes Where

This is the section to read slowly, because it is where residency claims are most often overstated. The honest statement has two halves: what stays put, and what may move.

4.1 What stays in the source Region

Cross-Region inference does not relocate your stored data. Data at rest — model invocation logs (when you enable model invocation logging), knowledge bases, and stored configurations — remains in the source Region. If you enable invocation logging, logs are published to CloudWatch Logs or Amazon S3 in the same Region you called from. CloudTrail records every cross-Region inference request in your source Region. The transient inference computation is the only thing that runs in a destination Region, and no customer data is stored in a destination Region as a result of ordinary cross-Region routing.

For a geographic profile, the destination Region is always inside the same geography, so even the transient computation stays within the geographic boundary. That is the property that makes the geographic profile the residency-oriented choice.

4.2 What may move, and the abuse-detection exception

Here is the part that a careless design ignores. Amazon Bedrock's own documentation for geographic cross-Region inference states it plainly: by default the data remains stored only in the source Region, but your input prompts and output results might move outside of your source Region during cross-Region inference, and to the extent Bedrock stores data for abuse detection, your input prompts and output results will be stored in the destination Region. For a geographic profile that destination Region is still inside the geography; the point is that "stays in the source Region" is not the same statement as "stays in the geography," and the honest version is the latter.

Whether any storage happens at all depends on the model, because Bedrock's default posture is strong:

Bedrock uses a zero operator access model — service operators cannot access model inputs or outputs.
Bedrock uses a zero data retention default — by default it does not store model inputs or outputs.

Storage for abuse detection is an exception applied to specific models, not the norm. As documented, for OpenAI GPT-5.4 and GPT-5.5 it is classifier-flagged traffic that is retained (up to 30 days for offline abuse detection). Anthropic Claude Fable 5 and Claude Mythos 5 go further: both require the provider data share retention mode — inputs and outputs are retained up to 30 days and shared with the model provider for trust-and-safety purposes, and you must explicitly opt in (by setting your account or project data retention mode) before either model becomes available. For any model that does require retention, if cross-Region inference is enabled the retained inputs and outputs are stored in the destination Region that processed the request. Eligible customers may be able to request full zero data retention for such models through their AWS account team.

There is a further nuance for opt-in destination Regions. A cross-Region inference profile's destination set can include opt-in Regions — Regions you must explicitly enable at the account or Organization level. When you use a profile, a request can be routed to a destination Region in the profile even if you did not opt that Region in for your account, and input prompts and output results may be stored in an opt-in Region for abuse-detection purposes. This is another reason the destination set is a first-class part of your residency reasoning, not a detail.

4.3 The EU boundary is narrower than "Europe"

For an EU deployment specifically, the geographic boundary of EU cross-Region inference is the European Union, and it is narrower than a casual reading of "European Regions." EU cross-Region inference routes only among EU Regions. Regions such as London and Zurich are treated as outside the EU boundary: a request from an EU source Region is not routed to London or Zurich, and conversely a request originating in London is routed only among EU Regions plus London itself, while a request originating in Zurich is routed only among EU Regions plus Zurich itself. If your obligation is "process inside the EU," the EU geographic profile expresses exactly that; if your obligation names a specific single Region, cross-Region inference is the wrong tool and you should invoke the model directly in that Region instead.

4.4 The honest summary

Put together, the residency picture for a geographic profile is:

Data category	Where it lives with a geographic profile
Stored data (knowledge bases, invocation logs, configuration)	Stays in the source Region
Transient inference computation	A destination Region within the geography
Abuse-detection storage (model-dependent)	A destination Region within the geography — only for models that require retention (default: none)
CloudTrail record of the request	The source Region

So the defensible sentence is not "this configuration makes my workload compliant." It is: "with a geographic profile, stored data stays in the source Region, all processing stays within the geography, and any model-specific abuse-detection storage stays within the geography — and I have verified my chosen model's retention behavior and destination-Region set against the model's documentation." What compliance requires on top of that is yours to determine.

5. SCP and IAM Alignment

This is the most important section in the guide, because it is where cross-Region inference most often fails in ways that are hard to diagnose. The core fact: invoking a profile requires permission for every Region the profile may route to, not just the Region you call from. Two authorization layers must agree — Service Control Policies at the organization level and IAM at the principal level — and a mismatch in either produces AccessDenied.

End-to-end request flow with SCP and IAM evaluation points and geographic routing

5.1 The IAM policy for a geographic profile

To let a principal invoke a geographic inference profile, IAM must allow access to three resources:

the geography-specific inference profile (the resource whose ID carries the us, eu, or apac prefix),
the foundation model in the source Region, and
the foundation model in all destination Regions listed in the geographic profile.

The following is the policy AWS documents for a US geographic profile with source Region us-east-1 and destination Regions us-east-1, us-east-2, and us-west-2:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GrantGeoCrisInferenceProfileAccess",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
      ]
    },
    {
      "Sid": "GrantGeoCrisModelAccess",
      "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:<ACCOUNT_ID>:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    }
  ]
}

Two things to notice. First, the second statement lists the foundation-model ARN in each destination Region, not just the source Region — this is the step people miss, and omitting a destination Region here is the single most common cause of intermittent AccessDenied. Second, the bedrock:InferenceProfileArn condition key scopes the model grant so the destination-model access is only usable through the intended profile; without it you would be granting broader direct model access than you want. Use the condition to tie the model permissions to the specific profile.

For an EU deployment, the shape is identical but the profile prefix is eu and the destination-Region list is the EU set for your source Region. Because that set is model-specific, read it from the model's detail page or from GetInferenceProfile (Section 3.4) and enumerate exactly those Regions in the second statement. The following shows the EU shape; the destination Regions in it are illustrative and you must replace them with the exact set your model reports:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GrantEuGeoCrisInferenceProfileAccess",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:eu-central-1:<ACCOUNT_ID>:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0"
      ]
    },
    {
      "Sid": "GrantEuGeoCrisModelAccess",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
        "arn:aws:bedrock:eu-west-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
        "arn:aws:bedrock:eu-west-3::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
      ],
      "Condition": {
        "StringEquals": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:eu-central-1:<ACCOUNT_ID>:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    }
  ]
}

Do not ship this policy with the three Regions shown; run GetInferenceProfile against eu.anthropic.claude-sonnet-4-5-20250929-v1:0 in your source Region and list every destination Region it returns. An EU profile can route to more EU Regions than the three above, and any omitted Region becomes an intermittent AccessDenied the first time Bedrock picks it.

5.2 The IAM policy for a global profile

A global profile needs a three-part policy because a global request may be processed anywhere. The difference from the geographic policy is the third statement, which grants access to the global foundation-model resource — the ARN with no Region — gated by the condition aws:RequestedRegion equal to unspecified:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GrantGlobalCrisInferenceProfileRegionAccess",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    },
    {
      "Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
      ],
      "Condition": {
        "StringEquals": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    },
    {
      "Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "unspecified",
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    }
  ]
}

The residency implication is visible right in the policy: the global policy authorizes an unregioned, "anywhere" model resource, while the geographic policy authorizes a specific enumerated list of Regions. If your design has a residency requirement and you find aws:RequestedRegion: unspecified in your policy, that is a red flag — it means you are on the global path, not the geographic one.

5.3 How SCPs interact with the profile

Service Control Policies and IAM work together, and they do so with an important asymmetry: an SCP can only remove permissions, never grant them, so a request must be allowed by both the SCP and IAM to succeed. For cross-Region inference the failure mode is specific and worth memorizing: if any destination Region in a profile is blocked by an SCP, the request fails even if every other Region is allowed. Bedrock may try to route to the blocked Region, and the SCP denies the action there.

Many organizations run a "deny unused Regions" SCP for security and compliance. If that SCP blocks a Region that happens to be in your inference profile's destination set, cross-Region inference breaks. The fix is not to weaken the Region restriction globally; it is to carve out the Bedrock inference actions for the profile. One valid SCP pattern, built from the condition keys AWS documents for cross-Region inference, denies a Region broadly but excepts the specific inference profile:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySpecificRegionAllowCRI",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-2"
        },
        "ArnNotLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    }
  ]
}

This denies everything in us-east-2 except actions made through the named inference profile. It is a deny-based statement and is meant to sit alongside your allow policies, not replace them. The general rule for aligning the two layers: the SCP must permit the Bedrock inference actions (for example bedrock:InvokeModel* or bedrock:CreateModelInvocationJob) in all destination Regions of the profiles you use. For a geographic profile, that means allowing all the in-geography destination Regions; for a global profile, that means allowing aws:RequestedRegion: unspecified.

Two practical notes. First, prefer the bedrock:InferenceProfileArn condition in SCPs as well as IAM, so you open the destination Regions only for the specific profiles you intend, not for arbitrary Bedrock use. Second, service-linked roles are not affected by SCPs, so if a service integration that uses a service-linked role works while your application role does not, that difference points you straight at an SCP problem on your application role.

The carve-out above is the pattern for a deny-based SCP, which is the common shape of a "deny unused Regions" control. If instead your organization runs an allow-list SCP — deny by default and explicitly permit only sanctioned actions — the correction is symmetric: the allow list must include the Bedrock inference actions across the profile's destination Regions. A compact allow statement, scoped to the profile with the same condition key, looks like this:

{
  "Sid": "AllowGeoCrisInferenceActions",
  "Effect": "Allow",
  "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": [ "eu-central-1", "eu-west-1", "eu-west-3" ],
      "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0"
    }
  }
}

Whichever shape your organization uses, the requirement is the same and it is the crux of this whole section: the SCP layer and the IAM layer must both permit the Bedrock inference actions in every destination Region the profile can route to. If you manage your organization with AWS Control Tower, treat the Region-deny controls as the thing to reconcile against your profiles, because those are the guardrails most likely to block a destination Region silently. Confirm the destination set with GetInferenceProfile and reconcile both layers against that list, not against your source Region alone.

5.4 Diagnosing AccessDenied

When a cross-Region invocation returns AccessDenied, the fastest path to the cause is to ask which layer and which Region:

Symptom	Likely cause	Where to look / fix
Every invocation of the profile fails with AccessDenied	IAM does not grant the inference-profile resource, or the source-Region model	Confirm statement 1 (profile ARN) and the source-Region model ARN are present in the principal's IAM policy
Invocations fail intermittently, some succeed	IAM (or SCP) is missing one destination Region; failures happen only when Bedrock routes to the missing Region	Enumerate all destination Regions from GetInferenceProfile and ensure each destination-Region model ARN is allowed in IAM and each Region is allowed in the SCP
Same policy works in one account, fails in another	An SCP attached to the failing account's OU blocks a destination Region	Review the SCPs on the failing account's OU path; add the DenySpecificRegionAllowCRI-style carve-out, or allow the inference actions in the blocked destination Region
A service integration works but the app role does not	SCPs do not apply to service-linked roles but do apply to your role	Treat as an SCP issue on the application role's account

The single mental model that prevents most of these: authorize the union of the source Region and every destination Region, in both IAM and SCP, and scope that authorization to the specific profile ARN.

6. Private Connectivity with VPC Endpoints

Keeping the source-Region call off the public internet is done with AWS PrivateLink interface VPC endpoints. Amazon Bedrock exposes several API surfaces, each as its own endpoint service, and you create the interface endpoints for the ones your architecture uses:

Category	Endpoint service suffix	Used for
Bedrock control plane	`bedrock`	Managing models, guardrails, inference profiles (control-plane APIs)
Bedrock runtime	`bedrock-runtime`	Model invocation: `InvokeModel`, `Converse`, and streaming variants
Bedrock Mantle runtime	`bedrock-mantle`	Newer-generation inference APIs (OpenAI-compatible Chat Completions/Responses and Anthropic Messages), recommended by AWS for new applications
Bedrock Agents build-time	`bedrock-agent`	Creating and configuring agents and knowledge bases
Bedrock Agents runtime	`bedrock-agent-runtime`	Retrieval and generation: `Retrieve`, `RetrieveAndGenerate`

For the reference architecture, the application needs at least the bedrock-runtime endpoint (to invoke the inference profile) and the bedrock-agent-runtime endpoint (to query the knowledge base). Create them in the source Region's private subnets, attach a security group that allows TLS only from the application's own security group, and give each endpoint an endpoint policy that scopes what may pass through it.

An endpoint policy on the runtime endpoint is a useful second layer of least privilege — it limits which actions and resources are reachable via that endpoint regardless of the caller's IAM. A minimal example that allows only invocation of the intended model:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<ACCOUNT_ID>:role/app-inference-role" },
      "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ],
      "Resource": [
        "arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
        "arn:aws:bedrock:*:<ACCOUNT_ID>:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0"
      ]
    }
  ]
}

Expressed as infrastructure as code, the runtime endpoint is a small resource. The pattern is one AWS::EC2::VPCEndpoint of type Interface per Bedrock surface you use, each with PrivateDnsEnabled so existing SDK calls resolve to the endpoint automatically:

Resources:
  BedrockRuntimeEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      ServiceName: !Sub com.amazonaws.${AWS::Region}.bedrock-runtime
      VpcEndpointType: Interface
      VpcId: !Ref AppVpc
      SubnetIds: !Ref PrivateSubnetIds
      SecurityGroupIds: [ !Ref EndpointSecurityGroup ]
      PrivateDnsEnabled: true
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              AWS: !Sub arn:aws:iam::${AWS::AccountId}:role/app-inference-role
            Action:
              - bedrock:InvokeModel
              - bedrock:InvokeModelWithResponseStream
            Resource:
              - !Sub arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0
              - !Sub arn:aws:bedrock:*:${AWS::AccountId}:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0

Repeat the resource with ServiceName ending in bedrock-agent-runtime for the retrieval path. Keep both endpoints' security group tight: allow inbound TLS on 443 only from the application's security group, so nothing but your application can even reach the endpoint.

One point that is easy to get wrong conceptually: the interface VPC endpoint secures the call from your application in the source Region to Bedrock. It does not carry the cross-Region hop. When Bedrock routes inference to a destination Region, that traffic travels over the AWS-managed Bedrock network between Regions, not back out through your VPC endpoint. So the VPC endpoint is a source-Region privacy control for the request entering Bedrock; the in-geography property of the cross-Region hop comes from the geographic profile, not from the endpoint. Both matter, and they secure different segments of the path. Organization-wide connectivity governance — centralized endpoint management, DNS strategy, and network perimeter design — is delegated to the security and governance guide.

7. Region-Contained RAG

Retrieval-augmented generation is where residency reasoning gets concrete, because a RAG system stores your actual documents. The design goal is that the corpus, the vector index, and the retrieval all stay in the source Region, while generation on top of the retrieved context uses the geographic inference profile so it too stays in-geography.

Amazon Bedrock Knowledge Bases is the managed RAG service that makes this practical. A knowledge base fetches from an S3 data source, parses and chunks the content, generates embeddings, and stores them in a vector index — and all of those resources live in the Region where you create the knowledge base. Bedrock Knowledge Bases supports several vector stores, including Amazon OpenSearch Serverless, Aurora PostgreSQL with pgvector, Amazon Neptune Analytics, and Amazon S3 Vectors; the choice among them is a scale, latency, and operational-model decision that is delegated to a vector database selection guide. For residency, the relevant property is shared by all of them: the vector store is a resource in your source Region, so the embeddings — which are derived from your documents — stay in the source Region.

The one place inference enters RAG is response generation. When you call RetrieveAndGenerate, retrieval runs against the in-Region vector store and generation runs against a model. Point that generation at the geographic inference profile, and the generation step inherits the in-geography routing while retrieval stays entirely in the source Region:

import boto3

agent_rt = boto3.client("bedrock-agent-runtime", region_name="eu-central-1")

resp = agent_rt.retrieve_and_generate(
    input={"text": "What is our data retention policy for EU customers?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "KB123456",
            # Point generation at the EU geographic inference profile:
            "modelArn": "arn:aws:bedrock:eu-central-1:<ACCOUNT_ID>:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
    },
)
print(resp["output"]["text"])

If your service must be available in more than one geography — say an EU deployment and a separate US deployment — the pattern is to run one Region-contained knowledge base per geography rather than a single global one, each ingesting from a data source in its own geography and each generating through its own geographic profile. That keeps every geography's corpus and processing inside its boundary. The cost of that pattern is replication: the same source documents must be ingested into each geography's knowledge base, and those copies drift if you do not keep them in sync. Ingestion mechanics, sync strategies, S3 metadata design, and tenant isolation for knowledge bases are delegated to a knowledge bases ingestion and isolation guide; the residency-relevant point here is only that the per-geography knowledge base is what keeps retrieval in-geography, and that its sync state becomes something you must monitor (Section 9).

The IAM principle from Section 5 applies to retrieval too: the role that calls RetrieveAndGenerate needs bedrock:Retrieve and bedrock:RetrieveAndGenerate on the knowledge base, plus the inference-profile and destination-model grants for whatever profile you use for generation. A minimal retrieval grant looks like this, and it composes with the inference-profile statements from Section 5 rather than replacing them:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "QueryRegionContainedKnowledgeBase",
      "Effect": "Allow",
      "Action": [ "bedrock:Retrieve", "bedrock:RetrieveAndGenerate" ],
      "Resource": "arn:aws:bedrock:eu-central-1:<ACCOUNT_ID>:knowledge-base/KB123456"
    }
  ]
}

To make the multi-geography topology concrete: an EU-and-US service runs two independent stacks. The EU stack has an application in an EU source Region, an EU knowledge base whose corpus and vector index sit in the EU, and generation through an eu.* profile; the US stack mirrors that with a US source Region, a US knowledge base, and a us.* profile. Neither stack's corpus ever leaves its geography, and a user is served entirely by the stack for their geography. The operational price is that the same source documents are ingested twice — once per geography — so a document update is not one write but a fan-out to every geography's knowledge base, and the ingestion status of each becomes a thing you monitor (Section 9.4). This is the deliberate trade the residency requirement imposes: you accept duplicated ingestion and per-geography operations in exchange for a hard corpus boundary, instead of a single global index that would be simpler to run but would place one geography's documents outside its boundary.

8. Cross-Region Guardrail Profiles

Guardrails need the same cross-Region treatment as inference, for the same reason: a single Region's guardrail evaluation capacity can bottleneck under load, and some guardrail capabilities require cross-Region inference to be enabled at all. Bedrock provides this through a guardrail profile — a system-defined resource, analogous to an inference profile, that defines the source and destination Regions across which guardrail policy evaluation may be distributed.

You attach a guardrail profile when you create or modify a guardrail, via the console or by passing it in CreateGuardrail or UpdateGuardrail (in AWS CloudFormation and CDK this is the crossRegionConfig property). The profile IDs follow a geography convention that mirrors inference profiles — for the EU boundary the profile is eu.guardrail.v1:0, and its ARN is arn:aws:bedrock:<source-region>:<account-id>:guardrail-profile/eu.guardrail.v1:0. The EU guardrail profile keeps evaluation within EU Regions; for an EU source Region its destination Regions are the EU set (eu-central-1, eu-west-1, eu-west-3, eu-north-1, eu-south-1, eu-south-2), which keeps guardrail evaluation inside the same geographic boundary as the inference it protects.

The permissions model parallels inference exactly. To invoke a guardrail with cross-Region inference, the calling principal needs bedrock:ApplyGuardrail on the guardrail in the source Region and on the guardrail-profile resource in every destination Region the profile covers:

{
  "Effect": "Allow",
  "Action": [ "bedrock:ApplyGuardrail" ],
  "Resource": [
    "arn:aws:bedrock:eu-central-1:<ACCOUNT_ID>:guardrail/<guardrail-id>",
    "arn:aws:bedrock:eu-central-1:<ACCOUNT_ID>:guardrail-profile/eu.guardrail.v1:0",
    "arn:aws:bedrock:eu-west-1:<ACCOUNT_ID>:guardrail-profile/eu.guardrail.v1:0",
    "arn:aws:bedrock:eu-west-3:<ACCOUNT_ID>:guardrail-profile/eu.guardrail.v1:0"
  ]
}

(Enumerate every destination Region of your guardrail profile, not just the three shown.) If you use resource-based policies on guardrails, those policies must be attached to the profile objects in all destination Regions, because create, edit, and delete operations execute across every Region in the profile.

There is a functional coupling to know about: some guardrail capabilities — the Standard tier of content filters and denied topics, which brings broader language support — require cross-Region inference to be enabled. So on a residency-sensitive workload, choosing the Standard tier is also a decision to run the guardrail across the geography via a guardrail profile, and you must pick the guardrail profile whose source Region matches where your guardrail resides. Guardrail policy design itself — which filters to enable, how to tune thresholds, the ApplyGuardrail API, and detection modes — is delegated to a guardrails implementation deep dive and the Responsible AI and Guardrails Architecture on AWS guide. This guide's contribution is only the residency and permissions alignment: the guardrail profile keeps safety evaluation inside the same geographic boundary as the model routing, and its permissions must enumerate the same kind of destination-Region set that inference does.

9. Failure Modes and Diagnostics

Cross-region designs fail in a small number of characteristic ways. Each is a symptom-to-cause-to-fix chain, and most trace back to the union-of-Regions principle from Section 5.

9.1 SCP and profile mismatch

Symptom — invocations succeed most of the time and fail with AccessDenied some of the time, with no change to the application. Cause — an SCP (or an IAM policy) blocks or omits one of the destination Regions, so failures occur exactly when Bedrock routes to that Region and succeed when it routes elsewhere. Isolation — reproduce with load so routing exercises multiple destinations; list the profile's destinations with GetInferenceProfile; check each destination Region against both the SCP path on the account and the principal's IAM. Fix — allow the Bedrock inference actions in all destination Regions in the SCP (with the profile-scoped carve-out) and add every destination-Region model ARN to IAM.

9.2 Single-Region throttling

Symptom — ThrottlingException under burst, using an In-Region profile or a direct model invocation. Cause — all traffic is concentrated in one Region's capacity for the model. Isolation — confirm the modelId in use is an in-Region ID or a raw model ID rather than a cross-Region profile ID. Fix — switch to a geographic (or global) inference profile so Bedrock distributes across Regions; layer retries with backoff and jitter on top for the residual throttling that any system can hit. Retry design, error taxonomy, and resilience patterns are covered in the Amazon Bedrock Errors and Exceptions Reference and the throughput optimization guide.

9.3 Guardrail Region availability

Symptom — creating or applying a guardrail with a cross-Region profile fails, or a Standard-tier capability is unavailable. Cause — the guardrail profile does not support your source Region, or the guardrail's source Region and the profile are mismatched, or cross-Region inference is not enabled for a capability that requires it. Isolation — verify the guardrail profile that matches your source Region from the guardrail profiles list; confirm the guardrail resides in a supported source Region. Fix — attach the correct geography's guardrail profile for your source Region and enable cross-Region inference for Standard-tier features.

9.4 Knowledge base replication drift

Symptom — the same question returns different or stale answers in different geographies, or a document that was updated shows up in one geography's answers but not another's. Cause — the per-geography knowledge bases are separate copies, and their ingestion is out of sync; one geography's index has ingested a change the other has not. Isolation — compare the last successful ingestion job timestamp and status across the per-geography knowledge bases; identify documents present in one index but not the other. Fix — treat ingestion as an operational SLO: monitor ingestion job status per knowledge base, version your source data, and reconcile on a schedule; on a failed ingestion, re-run and confirm completion before treating the index as current. The blast radius of drift is contained to answer freshness, not correctness of authorization, but for a residency-sensitive service that answers can differ by geography is itself something to surface to users or operators rather than hide.

9.5 The one-line triage

For any cross-Region AccessDenied, ask in order: is the profile ARN allowed in IAM? is the source-Region model allowed? are all destination-Region models allowed? does an SCP on this account block any destination Region? Four questions resolve the large majority of cases.

10. Observability and Audit Hooks

You cannot operate what you cannot see, and cross-Region inference has a specific visibility profile worth understanding.

CloudTrail is the backbone: every cross-Region inference request is logged in your source Region, so your existing source-Region trail already captures the invocations, the principal, and the profile used. That is the record you reach for when reconstructing what happened. If you enable model invocation logging, the logs likewise land in CloudWatch Logs or S3 in the source Region, keeping your inference audit trail in-geography alongside the requests it describes.

Concretely, the invocation events carry an eventSource of bedrock.amazonaws.com, and the profile you called appears in the request parameters as the modelId — so a query that filters events where the model ID begins with eu. gives you the population of requests that went through the EU geographic profile. If you deliver CloudTrail to S3 and query it with Amazon Athena, that filter becomes a one-line predicate and turns "were all inference requests for this workload made through the EU profile?" into an answerable question over a time window, rather than an assertion. Pair that population with the profile's destination set from GetInferenceProfile, and you have both halves of the residency claim: which requests used the profile, and where those requests could have been processed.

For understanding routing, the honest picture is that routing is managed and you reason about it at the profile level, not by expecting a per-request "this went to Region X" field in a simple response attribute. What you can and should do:

Enumerate a profile's possible destination Regions with GetInferenceProfile, and treat that set as the audited boundary of where a request could have been processed.
Use CloudTrail in the source Region as the authoritative record that a request was made through the profile.
Confirm, from the model's documentation, whether the model has any abuse-detection retention, so your audit story about "where data could rest" is accurate rather than assumed.

Together these let you make a defensible statement of the form: "requests for this workload were made through the EU geographic profile, whose destination Regions are the following EU Regions, and the model in use has no abuse-detection retention (or: has retention, stored within the geography)." That is an evidence-backed residency posture rather than a hopeful one. Full observability architecture — metrics, structured invocation-log analysis, distributed tracing, and anomaly detection for Bedrock — is delegated to a monitoring guide, and organization-wide audit and governance is delegated to the security and governance guide. The scope here is only the audit hooks that are specific to cross-Region inference: source-Region CloudTrail, source-Region invocation logs, and the profile's destination set as the boundary of your residency claim.

11. Frequently Asked Questions

Does using a geographic inference profile make my workload compliant with a data-residency regulation?
No — and no configuration can make that claim on its own. A geographic profile gives you a concrete, documented technical property: stored data stays in the source Region, and all processing (including any model-specific abuse-detection storage) stays within the geography. Whether that property satisfies your particular legal obligation is a compliance determination you must make, ideally with the model's documentation and your legal team, not something the profile asserts for you.

What is the practical difference between geographic and global cross-Region inference?
Geographic routes only within a defined geography (US, EU, APAC, and others) and is the choice when you have data-residency requirements; its destination-Region list never changes. Global routes to commercial Regions worldwide for the highest available throughput at a lower per-token rate, and its destination set can grow over time. The difference also shows up in your policies: geographic policies enumerate specific destination Regions, while global policies authorize the unregioned model resource with aws:RequestedRegion: unspecified.

Why do I get AccessDenied only sometimes?
Almost always because your IAM or SCP is missing one of the profile's destination Regions. The failure happens only when Bedrock routes to the Region you did not authorize, so it looks intermittent. Enumerate all destination Regions with GetInferenceProfile and make sure every destination-Region model ARN is allowed in IAM and every destination Region is permitted in your SCPs.

Does the interface VPC endpoint carry the cross-Region hop?
No. The VPC endpoint privately connects your application in the source Region to Bedrock. When Bedrock routes inference to a destination Region, that traffic goes over the AWS-managed Bedrock network between Regions, not back through your VPC endpoint. The endpoint secures the source-Region entry into Bedrock; the geographic profile is what keeps the cross-Region hop inside the geography.

Where does my RAG data live if I generate answers with a geographic profile?
The knowledge base, its S3 data source, and its vector index live in the source Region where you created the knowledge base — retrieval is entirely in-Region. Only the generation step routes cross-Region, and with a geographic profile it stays within the geography. To serve multiple geographies, run one Region-contained knowledge base per geography rather than a single shared one.

Do guardrails also need cross-Region configuration?
If you want guardrail evaluation to scale across the geography, or if you use Standard-tier guardrail capabilities that require cross-Region inference, yes — you attach a guardrail profile (for example eu.guardrail.v1:0) and grant bedrock:ApplyGuardrail on the guardrail in the source Region and on the guardrail-profile resource in every destination Region, exactly mirroring the inference permissions pattern.

12. Summary

Cross-Region inference and data residency are the same design problem viewed from two angles, and the inference profile is where they meet. The in-geography generative AI service platform in this guide ties together an interface VPC endpoint that privately admits the source-Region call, a geographic inference profile that routes the transient computation only within the geography, a Region-contained knowledge base whose corpus and vector index never leave the source Region, a cross-Region guardrail profile that keeps safety evaluation inside the same boundary, and — the load-bearing part — an SCP and IAM alignment that authorizes the union of the source Region and every destination Region, scoped to the specific profile.

The recurring lessons are worth restating. Authorize every Region a profile can route to, not just the one you call from; a missing destination Region is the classic cause of intermittent AccessDenied. Keep the two authorization layers in agreement, because an SCP that blocks a single destination Region breaks the whole profile. Reason about residency at the level of "stays within the geography," not "stays in one Region," and check your chosen model's abuse-detection retention rather than assuming zero. And separate what Bedrock documents from what you must still determine: the technical property is concrete and verifiable, but the compliance conclusion is yours to make. Deep dives on throughput levers, organization-wide governance, guardrail policy internals, vector store selection, and knowledge base ingestion are delegated to focused guides so this one can stay an implementation walkthrough of the residency-and-routing boundary.

For the surrounding building blocks and adjacent topics, see the Production RAG Architecture on Amazon Bedrock for the retrieval and generation architecture this platform builds on, the Amazon Bedrock Errors and Exceptions Reference for throttling symptoms and retry design, the Responsible AI and Guardrails Architecture on AWS for the full guardrails picture, and the Amazon Bedrock Glossary for terminology.

13. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi