Data Residency for AI Apps (2026): The Complete Region Guide

Layer 1 — vendor selection: which LLM vendor's models meet your quality/cost/feature needs. This is the typical primary decision.

Layer 2 — region selection within the vendor: which of the vendor's regions matches your residency requirement. This is constrained by the vendor's footprint.

Layer 3 — application configuration: ensuring your application code, SDK configuration, and adjacent infrastructure (logs, vector DB, audit trail) all honor the chosen region.

Mistakes happen most often at Layer 3. A vendor might offer EU residency, you might pick the right EU region, but your application's CloudWatch Logs are in us-east-1, your vector DB is in us-west-2, your CDN is global, and your support ticketing system processes everything in the US. The inference is in-region but the data flow as a whole is not.

Plan all three layers before committing. Map every component of the data flow (inference, logs, embeddings, fine-tuning datasets, audit trails, support tooling, analytics) and verify each is in the residency boundary you claim.

GDPR-driven EU residency is the most common residency requirement for AI deployments in 2026. The options:

Azure OpenAI in West Europe (Netherlands), North Europe (Ireland), Sweden Central (Sweden — sovereign), France Central (France), Switzerland North (Switzerland — sovereign), Germany West Central (Germany). 6+ EU regions. Broadest footprint in the major-vendor market. Microsoft Online Services DPA + EU SCCs cover.

AWS Bedrock in eu-west-1 (Ireland), eu-central-1 (Frankfurt), eu-west-3 (Paris), eu-north-1 (Stockholm), eu-west-2 (London). 5+ EU regions. AWS Service Terms + AWS GDPR DPA cover.

Google Vertex AI in europe-west1 (Belgium), europe-west4 (Netherlands), europe-west9 (Paris), europe-southwest1 (Madrid), and others. Multiple EU regions. Google Cloud DPA covers.

OpenAI Enterprise direct with EU residency provisioned. Coordinate via Enterprise sales; per-model availability narrower than the cloud-partner routes.

Anthropic Enterprise direct with EU residency. Coordinate via Enterprise sales.

Practical guidance: for most EU enterprises, pick the cloud you're already on (Azure OpenAI or AWS Bedrock); pick the region closest to your application infrastructure; pin every adjacent service to the same region.

UK GDPR is functionally similar to EU GDPR. UK adequacy decision with the EU is in force through 2026 with review in 2027.

Options:

Azure OpenAI in UK South.

AWS Bedrock in eu-west-2 (London).

Google Vertex AI in europe-west2 (London).

Practical guidance: UK-specific residency is straightforward through all three major clouds. For organizations with both UK and EU customers, picking an EU region usually suffices for both jurisdictions (UK adequacy means UK→EU transfer is permitted under UK GDPR rules; EU→UK transfer is permitted under EU adequacy).

Sovereign workloads require additional commitments beyond standard regional processing — data physically in-country, sovereign legal protections against foreign data access requests, often customer-managed encryption with sovereign-issued keys.

Switzerland: Azure Switzerland North is a fully sovereign region with Microsoft Swiss Cloud commitments. AWS does not have a Swiss region as of June 2026 (verify the European Sovereign Cloud rollout for any 2026 Swiss launch). For maximum Swiss sovereignty, Azure is the path.

Sweden: Azure Sweden Central is fully sovereign with Microsoft Swedish Cloud commitments. AWS Stockholm (eu-north-1) provides Swedish region processing but not the same sovereign overlay.

Germany: Azure Germany West Central is in-Germany. AWS Frankfurt (eu-central-1) is in-Germany. Both are standard regions, not 'sovereign' overlays. Microsoft previously had a separate Germany-Cloud product (Bundesgrenzen Cloud) which was sunset; the current standard Germany regions are the current path.

France: Azure France Central is in-France. AWS Paris (eu-west-3) is in-France. Google Vertex AI europe-west9 (Paris) is in-France. Standard regions, not sovereign overlay.

AWS European Sovereign Cloud: announced and launching 2026 (Germany first). Verify the current GA status before committing. The Sovereign Cloud will provide stronger sovereign overlay than standard EU regions including independent infrastructure, EU-resident operations staff, and stronger contractual sovereign commitments.

Practical guidance for sovereign: Switzerland North or Sweden Central on Azure for the cleanest sovereign positioning today. Watch AWS European Sovereign Cloud as an emerging option.

US federal workloads require FedRAMP Moderate (most civilian agencies) or FedRAMP High (CUI, DoD impact levels 4-5).

Azure OpenAI in Azure Government regions: FedRAMP High. Currently the most mature frontier-model path for FedRAMP High in 2026. Coordinate via Microsoft Federal sales.

AWS Bedrock in AWS GovCloud (US): FedRAMP High in GovCloud. Per-model Bedrock availability in GovCloud has expanded; verify the current region scope. Coordinate via AWS Federal sales.

