Picking cloud AI regions is the first deployment decision that is expensive to reverse: it fixes where prompts, fine-tuning datasets and inference traffic are processed, which model families you can call, and the round-trip distance your users feel on every request. For engineering teams in Portugal, the practical answer is to default to EU regions on each provider, then verify two things per region before provisioning anything: the provider’s data-processing commitment and the exact model catalog that region exposes. Google documents that Vertex AI stores and processes data only in the region you specify, with narrow exceptions for data labeling and preview features, while Microsoft ties model availability to individual regions — so residency and catalog coverage are per-region facts, not platform-wide promises.
This guide compares what region selection controls on Google Cloud and Microsoft Azure, maps the European regions each provider exposes to machine learning workloads, and ends with a checklist a team in Portugal can run before creating its first production endpoint. It skips marketing comparisons: every constraint below comes from provider documentation you can verify against your own tenant.
What Region Selection Decides
A region is not a label; it is a bundle of four constraints that move together. First, it is the contractual and legal location where inference requests and training data are processed, which is what data residency reviews examine. Second, it is the catalog: models, accelerator types and platform features ship region by region, so a model that is deployable in one region may simply not exist in another. Third, it is a quota boundary — request limits and capacity are tracked per region, and a spike that one region absorbs will throttle in a neighbor. Fourth, it is a network position that sets the baseline round trip for every API call, including each streaming token.
Because all four constraints move together, region changes are migrations, not configuration edits. Endpoints, fine-tuned models, stored datasets and monitoring history are regional objects; moving workloads means re-creating them and re-processing anything the old region ingested. Teams that treat placement as an afterthought discover this when a compliance review or a capacity ceiling forces the move under pressure. Context matters as well: EU enterprises layer AI onto existing cloud estates rather than building greenfield, as the enterprise cloud AI adoption survey data for 2025 shows, which means region choice is usually constrained by where the rest of the estate already runs.
Residency Guarantees Differ by Provider
The two hyperscalers express residency differently, and the difference decides what you can promise auditors. On Google Cloud, the platform-level commitment covers all features of the managed machine learning service except data labeling tasks and features in experimental or preview status — two exceptions that matter, because preview features are exactly what engineering teams reach for first. The same documentation adds a governance hook: organization policy administrators can restrict the regions available to the service with a resource locations constraint, which lets a platform team make non-EU regions unselectable rather than merely discouraged. That is the control to configure before tenants start self-provisioning, and it is documented in the Vertex AI locations reference.
Azure frames its promise through the commercial model instead. Models sold directly by Azure are hosted and operated by Azure, billed through your Azure subscription and covered by Azure service-level agreements. For EU teams the practical reading is that the residency surface to assess is the Azure region plus the Foundry service boundary, not the origin of each model’s weights. First-party models process prompts in the region you deploy to, but partner models in the catalog deserve a per-model check, because their operating arrangements differ from first-party ones. Record which deployment type serves each workload, since that choice changes where requests are served and how residency is argued in a review.
Model Availability Shapes the Menu
Region choice silently edits your model menu. Microsoft states plainly that model availability varies by region and cloud for the Azure OpenAI model families it sells, and Google ships Vertex AI capabilities region by region as well; the feature availability matrix in its documentation is the artifact to check, not the marketing page. The consequence for architecture is discipline: pin model versions per feature and record the region each version was validated in, because a model that passes integration tests in your development region may not be deployable where production data must stay. Before each deployment, re-check the Foundry models documentation for the region list that applies to your tenant.
European coverage is broad on both platforms, which removes the usual excuse for routing prompts out of the Union. Vertex AI lists Belgium (europe-west1), London (europe-west2), Frankfurt (europe-west3), the Netherlands (europe-west4), Zürich (europe-west6), Milan (europe-west8), Paris (europe-west9), Turin (europe-west12), Madrid (europe-southwest1), Warsaw (europe-central2) and Finland (europe-north1) as its European machine learning regions. For a team in Lisbon, Madrid and Paris are the geographically nearest options on that list; choose between candidates on catalog coverage rather than distance alone. Availability is per feature as much as per region — training, online inference, vector search and feature stores each carry their own support matrix, so validate the feature you actually need, not just the region pin.
| Decision factor | Google Vertex AI | Azure OpenAI / Foundry |
|---|---|---|
| Regional processing commitment | Data stored and processed in the region you specify, except data labeling and preview features | First-party models hosted and operated by Azure, billed via subscription, covered by Azure SLAs |
| Catalog behavior | Feature availability matrix varies by region; check per feature | Model availability varies by region and cloud |
| Nearest EU options to Portugal | Madrid (europe-southwest1), Paris (europe-west9) | Verify per-model region availability before assuming parity |
| Enforcement control | Organization policy resource locations constraint | Deployment type choice plus per-region provisioning policy |
Latency From Portugal Is Secondary
Latency argues for nearby regions, but it rarely decides. An inference call spends its time in queueing, prefill compute and token generation, not in pure network transit; across European regions the transit component is small next to time-to-first-token for long prompts. Pick the nearest region that passes the catalog and residency checks, then stop optimizing placement for distance. Streaming responses hide most remaining transit differences, because tokens arrive progressively instead of after a full round trip.
Where latency genuinely matters is at the system level. Applications that chain model calls, retrieval steps and tool executions multiply round trips, and that multiplication — not the individual hop — is what users perceive. Colocating retrieval stores, caches and model endpoints in a single region does more for responsiveness than switching between European regions a few hundred kilometers apart. Keep inter-service traffic on the provider backbone where the option exists, and measure time-to-first-token and tokens per second from Portugal before and after any move, because those two figures describe what users actually experience.
Region Selection Checklist
Run this sequence before creating production endpoints; each step either eliminates a region from consideration or documents why it stays.
- List the EU regions your provider exposes for the exact features you need — training, online inference, vector search, fine-tuning — using the feature availability matrix, not the region landing page.
- Confirm the data-processing commitment for each candidate region in provider documentation and record the exceptions that apply.
- Verify that the model families and versions you depend on are deployable in each candidate region, and pin versions per feature.
- Classify workloads as interactive, asynchronous or fault-tolerant training; each class has different region priorities.
- Apply an organization-level region constraint so non-EU regions cannot be selected by individual tenants.
- Check quotas for expected peak request volume, per region, and file increases before launch rather than during an incident.
- Colocate object storage, vector stores and endpoints in the chosen region, then measure time-to-first-token from your real user base.
- Record provider-versus-deployer roles and processing locations per feature so compliance reviews map to evidence, and repeat the checklist whenever the provider changes region or model availability.
Placement also interacts with spend and with EU obligations that now carry fixed dates; the companion analysis of cloud AI cost optimization and compliance for Portugal covers those levers once the region is settled. Treat region choice as a portfolio decision reviewed quarterly: vendor catalogs shift, and the cheapest time to notice is before a migration, not during one.