Amazon Bedrock cross-region inference gives you higher effective throughput and fewer regional throttling errors at no routing surcharge, which is close to free resilience. The trap is that a global inference profile can send your prompt to whichever region has capacity, and if that prompt carries regulated data, "wherever there is capacity" is not an answer your compliance team will accept. The feature is genuinely useful. Whether it is a win or a violation depends entirely on which kind of inference profile you pick, and that choice is easy to make without reading what it means.

The appeal is real. A single-region model call is capped by that region's capacity and its per-region throttling limits. Cross-region inference lets Bedrock spread requests across regions, so a spike that would have thrown throttling errors in one region gets absorbed. You get better tail latency and fewer 429s without paying a premium for the routing itself. The question is not whether that helps. It is where your data is allowed to go while it helps.

Two profiles, two very different promises

Bedrock gives you two flavors of cross-region inference, and the gap between them is the whole article:

  • Geographic profile. Routing is confined to a named geography, such as US or EU. Bedrock picks the best region within that boundary, so an EU geographic profile keeps processing inside EU regions. This is the one you choose when you have data residency requirements.
  • Global profile. Routing is unconstrained for maximum throughput and cost efficiency. Bedrock sends the request to the best available commercial region anywhere. This is the one that can move a European user's prompt to a region outside Europe.

Both improve resilience. Only one respects a geographic boundary. Picking the global profile because it advertises the best throughput, without checking what data flows through it, is how a throughput optimisation becomes a residency incident.

Residency is about the prompt, not just the store

Teams that carefully keep their database in the EU sometimes forget that an inference call ships data too. The prompt is data. If it contains personal data, customer records, or anything a regulation pins to a geography, then the region that processes that prompt is in scope for residency, exactly like the region that stores it. A global profile that relays that prompt to another continent for processing has moved regulated data across a border, even though nothing was "stored" there. The residency question follows the data through inference, not only into the database.

How to decide, per workload

This is not one setting for the whole account. It is a per-workload call, and the deciding question is what the prompt carries:

Does the prompt contain data bound to a geography?
  yes -> geographic profile, matched to the required region
         (accept the capacity ceiling of that geography)
  no  -> global profile is fine
         (take the throughput and resilience, no residency risk)

A workload processing regulated European data uses an EU geographic profile and lives with being capped to EU capacity, because the alternative is non-compliant however fast it is. A workload on non-sensitive data, internal tooling, public content, synthetic prompts, can take the global profile and enjoy the resilience with nothing at risk. The pricing is calculated from the region you call from in either case, so this is a compliance decision, not a cost one.

The takeaway

Cross-region inference is cheap resilience when you match the profile to the data. A geographic profile keeps processing inside a boundary and is the correct default for anything touching regulated data, at the cost of that geography's capacity ceiling. A global profile gives you the best throughput and is fine for data with no residency constraint. The trap is not the feature, it is choosing the global profile by reflex because it sounds faster, and discovering later that "best available region" quietly relayed regulated prompts across a border. Decide per workload, and let what the prompt carries pick the profile.

Read this next

For the multi-region architecture and data-residency playbook across AWS, the cloud field notes live at ercan.cloud, and the hub is at ercanermis.com.