AWS Bedrock in commercial regions: FedRAMP Moderate for the services in scope. Per-model coverage varies. Often sufficient for FedRAMP Moderate workloads.

Google Cloud Assured Workloads for federal: provides FedRAMP Moderate / High options on Google Cloud including Vertex AI in supported configurations. Coordinate via Google Federal sales.

OpenAI direct: limited FedRAMP Moderate on specific endpoints. Anthropic direct: FedRAMP Moderate in progress.

Practical guidance: federal AI workloads in 2026 default to Azure OpenAI in Azure Government (FedRAMP High) or AWS Bedrock in GovCloud (FedRAMP High, model availability narrower). For Moderate-only workloads, all three major clouds work.

Asia Pacific residency requirements vary by jurisdiction. Major options:

Japan: Azure Japan East (Tokyo), AWS ap-northeast-1 (Tokyo), Vertex AI asia-northeast1 (Tokyo).

Korea: Azure Korea Central (Seoul), AWS ap-northeast-2 (Seoul) — verify per-model availability, Vertex AI asia-northeast3 (Seoul).

Singapore: Azure Southeast Asia (Singapore), AWS ap-southeast-1 (Singapore), Vertex AI asia-southeast1 (Singapore).

Australia: Azure Australia East (Sydney), AWS ap-southeast-2 (Sydney), Vertex AI australia-southeast1 (Sydney). For IRAP (Australian government) workloads, Azure and AWS both have IRAP-assessed regions.

India: Azure South India (Chennai), AWS ap-south-1 (Mumbai) and ap-south-2 (Hyderabad), Vertex AI asia-south1 (Mumbai).

Hong Kong: Azure East Asia (Hong Kong), AWS ap-east-1 (Hong Kong) — note Hong Kong sovereignty considerations.

Practical guidance: APAC residency is straightforward through major clouds. Verify per-model availability — APAC regions historically have narrower model availability than US / EU regions. Newest models often launch in APAC weeks to months after US launch.

Latin America residency options:

Brazil: Azure Brazil South (São Paulo), AWS sa-east-1 (São Paulo), Vertex AI southamerica-east1 (São Paulo).

Mexico, Argentina, Chile, Colombia: typically processed via the closest US or Brazil region. As of June 2026, no dedicated Mexico / Argentina cloud regions for the major vendors (verify current state).

Brazil specifically: LGPD (Lei Geral de Proteção de Dados) is functionally similar to GDPR. Brazil region processing satisfies LGPD residency considerations.

Practical guidance: for LATAM workloads, default to Brazil region if available. For non-Brazil LATAM customers, document the cross-border transfer mechanics (US region processing under appropriate transfer agreements).

Even with the LLM inference in the right region, common adjacent infrastructure mismatches break the residency claim:

Application logs: CloudWatch Logs / Cloud Logging / Azure Monitor are region-scoped. Make sure your log destination is the same region as your inference.

Vector embeddings stores: Pinecone Serverless region, Weaviate Cloud region, Qdrant Cloud region. Pin to the same EU / sovereign region as inference.

Fine-tuning datasets: stored in the LLM vendor's region. Verify the storage is in your chosen region.

Audit trail destination: same as application logs. Cross-region log shipping breaks residency.

Customer support tools: support tickets often contain prompts / outputs. Pin the support tool to a residency-appropriate region or anonymize / redact at ticket creation.

Analytics: many SaaS analytics tools (Mixpanel, Amplitude, Heap) process events in US regions by default. Use EU-region configurations or self-hosted analytics for residency-strict workloads.

CDN: global CDNs cache content close to users. For residency-strict workloads, configure CDN to region-restrict or skip caching for inference paths.

Email / notification systems: customer-bound emails / SMS often route through US-based providers. For residency-strict workloads, use EU-region or in-region providers.

Practical pattern: maintain a 'data flow map' diagram showing every component touching the inference path and its region. Update on every infrastructure change. Verify quarterly.

When you serve customers in multiple residency jurisdictions, the deployment is multi-region. Common patterns:

Pattern 1 — single region default, customer-pinned region: customer chooses their region at signup (or you choose based on their geography). All processing for that customer happens in their region. Storage is per-region.

Pattern 2 — multi-region active-active: same workload runs in multiple regions; requests routed to the nearest region based on user geography. Data is per-region; cross-region access requires explicit user consent.

Pattern 3 — global with region-pinned subset: most customers processed in a default region; specific customers (regulated, sovereign) processed in their pinned region. Two operational pipelines.

Pattern 4 — federated regions: tenant-isolated infrastructure per region; each tenant lives in exactly one region. Strongest residency story; highest ops complexity.

Pick the pattern based on customer mix. Pattern 1 or 3 is most common for B2B SaaS with mixed customer base. Pattern 4 is for highly regulated industries or government.

Cost implication: multi-region typically adds 30-100% to infrastructure cost vs single-region. Justify by customer revenue or regulatory necessity.