LLM Data Residency and Sovereignty: A Provider by Region Matrix

Last updated: August 2026

A client asked us to sign off that their EU deployment was sovereign. They had bought a European endpoint, paid the premium for it, and had a signed data processing agreement in the folder. The inference really did run in the EU. The operator was still a US company that a US court can compel, the abuse classifier ran outside the boundary they thought they had bought, and their gateway had a global fallback route that nobody on the compliance side had ever seen. Three of those four facts were sitting in public vendor documentation.

That gap is what this page exists to close. Residency is a claim about geography: the accelerators that produced those tokens were in a named place. Sovereignty is a claim about legal reach: no foreign court or agency can order the operator to produce the data. You can buy the first without getting the second, and most teams that buy a regional endpoint do exactly that.

Below is the matrix, what each row costs, and the part every vendor page leaves out. Every claim was checked against primary vendor documentation or the official legal text on 11 August 2026. Region lists and prices move every quarter, so treat the verification date as the most important column.

Residency Is Not Sovereignty, and the Difference Is Legal

The US CLOUD Act amended the Stored Communications Act with 18 U.S.C. 2713, effective 23 March 2018. It requires a provider of electronic communication or remote computing service to preserve, back up or disclose customer content and records in its "possession, custody, or control", and says explicitly that this applies regardless of whether the data sits inside or outside the United States. Storing prompts in Frankfurt does not remove them from that reach if the entity holding them is a US parent or its subsidiary. So there are three postures, not two, and they cost very different amounts:

• Default routing. Cheapest, best availability, newest models first. Inference lands wherever there is capacity. Fine for a large slice of most workloads and completely unacceptable for a small slice.
• Residency. You pin inference and at-rest storage to a jurisdiction. This satisfies a contractual or regulatory requirement about location. It does not change who the operator answers to.
• Sovereignty. The operator is a locally incorporated entity, staffed and controlled locally, with a documented process for refusing or challenging foreign orders. Or you run the weights yourself. Very few offerings clear this bar, and the ones that do are separate products, not a flag on your existing account.

The AWS European Sovereign Cloud, generally available since January 2026 with its first Region in Brandenburg, is the clearest hyperscaler example of the third posture. It is a separate cloud partition with its own billing and IAM systems, managed through dedicated European legal entities established under German law, with managing directors who are EU citizens resident in the EU. AWS says technical controls built into the infrastructure prevent access from outside the EU, and that logical and physical access to systems inside the partition is restricted to qualified staff located in the EU. Bedrock and SageMaker are among the initial AI services. You need new accounts: you create a new root account for the partition and new IAM identities inside it, so existing AWS credentials do not reach it.

The Matrix: How You Pin, and What It Costs

Two things surprise people. The same model on two clouds gives you different residency controls, because the control belongs to the platform and not the model. And the price mechanics differ: one vendor applies a multiplier to every token category including cache reads, another adds a flat surcharge to non-global endpoints.

The Cost of Pinning Is Not Mostly Money

A 10 percent surcharge is a rounding error next to a compliance finding. The expensive part is the availability tax and the model lag.

• Newest models arrive last. Microsoft documents the launch order: Global, then Data Zone, then single region, where deployments "depend on capacity that frees up as older models retire". On Google Cloud, the newest Claude models are not offered on single-region endpoints at all. A policy that says single region only also says you get last year's model.
• Provisioned capacity and residency pull in opposite directions, and each cloud resolves that differently. On Google Cloud, Provisioned Throughput requires a regional endpoint, while global and multi-region are pay as you go only, so buying capacity forces you into the narrowest residency posture. On Bedrock the opposite: cross-Region inference profiles do not support Provisioned Throughput at all, so buying capacity means giving up multi-Region routing. On Azure, provisioned variants exist for every tier, so the tension does not arise. Three clouds, same model family, three different architectural conclusions.
• Rate limits do not follow the geo. On the Claude API, rate limits are shared across geos. Pinning does not buy you a separate capacity pool, so a noisy non-regulated workload can throttle the regulated one.
• Priority commitments burn faster. On the Claude API a Priority Tier token consumed with inference_geo: "us" draws down 1.1 tokens from committed TPM, so the multiplier hits your capacity plan as well as your invoice.
• Fewer features. The Claude API on Google Cloud does not support the Files API, code execution, web fetch, batches, MCP connector or server-side fallback. Residency choices silently remove capabilities your application may already depend on.

What Still Leaves the Region When Inference Does Not

This is the section no vendor writes, because it undermines the thing they just sold you. None of it is secret. All of it is in the docs, several clicks past the marketing page.

