Where Is Your AI Prompt Processed? Data Residency on Bedrock, Vertex AI and Azure

When a developer calls a large language model through a cloud provider, the region in the code is not always the region where the prompt is processed. Amazon Bedrock, Google Cloud's Vertex AI and Microsoft Foundry all now offer routing options that send requests to wherever capacity is free. These options are cheaper and more reliable, and they are often the default for new models. They can also move customer prompts across borders without anyone on the team noticing.

This guide explains how each of the three big platforms handles cross-region and global inference, what each says about data residency, and the settings to use if your prompts must stay in the US, the EU or another jurisdiction.

Key facts at a glance

• "Global" means anywhere. On all three platforms, global options can process a request in any region the provider chooses.
• Global is usually cheaper. Amazon says its global cross-Region inference saves about 10% on input and output token prices compared with geographic profiles. Microsoft calls Global Standard its lowest-price option.
• Endpoints are not residency guarantees. Google's documentation says plainly that its endpoints "don't guarantee data residency or in-region ML processing".
• Each cloud has a fenced middle tier. Bedrock has geographic inference profiles (such as US or EU), Google has multi-region US and EU endpoints, and Microsoft has Data Zone deployments.
• Stored data and processing are different. Microsoft says data at rest stays in the chosen Azure geography for every deployment type, but processing for global types can happen in any Azure region.
• You can log and block it. Bedrock records the actual processing region in CloudTrail, and its global calls can be denied with an IAM or organisation policy.

Who this guide is for

It is written for engineers, architects and compliance leads who run AI features on a public cloud and need to answer a simple question from a customer or regulator: where is our data processed? It covers pay-per-token inference on hosted models. Self-hosted models on your own virtual machines or managed compute are outside its scope, because you choose their region directly.

Amazon Bedrock: inference profiles

Bedrock routes traffic through what Amazon calls inference profiles. There are two kinds of cross-Region profile.

Geographic profiles keep requests within a named geography. A US profile, for example, can route between regions such as US East (N. Virginia), US East (Ohio) and US West (Oregon). Amazon says the profile can send requests to destination regions even if they are not enabled in your account.

Global profiles can send requests to any supported commercial AWS region. Amazon says these carry the roughly 10% price saving noted above.

Several details matter for compliance:

• No extra routing charge. Pricing is based on the region where you make the call, the source region.
• Traffic stays on Amazon's network. Amazon says requests travel over its own network, encrypted in transit, rather than the public internet.
• Logs stay in the source region. CloudTrail records the call in the source region, and the field additionalEventData.inferenceRegion shows where the request was actually processed. This is the evidence an auditor will want.
• Global needs explicit permissions. Using a global profile requires an IAM policy that covers the profile, the regional model and the global model resource, which takes the form arn:aws:bedrock:::foundation-model/MODEL.
• Global calls can be blocked. For global requests, the aws:RequestedRegion condition key has the value unspecified. Security teams can use that value in a deny policy or a service control policy to stop global routing across an organisation.
• Reserved capacity does not mix. Inference profiles do not support Provisioned Throughput, so teams that buy reserved capacity choose a specific region.

Google Cloud: regional, multi-region and global endpoints

Google's generative AI platform, still widely known as Vertex AI and now documented under the Gemini Enterprise Agent Platform name, offers three kinds of endpoint.

Regional endpoints, such as us-central1, use a hostname with the region as a prefix.

Multi-region endpoints are the residency tool. Google says they "let you ensure that machine learning processing of Customer Data by the service stays within a specific jurisdictional boundary". There are two: aiplatform.us.rep.googleapis.com for the United States and aiplatform.eu.rep.googleapis.com for the European Union. In code, you set the location to us or eu and use the .rep. hostname.

The global endpoint uses the plain aiplatform.googleapis.com hostname with the location global. Google says it improves availability and reduces resource-exhausted (HTTP 429) errors. It also warns, in its own words: "Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to."

One networking catch: Private Google Access is not supported for multi-region endpoints. Teams that need private connectivity to the US or EU multi-region endpoints must use Private Service Connect, either as a direct endpoint or behind a load balancer. Not every model supports every endpoint type, so check the model's location table before you commit.

Microsoft Foundry: deployment types

Microsoft builds the choice into the deployment itself. When you deploy a model for serverless, pay-per-token use, you pick a deployment type that sets both the price model and the processing location.

• Global Standard, Global Provisioned and Global Batch may process data in any Azure region.
• Data Zone Standard, Data Zone Provisioned and Data Zone Batch keep processing within a Microsoft-defined data zone: the US, the EU or Asia Pacific.
• Standard and Regional Provisioned process prompts and responses within the Azure geography you choose. Microsoft notes that data may move between regions inside that geography for operational reasons.

Microsoft recommends starting with Global Standard for most workloads. It says new models launch there first, it has the lowest price and the broadest region coverage, and new deployment types arrive in the order Global, then Data Zone, then geography-based. That last point is the trade-off: geography-based options come last and have no guaranteed availability date. Batch types offer a 50% discount for jobs that can wait up to 24 hours. A Developer type for testing fine-tuned models carries no SLA and no data-residency guarantee.

A five-step checklist to lock down processing location

1. Write down the requirement. Is it "EU only", "US only", "in-country", or simply "documented"? Contracts and regulators often accept a data zone, but some public sector work needs a single country.
2. Choose the matching tier per platform. For EU-only, use an EU geographic profile on Bedrock, the eu multi-region endpoint on Google, and a Data Zone or Standard deployment in an EU region on Azure.
3. Block the global option centrally. On AWS, deny requests where aws:RequestedRegion is unspecified. On Azure, limit who can create Global deployments through your usual role and policy controls. On Google, review code and configuration for the global location.
4. Collect evidence. Keep CloudTrail entries showing inferenceRegion values, and record endpoint hostnames and deployment SKUs in your architecture documents.
5. Re-check when models change. A new model may launch only as global first. Make "which regions does this model support?" part of every upgrade review.

What it means for you

For most teams, the answer is not to avoid global inference but to use it deliberately. Prototypes, internal tools and workloads with no residency commitments benefit from the lower prices and fewer capacity errors. Customer-facing features that handle personal data from the EU, UK or regulated sectors deserve a fenced tier, and the 10% or so price difference is a small cost compared with a breach of contract.

The counterpoint: residency is not the same as compliance

Pinning processing to a region does not by itself make a system compliant. European data protection law allows international transfers under safeguards, and many customers care more about contractual terms, retention and access controls than about the physical location of a GPU. Fenced tiers can also mean slower access to new models and more 429 errors at busy times. Some architects argue that strong encryption, short retention and clear contracts deliver more real protection than chasing region locks.

What happens next

All three providers are expanding global capacity first, because it lets them use spare GPUs wherever they sit. Expect more models to launch as global-only, with regional and data zone options following later. Teams with strict residency needs should track each provider's model availability pages and plan for a lag.

Key takeaways

• Default settings may route your prompts anywhere: global options on Bedrock, Google Cloud and Microsoft Foundry can process data in any region.
• Use the fenced tiers for regulated data: Bedrock geographic profiles, Google's US and EU multi-region endpoints, and Azure Data Zone or Standard deployments.
• Enforce it in policy, not memory: on AWS, deny aws:RequestedRegion = unspecified; on Azure, control who can create Global deployments.
• Keep proof: CloudTrail's inferenceRegion field and documented endpoint and SKU choices are what auditors will ask for.