Keeping AI workloads inside the EU is a routing decision, not a hosting decision. On all three hyperscalers the default path for foundation models is global, and the residency guarantee arrives only when you deliberately select a deployment type or endpoint whose contract keeps processing inside a jurisdiction. Azure Data Zone deployments process prompts and responses only inside the data zone you pick, and the EU zone follows the Azure EU Data Boundary, which can include EFTA countries such as Norway and Switzerland in addition to EU member states. Amazon Bedrock and Google Vertex AI ship equivalent controls, and this guide maps all three, what each one actually scopes, and how to verify where a request really ran before an auditor asks.
Where inference actually runs
Most residency incidents in AI stacks are not about storage. Buckets, vector databases and application logs usually sit in the region you chose when you created them. The exposure is inference: prompts, completions and tool outputs crossing into whichever datacenter the provider’s router picks at request time. Microsoft documents this split explicitly — data stored at rest remains in the designated Azure geography, but global deployment types may have their inferencing data processed in any Azure region. Treat every global SKU, global endpoint and global inference profile as a potential third-country exposure until your data processing agreement and transfer mechanism say otherwise, because the console label rarely mentions where routing happens.
Azure pins processing to zones
In Microsoft Foundry, residency is a deployment-type property you set per model. Data Zone Standard and Data Zone Provisioned keep prompts and responses inside the US, EU or APAC data zone, while the geography-based Standard and Regional Provisioned types tighten the boundary to a single customer-specified Azure geography. Two operational footnotes matter for planning. First, the Developer tier used for fine-tuned model evaluation carries no data residency guarantee and no SLA, with a fixed 24-hour lifetime. Second, new models reach geography-based tiers last, so a strict residency requirement can delay access to the newest releases. Enforce the choice centrally with Azure Policy: a deny rule targeting the CognitiveServices deployment SKU name stops anyone on the team from quietly provisioning a global deployment.
Bedrock keeps routing in geography
AWS exposes the same choice as inference profiles. Bedrock geographic inference profiles keep inference processing inside a named geography such as the EU, while global inference profiles let Amazon Bedrock select any commercial Region worldwide. Geographic profiles price at standard rates, and global profiles trade the geographic guarantee for a cost discount. Because routing happens outside your account, verify it after the fact: CloudTrail records every cross-Region inference call in your source Region, and the additionalEventData inferenceRegion field names the Region that actually processed each request, which turns a marketing claim into auditable evidence. One capacity caveat: inference profiles currently do not support Provisioned Throughput, so teams that sized reserved capacity using our provisioned throughput sizing walkthrough must choose between the reservation and the geographic profile.
Vertex offers EU endpoints
Google’s control is an endpoint, not a deployment flag. Vertex AI multi-region endpoints keep machine learning processing of customer data inside a jurisdictional boundary such as the European Union. The EU endpoint lives at aiplatform.eu.rep.googleapis.com and you select it by setting the client location to eu. Two sharp edges deserve attention. The global endpoint maximises availability and reduces resource-exhausted errors, but you cannot control or know which region processes a request sent to it, which disqualifies it for residency-bound workloads. And Private Google Access is not supported for multi-region endpoints, so private connectivity to the EU endpoint requires Private Service Connect instead.
Residency controls compared
| Provider | Residency control | Processing boundary | Enforcement | Main gap |
|---|---|---|---|---|
| Azure Foundry | Data Zone Standard or Provisioned SKU | Data zone; EU zone follows the EU Data Boundary | Azure Policy deny on deployment SKU | Newest models land on global tiers first |
| Amazon Bedrock | Geographic cross-Region inference profile | Named geography such as the EU | SCPs on destination Regions plus CloudTrail auditing | No Provisioned Throughput support |
| Vertex AI | EU multi-region endpoint with location set to eu | Jurisdictional boundary covering the EU | Client configuration plus Private Service Connect | Global endpoint is the availability default |
A routing verification checklist
- Classify everything that crosses the model API: prompts, completions, tool outputs, evaluation datasets and telemetry.
- Pin the control per workload: Data Zone SKU in Azure, geographic inference profile in Bedrock, the eu endpoint in Vertex AI.
- Block the defaults organisation-wide: Azure Policy on the deployment SKU, service control policies on destination Regions, org policy on endpoints.
- Verify with evidence rather than labels: sample CloudTrail inferenceRegion entries and provider audit logs across a week of real traffic.
- Re-check after every model migration, because new models often launch global-only and geography-bound options arrive later.
What residency does not fix
An EU processing boundary is necessary but not sufficient. An EU adequacy decision lets personal data flow to a third country without any further safeguard being necessary, and the decision covering the United States applies only to commercial organisations participating in the EU-US Data Privacy Framework — so a provider support engineer in a non-adequate jurisdiction reading your prompts is a transfer that a regional endpoint never stops. Residency controls also say nothing about retention defaults, which deserve a separate audit; our piece on zero data retention defaults covers that half of the problem. Write down which claims your residency control does and does not make before a DPA negotiation, not after.
Sources
- Microsoft Learn — Understanding deployment types in Microsoft Foundry Models
- AWS Documentation — Route model inference requests across AWS Regions with cross-Region inference
- Google Cloud — Vertex AI deployments, endpoints and supported locations
- European Commission — Data protection adequacy for non-EU countries