Read those rows together and a pattern falls out. The residency guarantee covers the happy path. The exceptions are all on the unhappy path: something got flagged, something failed over, something needed a human. Those are precisely the events a regulator will ask about.

Your Gateway Is the Real Compliance Boundary

Every serious deployment has a gateway in front of the models, and that gateway usually has retry and fallback logic written by someone optimizing for uptime. That logic is now a compliance control, whether or not anyone has told the compliance team. Two rules: check where the request actually ran rather than where you asked it to run, and fail closed instead of falling back across the boundary.

# residency_gateway.py
# Requires: pip install anthropic
import os
import anthropic

BOUNDARY = os.environ.get("LLM_BOUNDARY", "us")   # "us" or "global"
ALLOWED = {
    "restricted": {"us"},          # PHI, PII, contract text
    "general": {"us", "global"},   # everything else
}

client = anthropic.Anthropic()   # reads ANTHROPIC_API_KEY


class ResidencyViolation(RuntimeError):
    pass


def ask(prompt, classification="restricted", model="claude-opus-5"):
    if BOUNDARY not in ALLOWED[classification]:
        raise ResidencyViolation(
            f"{classification} traffic may not run in {BOUNDARY}"
        )

    resp = client.messages.create(
        model=model,
        max_tokens=4096,                 # thinking is on by default on Opus 5
        inference_geo=BOUNDARY,          # Claude 4.6 and later; older models 400
        messages=[{"role": "user", "content": prompt}],
    )

    # Do not trust the request. Check where it actually ran.
    served_in = resp.usage.inference_geo
    if served_in not in ALLOWED[classification]:
        raise ResidencyViolation(
            f"asked for {BOUNDARY}, served from {served_in}, id={resp.id}"
        )

    # This log is your evidence. The vendor's marketing page is not.
    print(f"{resp.id}\t{classification}\t{BOUNDARY}\t{served_in}")
    return resp


if __name__ == "__main__":
    ask("Summarize the attached discharge note.", classification="restricted")

The resp.usage.inference_geo field exists precisely so you can audit this. On Bedrock or Google Cloud the equivalent is the inference profile ID or the endpoint hostname you called, and both belong in the log on every request, not sampled. But application-level checks are a good tripwire and a bad control, because someone will eventually ship a service that calls the SDK directly. Put the real boundary where a developer cannot route around it.

// Annotated for reading. Strip the // comments before you apply either document:
// neither AWS SCPs nor Azure Policy accept comments in JSON.

// AWS SCP: attach at the OU level. Two separate mechanics make this work.
// 1. A geographic (eu.) profile fails outright if ANY of its destination Regions
//    is denied here, even when your source Region is still allowed.
// 2. Global cross-Region inference does not report a real Region at all. AWS sets
//    aws:RequestedRegion to the literal string "unspecified", so leaving that
//    string out of the list below is exactly what blocks worldwide routing.
//    Adding it back, as plenty of teams do to stop the errors, silently re-opens it.
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyBedrockOutsideEU",
    "Effect": "Deny",
    "Action": [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream",
      "bedrock:CreateModelInvocationJob"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": [
          "eu-central-1", "eu-west-1", "eu-west-3", "eu-north-1"
        ]
      }
    }
  }]
}

// Azure Policy: block the Global deployment SKU in a regulated subscription.
// Repeat per SKU you want to forbid: GlobalStandard, GlobalProvisionedManaged,
// GlobalBatch, DeveloperTier.
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        { "field": "type",
          "equals": "Microsoft.CognitiveServices/accounts/deployments" },
        { "field": "Microsoft.CognitiveServices/accounts/deployments/sku.name",
          "equals": "GlobalStandard" }
      ]
    },
    "then": { "effect": "deny" }
  }
}

The SCP behavior is worth dwelling on. AWS documents that if any destination Region in a cross-Region inference profile is blocked by your SCPs, the request fails even though other Regions are still allowed. Teams read that as a bug and add the Regions back. It is not a bug. It is the only way you find out that your "EU" traffic was riding a global profile.

Retention, Zero Retention and BAAs

The question that decides your timeline is not whether zero data retention exists. It is whether you can turn it on yourself or whether it needs a signature and a sales cycle.

One trap worth naming. On the Claude API, HIPAA readiness and ZDR are alternatives, not a stack. HIPAA readiness applies encryption, access control and audit logging across the PHI lifecycle instead of deleting immediately, and it blocks non-eligible features with a 400 rather than letting you drift. ZDR does not block anything: calling a non-eligible feature under ZDR just steps outside the arrangement for that data, silently. If you have PHI, take the BAA, not ZDR.

The Gulf and APAC Rows the EU-Centric Pages Skip

