9 min read - Cross-Region AI Inference: Put Routing Policy Before Throughput

A model endpoint can sit in Paris while the model call is processed somewhere else. That distinction has just become harder to ignore.

On 20 August 2026, AWS published implementation details for cross-Region inference for OpenAI GPT-5.6 on Amazon Bedrock. The three general-purpose variants—Sol, Terra and Luna—can be invoked from more than 25 AWS Regions. The launch documents a US geographic profile and a global profile. The global profile can route a request to supported commercial Regions worldwide according to available capacity.

This is useful infrastructure. It can also turn a model identifier into a data routing decision that product teams, security, privacy and procurement never explicitly approved. For startups, SMEs and mid-market organisations, the right question is therefore not simply “does global inference improve throughput?” It is “which workloads may use which routing boundary, and what evidence proves that the boundary was respected?”

What changed—and what did not

Amazon Bedrock cross-Region inference uses an inference profile rather than a raw model ID. A source Region receives the API call; Bedrock may then use compute in a destination Region allowed by that profile. AWS describes the mechanism primarily as a way to draw on a larger capacity pool and maintain performance under load.

The distinction between profile types is material:

• a geographic profile limits processing to the Regions defined for that geography;
• a global profile can use any eligible commercial Region for that model.

AWS's cross-Region inference documentation says global requests are routed worldwide, while geographic requests remain inside their defined geography. It also says routing may use Regions that are not manually enabled in the customer's account. A familiar source endpoint is therefore not evidence of the final processing location.

Availability is model-specific. Although Bedrock supports geographic profiles such as US, EU or APAC for some models, the 20 August GPT-5.6 article lists only US and global profiles for Sol, Terra and Luna. Teams in Europe should not infer that an eu. GPT-5.6 profile exists from the platform's general capability. They should verify the exact model page and profile ID at the time of a design or deployment decision.

This check is not one-and-done. AWS's inference-profile support documentation states that the destination set for a global profile can change as commercial Regions are added. In contrast, the destination list of a geography-bound profile does not change; AWS may publish a new profile when expanding that geography. A global profile should therefore be treated as a dynamic routing surface, not a static list copied into an architecture document.

API compatibility is not control equivalence

The Bedrock launch supports OpenAI-compatible Responses and Chat Completions formats. That can reduce application changes, but a shared request shape does not make two providers' regional, retention or logging controls equivalent.

For example, OpenAI's separate API data-control documentation describes project-level data residency and a European endpoint for eligible customers, models and services. It also separates customer content from system data, notes that eligibility and retention controls still apply, and documents limits for third-party services. Those are OpenAI platform controls; they do not describe a Bedrock inference profile.

The same separation matters inside AWS. The launch article says certain GPT-5.6 content flagged by Bedrock's automated abuse-detection classifiers may be retained for up to 30 days. AWS also says optional model-invocation logging can deliver request and response payloads to S3 or CloudWatch Logs in the source account and Region. Processing location, application-state retention, abuse-monitoring retention and customer-configured logging are four different questions. A single “data stays in region” checkbox cannot answer all four.

Build a routing policy by workload

Do not let each developer choose global. or a direct endpoint ad hoc. Create one routing policy that maps a workload class to an allowed execution path.

This is a starting framework, not a legal classification. The organisation should define its own categories, owners and stop conditions. The important property is that unknown data does not silently inherit the widest route.

Implement the decision in a small routing layer rather than scattering profile IDs through application code. The layer should accept a workload class, reject unknown classes, select an approved provider and profile, and record a policy version. Direct calls that bypass it should be denied with identity and service control policies where the platform permits.

Five controls before production traffic

1. Map the complete payload

Inventory more than the visible prompt. Include system instructions, retrieved documents, images, tool arguments, tool results, cached context, error traces and human feedback. Record which items can contain personal, confidential or regulated data and who owns the classification.

2. Authorise the route centrally

