If you've deployed Azure OpenAI in the last two years, you've probably defaulted to Sweden Central. That advice came from a real condition. Sweden Central was where new OpenAI models showed up first, and where capacity was less constrained than the US regions.
As of May 2026, the advice is stale. For UK clients with data-residency requirements, Sweden Central no longer fits. GPT-5 family models in Sweden Central are Global Standard SKU only, meaning prompt processing routes anywhere in Microsoft's cloud globally for operational purposes, breaking the regional residency story. UK South offers Standard regional and Data Zone EU SKUs on the same models. You've been deploying in the wrong region.
The current Foundry catalogue, by region
This is what we found checking the deployable models in each region during the May 1 benchmark setup:
| Region | GPT-5 family, Standard / Data Zone | GPT-5 family, Global Standard only | Multimodal/audio | DeepSeek MaaS |
|---|---|---|---|---|
| UK South | ✓ Standard + Data Zone | also offered | partial | ✓ |
| Sweden Central | ✗ (Global Standard only) | ✓ all variants | ✓ full multimodal | ✓ |
| West Europe | partial (gpt-5 only) | partial | partial | ✓ |
| North Europe | ✗ | partial | ✗ | ✓ (recently added) |
| East US 2 | ✓ Standard + Data Zone | ✓ | ✓ full multimodal | ✓ |
The pattern: UK South is the European region with regional / Data Zone SKUs for the full GPT-5 text family in 2026. Sweden Central has the models, but only on Global Standard, which means prompt processing isn't pinned to the chosen Azure region, defeating residency. Sweden Central's real edge is multimodal: image, audio, realtime API. None of which most enterprise IaC workloads need.
Why this happened
A few things moved at once:
- Microsoft expanded UK South capacity for GPT-5. UK South has been a quiet beneficiary of Microsoft's region rebalancing. GDPR-aligned data residency for UK clients drove demand; Microsoft followed with capacity.
- Sweden Central got prioritised for multimodal. The Audio API, Realtime API, and image-input-rich models landed there first. Text models lagged.
- The default advice didn't update. Documentation, tutorials, and architectural reference patterns still say "Sweden Central for latest OpenAI." The catalogue moved; the guidance didn't.
If you're a UK shop with UK-customer data residency requirements, deploying GPT-5-codex in Sweden Central means accepting Global Standard SKU, which routes processing globally and fails the residency story. The realistic options were "fall back to gpt-4o on a Standard SKU" or "use Sweden Central Global Standard and hope nobody asks." Neither was satisfactory. UK South lifts that tradeoff entirely.
What this changes about the data-residency story
1. UK South can serve UK-customer workloads with frontier models, today
If a UK client mandates UK data residency on prompts and inference, the previous answer was either "use a non-frontier model in UK South" or "use Sweden Central and hope EU residency is acceptable." Neither was great.
The current answer: UK South + GPT-5 family covers the scenario fully. Frontier-quality reasoning, UK data residency, full Microsoft compliance posture (GDPR, ISO 27001, Cyber Essentials Plus). For most UK enterprise clients, this is now the obvious deployment.
2. Sweden Central is the multimodal region
If you need vision (image input/output), audio (Whisper, TTS, Realtime), or specifically the multimodal-tuned GPT-4o variants, deploy in Sweden Central. For text-only LLM workloads in 2026, deploy in UK South.
3. North Europe and West Europe are middle-ground
North Europe has DeepSeek MaaS (recently added) but no GPT-5 family. West Europe has gpt-5 standard but not the codex/pro variants. If you have a workload that's mostly DeepSeek-V3.x on Foundry MaaS with occasional GPT-5 escalation, North Europe is fine. If you need GPT-5-codex, go UK South.
A note on Marketplace partner models (Anthropic Claude, Cohere)
Worth flagging because it crosses regional boundaries: Claude on Foundry doesn't actually run on Azure infrastructure in any region. Inference still routes to Anthropic's systems. So "Claude in UK South" doesn't satisfy a strict Azure-resident sovereignty requirement, even though the Foundry deployment is in UK South.
For clients with strict in-tenant inference requirements, only the Azure-native models (GPT-5 family via AOAI, DeepSeek/Llama/Mistral/Grok/Kimi via Foundry MaaS direct-from-Azure) qualify. Marketplace SaaS models (Claude, Cohere, AI21) are outside the Azure inference perimeter regardless of region.
This is buried in the Foundry product docs. Most architects we've worked with weren't aware of it. It changes which "frontier-quality" models are on the menu for sovereignty-sensitive UK clients. UK South + GPT-5 is in; UK South + Claude is out. Full taxonomy in Three things to check before you commit to Foundry.
What to do about your existing Sweden Central deployments
If you already have AOAI text workloads in Sweden Central:
- Don't migrate immediately. Sweden Central deployments still work; the older GPT-4 family is available there. If your workload runs on gpt-4o, no urgent action needed.
- Plan the GPT-5 cutover in UK South. New deployments of GPT-5-codex / GPT-5 / gpt-5-pro should go in UK South for UK clients. Stand up parallel deployments and route new traffic.
- Keep multimodal in Sweden Central. If you have a Realtime or Whisper deployment, leave it. Sweden Central is the right region for those, indefinitely.
- Audit your reference architecture documents. If you have a "preferred regions" page in your internal docs, update it. The default-to-Sweden advice should now be default-to-UK-South for most text workloads.
This is the kind of update that doesn't make a big splash. Microsoft doesn't announce "we shifted GPT-5 to UK South", but it changes the right answer to "where should I deploy AOAI?" for a meaningful portion of UK Azure shops. Worth getting right.
Companion post covering five other Foundry pricing/deployment gotchas is here.
Need help auditing your current AOAI deployment for residency posture? Request a free assessment.