We deploy into the US, UK, Philippines and UAE, and the Gulf rows are where the aggregator posts fall apart, because they are copied from EU-first vendor pages.

• UAE on AWS. Bedrock runs in me-central-1, and the Claude launch there on 24 February 2026 covered the Middle East Regions, UAE and Bahrain. Read the announcement properly and it is global cross-Region inference: the request originates in the Gulf and is routed for processing to a Region anywhere in the commercial AWS footprint. AWS says data remains in the source Region and that CloudWatch and CloudTrail logging stays there for compliance, which is true and is not the same claim. The processing itself leaves. Anthropic's own Region table settles it: me-central-1 is listed as Global endpoint only, with no in-region option and no geography to pin to. If a UAE regulator asks where the inference ran, "me-central-1" is the wrong answer.
• UAE on OpenAI. The UAE is one of only three regions supporting regional processing of inference, alongside the US and Europe, and selecting it needs additional approval from OpenAI. On the published documentation this is the cleanest in-region path for a Gulf workload on a hosted frontier model.
• UAE on Google Cloud. The multi-region endpoints are us and eu. There is no Middle East equivalent for Claude or Gemini, so a Gulf residency requirement has no multi-region answer here at all, and storage residency in a Middle East region is a different commitment that should not be sold as one.
• UK, and why "Europe" is three different sets. Google's eu multi-region covers EU member states and excludes the United Kingdom and Switzerland, so post-Brexit UK workloads need a specific regional endpoint rather than the shortcut. Microsoft's EU Data Zone follows the Azure EU Data Boundary, which can include EFTA countries such as Norway and Switzerland. Bedrock's EU geography goes further still: eu-west-2 is London and eu-central-2 is Zurich, both inside it. So a policy that says "EU only" and a vendor flag labelled EU can differ by two countries in either direction. Write the Region list, not the word.
• APAC. On the older Bedrock inference-profile surface the geographies are US, EU and APAC; on the current Claude in Amazon Bedrock surface they are US, EU, JP and AU, so an apac.-shaped policy does not port across. Azure offers an APAC Data Zone. OpenAI offers storage residency in Japan, Singapore, South Korea, India and Australia, and regional inference processing in none of them. For a Philippines or Singapore deployment, that last difference decides the architecture.

One more legal wrinkle for the Gulf. The UAE PDPL, Federal Decree-Law No. 45 of 2021, in force since 2 January 2022, restricts cross-border transfer to jurisdictions the UAE Data Office has deemed adequate, or to a narrow set of other bases. It does not apply inside the DIFC or ADGM, which run their own regimes (DIFC Data Protection Law No. 5 of 2020 and the ADGM Data Protection Regulations 2021). A Dubai entity and a DIFC entity in the same group can be under different rules for the same prompt.

The Law You Are Buying Against

Numbers first, since they set the budget for the whole exercise. Under GDPR Article 83, the two fine tiers are up to 10 million EUR or 2 percent of total worldwide annual turnover, and up to 20 million EUR or 4 percent, whichever is higher in each case. Under EU AI Act Article 99, prohibited practices under Article 5 carry up to 35 million EUR or 7 percent of total worldwide annual turnover, other operator obligations up to 15 million EUR or 3 percent, and supplying incorrect or misleading information up to 7.5 million EUR or 1 percent.

On timing, Article 113 sets general application from 2 August 2026, with Chapters I and II applying from 2 February 2025 and the general-purpose AI, governance and penalties chapters from 2 August 2025. High-risk always ran on two tracks: Annex III stand-alone systems from 2 August 2026, and Annex I systems embedded in products already covered by EU product-safety law from 2 August 2027. The Digital Omnibus on AI moved both. Political agreement landed on 6 May 2026, the Parliament adopted it on 16 June, and it entered into force on 27 July 2026. The replacement deadlines are fixed calendar dates rather than the conditional trigger the Commission first proposed: 2 December 2027 for Annex III stand-alone high-risk systems, 2 August 2028 for the Annex I embedded ones.

Note what none of this says. Neither the GDPR nor the AI Act requires that inference run inside the EU. What the GDPR regulates is international transfer and the safeguards around it. Teams routinely conflate "we must comply with GDPR" with "we must pin to Frankfurt", buy the premium endpoint, and still have an unmapped transfer sitting in their abuse-logging path. Residency is one control among several, not the whole answer.

What Residency Does Not Give You