Bind workload classes to explicit profile or endpoint allowlists. A feature flag is not enough if any service role can still invoke the global profile. Test both allow and deny cases. AWS documents that IAM and service control policies interact with every destination Region, so a route may fail when one required destination is blocked—or work more broadly than intended when a global exception is too permissive.

3. Observe the destination, not only the source

AWS records cross-Region requests in CloudTrail in the source Region and exposes the processing Region through additionalEventData.inferenceRegion. Capture that field in an audit view and alert on destinations outside the approved set. Keep the audit record useful without copying full prompts into broadly accessible logs.

4. Separate routing from retention

Create a short matrix for provider-side abuse monitoring, API application state, prompt caching, invocation logging, object storage and support data. Assign a retention owner and deletion path to each store. Recheck the current provider documentation rather than importing assumptions from another API that happens to use the same SDK.

5. Define failure behaviour

Decide what happens when the approved route is throttled or unavailable. A restricted workload should not fail open to a global profile. Choose whether to queue, degrade to a smaller approved model, switch to a verified route or return the task to a person. Exercise that path under load before launch.

The France–Morocco operating question

A France–Morocco team must distinguish where its people sit, where an API call enters, where inference runs, where logs are stored and which organisations are in the processing chain. None can be derived reliably from the user's country or the cloud console's selected Region.

For transfers involving personal data subject to the GDPR, the legal analysis depends on the actual roles, destinations and transfer mechanism. The CNIL's final Transfer Impact Assessment guide says an exporter relying on Article 46 transfer tools must assess the destination country's law and practices, document the transfer and consider supplementary measures. It also identifies exceptions and does not turn every cross-border technical flow into the same legal case.

Engineering should provide the factual processing map; qualified privacy and legal specialists should determine what obligations apply. For Exceev's coordinated Paris–Casablanca model, this is exactly where strategy and engineering need one shared artifact rather than separate assumptions. Our AI data-residency decision guide offers the broader classification questions, while the services overview explains how discovery, architecture and delivery connect.

A two-week routing pilot

In the first week, select one low-risk use case and create four artifacts: the payload inventory, workload classification, allowed-route table and retention map. Configure the narrowest permissions that support the selected route. Add destination-Region telemetry and a dashboard that compares request volume, latency, throttling, failures and destination mix.

In the second week, run four test groups:

1. normal traffic through every approved route;
2. a restricted workload presented to the global route;
3. throttling and destination failure without a fail-open path;
4. a provider-profile change detected by the documentation review process.

Compare a fixed or restricted route with global routing using your real traffic shape, but synthetic or approved test data. Throughput gains should be measured, not assumed. The go/no-go record should name the workload owner, allowed profile, reviewed destination set, retention choices, tested fallback and next review date.

Sources and limitations

• AWS's 20 August 2026 GPT-5.6 cross-Region inference article is the current trigger and the source for the launch-specific profile, security, logging and retention details.
• Amazon Bedrock cross-Region inference documentation defines global and geographic routing and its general operational behaviour.
• Amazon Bedrock inference-profile support documentation documents model-specific destinations and how profile membership can change.
• OpenAI API data controls provide an independent comparison for OpenAI's direct API. They do not define AWS controls.
• The CNIL Transfer Impact Assessment guide provides official French regulatory guidance for relevant transfers.

Cloud capabilities, model availability, profile membership, retention terms and regulatory guidance can change. This article does not establish that a route is compliant, compatible or suitable for a specific workload. Verify the current technical and contractual documentation and obtain qualified advice for consequential privacy, security, legal or procurement decisions.

Final take

Cross-Region inference makes capacity easier to consume. It does not remove the need to decide where each workload may run.

Treat the inference profile as governed infrastructure: classify the payload, authorise the route, observe the actual destination, map every retention layer and test a non-global failure path. Throughput is valuable only when the team can explain—and prove—the boundary within which it was achieved.