• Immunity from foreign legal process. 18 U.S.C. 2713 reaches data in the provider's possession, custody or control regardless of location. Only a genuinely separate local operator, or self-hosting, changes that calculus.
• Control over the safety path. Classifier-flagged content is retained and sometimes human-reviewed under every major provider's terms, including under ZDR and HIPAA arrangements. On the Claude API that retention window is up to 2 years for flagged content.
• A stable boundary. Microsoft says it can add regions to either the EU or APAC data zone without prior notice, to improve capacity and availability. AWS publishes the destination Regions behind a geographic profile but claims worldwide routing for global ones, and the commercial Region list grows. A boundary you have not written down and pinned yourself is a boundary the vendor can move in a documentation update.
• Protection from your own integrations. A web search tool, an MCP server, a RAG index or a logging sink can carry the same content out of the region seconds after a compliant inference call.
• An answer for the auditor. Residency is a configuration claim. Evidence is a per-request log of the geo or endpoint that actually served it. If you cannot produce the second, you do not have the first in any way that survives scrutiny.

The Architecture I Would Actually Build

Two planes, split by data classification, not by team or by application. It is the recommendation I give on every engagement where this comes up, and it holds because it matches how the cost curve actually behaves.

• Plane one, the small one. Genuinely sensitive traffic. PHI, identified customer records, unredacted contracts, anything a regulator would name. Run this on a sovereign partition, an in-region deployment with a signed BAA, or an open-weights model you host yourself. Accept older models, lower throughput and a higher unit cost. In practice this is usually 5 to 15 percent of request volume.
• Plane two, everything else. Hosted frontier models on default global routing, behind a gateway that classifies, redacts and logs. Full model choice, best price, best availability.
• The gateway is the product. Classification, redaction, geo pinning, fail-closed routing and per-request residency logging all live in one place that both planes go through. If you build only one thing from this article, build that.

The failure mode I see most often is the opposite: a team buys the strictest posture for 100 percent of traffic to make the policy simple, discovers six weeks later that the strict posture cannot do batch, or code execution, or the model the product team wanted, and quietly exempts those workloads one ticket at a time. Twelve months on they are paying the premium on the boring traffic and running the interesting traffic on default routing. That is worse than never having pinned anything, because the org now believes it is covered.

If you would not defend the exemption in front of a regulator, do not grant it. And if you would, then the strict tier was scoped wrong to begin with. Redo the classification, not the exemption list.

Verify It Yourself, Then Put It on a Calendar

Do not take this table into a design review without re-checking the rows you depend on. The two-minute version:

#!/usr/bin/env bash
set -euo pipefail

# 1. Bedrock: find out which destination Regions a profile can actually route to.
#    List first. Do not hardcode a profile ID copied from a blog post: the
#    identifiers are dated and differ per model and per geography.
aws bedrock list-inference-profiles \
  --type-equals SYSTEM_DEFINED \
  --region eu-west-1 \
  --query 'inferenceProfileSummaries[].inferenceProfileId' --output text

#    Then read the destination Regions off the one you depend on. Each model ARN
#    carries the Region it lives in, so this is the real blast radius.
PROFILE_ID="eu.anthropic.example-profile-id"   # from the list above
aws bedrock get-inference-profile \
  --inference-profile-identifier "${PROFILE_ID}" \
  --region eu-west-1 \
  --query 'models[].modelArn' --output text

# 2. Google Cloud: call the EU multi-region host explicitly.
#    aiplatform.eu.rep.googleapis.com is the residency boundary,
#    aiplatform.googleapis.com/locations/global is not.
curl -sS -o /tmp/body.json -w '%{http_code} %{url_effective}\n' \
  "https://aiplatform.eu.rep.googleapis.com/v1/projects/${PROJECT_ID}/locations/eu/publishers/anthropic/models/claude-opus-5:rawPredict" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version":"vertex-2023-10-16","max_tokens":64,
       "messages":[{"role":"user","content":"ping"}]}'

# 3. Claude API: confirm the served geo, not the requested one.
curl -sS https://api.anthropic.com/v1/messages \
  -H "x-api-key: ${ANTHROPIC_API_KEY}" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-opus-5","max_tokens":64,"inference_geo":"us",
       "messages":[{"role":"user","content":"ping"}]}' \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['usage']['inference_geo'])"

# 4. Azure: prove no Global SKUs exist in the regulated subscription.
az cognitiveservices account deployment list \
  --name "${FOUNDRY_ACCOUNT}" --resource-group "${RG}" \
  --query "[].{name:name, sku:sku.name}" -o table

Then set a quarterly reminder against four pages: the provider's pricing page, its data residency page, its abuse and retention page, and its subprocessor list. Those four move independently. If nobody owns that reminder, delete the price column from your internal matrix and keep only the decision framework, because a stale price is worse than no price. That is the honest reason most published comparisons are wrong within a quarter, and it is why every row above carries a verification date.