# Regional Deployment for Latency Reduction

**Last updated:** 2026-06-19
**Status:** GA
**Category:** Performance & Scalability
**Type:** reference
**Source:** https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types

---

## Innhold

- [Introduksjon](#introduksjon)
- [Kjernekomponenter](#kjernekomponenter)
- [Region Selection Criteria](#region-selection-criteria)
- [Traffic Routing Strategies](#traffic-routing-strategies)
- [Cross-Region Redundancy](#cross-region-redundancy)
- [Data Residency Requirements](#data-residency-requirements)
- [Azure Front Door — oppdatert (2026-06-19)](#azure-front-door--oppdatert-2026-06-19)
- [Gateway Multi-Backend — 4 topologier (oppdatert 2026-06-19)](#gateway-multi-backend--4-topologier-oppdatert-2026-06-19)
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
- [Beslutningsrammeverk](#beslutningsrammeverk)
- [Referanser](#referanser)
- [For Cosmo](#for-cosmo)

## Introduksjon

Multi-region deployment av Azure OpenAI-tjenester er en strategi for å minimere latens, øke tilgjengelighet og oppfylle krav til dataresidency. Azure OpenAI tilbyr flere deployment-typer som adresserer ulike regionale behov: Global Standard (automatisk routing til region med tilgjengelig kapasitet), Data Zone (data holdes innenfor en geografisk sone som EU), Regional Standard (fast region) og tilsvarende Provisioned-varianter.

For norsk offentlig sektor er regionvalg spesielt viktig på grunn av Schrems II, Personopplysningsloven og krav fra sektorregulering. Azure Norway East er den foretrukne primærregionen, med Sweden Central som sekundær. Azure Front Door og Azure API Management kan brukes som global router foran multiple Azure OpenAI-instanser for å oppnå latens-basert routing med automatisk failover.

Latensforskjellen mellom regioner kan være betydelig: en forespørsel fra Oslo til Norway East har typisk 2-5ms nettverkslatens, mens samme forespørsel til East US legger til 80-120ms. For interaktive AI-applikasjoner der brukeropplevelsen avhenger av time-to-first-token (TTFT), er nær region-plassering en viktig optimaliseringsfaktor.

## Kjernekomponenter

| Komponent | Formål | Teknologi |
|-----------|--------|-----------|
| Azure Front Door | Global load balancing med latens-basert routing | Azure Front Door |
| Azure Traffic Manager | DNS-basert trafikk-routing | Azure Traffic Manager |
| Azure API Management (multi-region) | Gateway med regionalt distribuerte gateways | Azure APIM |
| Private Link | Privat nettverkstilgang til Azure OpenAI | Azure Private Link |
| Azure OpenAI Deployment Types | Global, Data Zone, Regional | Azure OpenAI |

## Region Selection Criteria

### Deployment-typer og regionvalg

> **Anbefaling (Verified MCP 2026-06-19):** Hvis du ikke trenger å begrense databehandling til én bestemt region, bruk **Global** eller **Data Zone**-deployments for å utnytte Azures globale infrastruktur til dynamisk ruting til datasentre med ledig kapasitet — fremfor å bygge kompleks multi-region gateway-logikk.

| Deployment Type | Data Location | Routing | Bruksområde |
|----------------|---------------|---------|-------------|
| Global Standard | Any Azure region | Automatisk til ledig kapasitet | Høyest tilgjengelighet, lavest kostnad |
| Data Zone Standard | Innenfor geografisk sone (EU/US) | Automatisk innen sone | EU data residency |
| Regional Standard | Fast spesifisert region | Ingen routing | Full kontroll over plassering |
| Global Provisioned | Any Azure region | Automatisk | PTU med global routing |
| Data Zone Provisioned | Innenfor sone | Automatisk innen sone | PTU med data residency |
| Regional Provisioned | Fast region | Ingen | PTU med full regionkontroll |

### Regionsvalg for norsk offentlig sektor

```python
# Regionsprioriteringer for norske offentlige virksomheter
REGION_PRIORITIES = {
    "tier_1_preferred": {
        "regions": ["norwayeast"],
        "rationale": "Primær: Norsk region, lavest latens, data i Norge",
        "data_residency": "Norway",
        "network_latency_from_oslo_ms": 2
    },
    "tier_2_fallback": {
        "regions": ["swedencentral"],
        "rationale": "Sekundær: Nær region, EU data residency",
        "data_residency": "EU/EEA",
        "network_latency_from_oslo_ms": 8
    },
    "tier_3_extended": {
        "regions": ["westeurope", "northeurope"],
        "rationale": "Tertiær: EU-regioner for høy tilgjengelighet",
        "data_residency": "EU/EEA",
        "network_latency_from_oslo_ms": 25
    },
    "avoid_for_sensitive": {
        "regions": ["eastus", "eastus2", "westus"],
        "rationale": "Unngå for personopplysninger — utenfor EU/EØS",
        "data_residency": "US",
        "network_latency_from_oslo_ms": 90
    }
}

def select_regions_for_workload(
    data_classification: str,  # "public", "internal", "confidential"
    latency_requirement_ms: float = 100,
    availability_requirement: float = 99.9
) -> list[dict]:
    """Select appropriate regions based on requirements."""
    if data_classification == "confidential":
        return [REGION_PRIORITIES["tier_1_preferred"]]
    elif data_classification == "internal":
        regions = [
            REGION_PRIORITIES["tier_1_preferred"],
            REGION_PRIORITIES["tier_2_fallback"]
        ]
        if availability_requirement > 99.9:
            regions.append(REGION_PRIORITIES["tier_3_extended"])
        return regions
    else:  # public
        return [
            REGION_PRIORITIES["tier_1_preferred"],
            REGION_PRIORITIES["tier_2_fallback"],
            REGION_PRIORITIES["tier_3_extended"]
        ]
```

## Traffic Routing Strategies

### Azure API Management multi-region

```xml
<!-- APIM Policy: Latens-basert routing til Azure OpenAI backends -->
<policies>
    <inbound>
        <base />

        <!-- Definer backend-pool med prioritet -->
        <set-variable name="backends" value="@{
            var backends = new JArray();
            backends.Add(new JObject(
                new JProperty("url",
                    "https://aoai-norway.openai.azure.com"),
                new JProperty("priority", 1),
                new JProperty("region", "norwayeast")));
            backends.Add(new JObject(
                new JProperty("url",
                    "https://aoai-sweden.openai.azure.com"),
                new JProperty("priority", 2),
                new JProperty("region", "swedencentral")));
            backends.Add(new JObject(
                new JProperty("url",
                    "https://aoai-westeu.openai.azure.com"),
                new JProperty("priority", 3),
                new JProperty("region", "westeurope")));
            return backends.ToString();
        }" />

        <!-- Route til region basert på APIM gateway location -->
        <set-backend-service
            base-url="@{
                var region = context.Deployment.Region;
                if (region.Contains("norway"))
                    return "https://aoai-norway.openai.azure.com";
                if (region.Contains("sweden"))
                    return "https://aoai-sweden.openai.azure.com";
                return "https://aoai-westeu.openai.azure.com";
            }" />
    </inbound>

    <backend>
        <!-- Retry til neste region ved feil -->
        <retry condition="@(
            context.Response.StatusCode == 429 ||
            context.Response.StatusCode >= 500)"
            count="2"
            interval="0"
            first-fast-retry="true">
            <choose>
                <when condition="@(
                    context.Response.StatusCode == 429)">
                    <!-- Bytt til neste region -->
                    <set-backend-service
                        base-url="@{
                            // Roter til neste backend i prioritet
                            return context.Variables
                                .GetValueOrDefault<string>(
                                    "fallback-url",
                                    "https://aoai-sweden.openai.azure.com");
                        }" />
                </when>
            </choose>
            <forward-request />
        </retry>
    </backend>
</policies>
```

### Azure Front Door konfigurasjon

```bash
# Opprett Azure Front Door med latens-basert routing til OpenAI

# 1. Opprett Front Door profil
az afd profile create \
  --resource-group rg-ai-networking \
  --profile-name fd-ai-gateway \
  --sku Premium_AzureFrontDoor

# 2. Opprett endpoint
az afd endpoint create \
  --resource-group rg-ai-networking \
  --profile-name fd-ai-gateway \
  --endpoint-name ai-openai \
  --enabled-state Enabled

# 3. Opprett origin group med latens-basert routing
az afd origin-group create \
  --resource-group rg-ai-networking \
  --profile-name fd-ai-gateway \
  --origin-group-name aoai-backends \
  --probe-request-type GET \
  --probe-protocol Https \
  --probe-path "/openai/deployments?api-version=2024-10-21" \
  --probe-interval-in-seconds 30 \
  --sample-size 4 \
  --successful-samples-required 3 \
  --additional-latency-in-milliseconds 50

# 4. Legg til origins (Azure OpenAI instanser)
az afd origin create \
  --resource-group rg-ai-networking \
  --profile-name fd-ai-gateway \
  --origin-group-name aoai-backends \
  --origin-name aoai-norway \
  --host-name aoai-norway.openai.azure.com \
  --origin-host-header aoai-norway.openai.azure.com \
  --priority 1 \
  --weight 1000 \
  --enabled-state Enabled \
  --https-port 443

az afd origin create \
  --resource-group rg-ai-networking \
  --profile-name fd-ai-gateway \
  --origin-group-name aoai-backends \
  --origin-name aoai-sweden \
  --host-name aoai-sweden.openai.azure.com \
  --origin-host-header aoai-sweden.openai.azure.com \
  --priority 2 \
  --weight 500 \
  --enabled-state Enabled \
  --https-port 443
```

## Cross-Region Redundancy

### Active-active deployment pattern

```python
# Multi-region health check og failover
from dataclasses import dataclass
import aiohttp
import asyncio

@dataclass
class RegionHealth:
    region: str
    endpoint: str
    is_healthy: bool
    latency_ms: float
    last_check: float

class MultiRegionHealthChecker:
    """Monitor health across Azure OpenAI regions."""

    def __init__(self, regions: list[dict], check_interval: int = 30):
        self.regions = regions
        self.check_interval = check_interval
        self.health: dict[str, RegionHealth] = {}

    async def check_all(self):
        """Check health of all regions."""
        tasks = [
            self._check_region(r["region"], r["endpoint"], r["api_key"])
            for r in self.regions
        ]
        await asyncio.gather(*tasks)

    async def _check_region(self, region: str, endpoint: str, api_key: str):
        start = time.time()
        try:
            async with aiohttp.ClientSession() as session:
                async with session.get(
                    f"{endpoint}/openai/deployments"
                    f"?api-version=2024-10-21",
                    headers={"api-key": api_key},
                    timeout=aiohttp.ClientTimeout(total=10)
                ) as resp:
                    latency = (time.time() - start) * 1000
                    self.health[region] = RegionHealth(
                        region=region,
                        endpoint=endpoint,
                        is_healthy=resp.status < 400,
                        latency_ms=round(latency, 1),
                        last_check=time.time()
                    )
        except Exception:
            self.health[region] = RegionHealth(
                region=region,
                endpoint=endpoint,
                is_healthy=False,
                latency_ms=9999,
                last_check=time.time()
            )

    def get_best_region(self) -> str:
        """Get the healthiest, lowest-latency region."""
        healthy = [
            h for h in self.health.values()
            if h.is_healthy
        ]
        if not healthy:
            return self.regions[0]["region"]

        return min(healthy, key=lambda h: h.latency_ms).region
```

## Data Residency Requirements

### EU/EØS data residency-matrise

| Krav | Global Standard | Data Zone (EU) | Regional (Norway East) |
|------|----------------|----------------|----------------------|
| Data prosesseres i EU | Nei (global) | Ja | Ja |
| Data lagres i Norge | Nei | Nei (EU) | Ja |
| Schrems II-kompatibel | Delvis | Ja | Ja |
| Personopplysninger OK | Avhenger av DPA | Ja med DPA | Ja med DPA |
| Gradert informasjon | Nei | Nei | Avhenger av sertifisering |
| Metadata i EU | Nei | Ja | Ja |


## Azure Front Door — oppdatert (2026-06-19)

### Edge-lokasjoner og kapabiliteter

Azure Front Door har **118+ edge-lokasjoner** på tvers av 100+ metroområder globalt (bekreftet 2026-06-19). Premium-tier støtter:
- **Private Link til origins**: Front Door Premium kan rute trafikk til Azure OpenAI via Private Link — ingen offentlig eksponering av backend
- **WAF-regler**: Innebygd Web Application Firewall (managed rule sets, bot manager) foran backend

```bash
# Front Door Premium med Private Link til Azure OpenAI
az afd origin create \
  --resource-group rg-ai-networking \
  --profile-name fd-ai-gateway \
  --origin-group-name aoai-backends \
  --origin-name aoai-norway \
  --host-name aoai-norway.openai.azure.com \
  --origin-host-header aoai-norway.openai.azure.com \
  --priority 1 \
  --weight 1000 \
  --enabled-state Enabled \
  --https-port 443 \
  --enable-private-link true \
  --private-link-location norwayeast \
  --private-link-resource "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/aoai-norway" \
  --private-link-sub-resource-type account
```

## Gateway Multi-Backend — 4 topologier (oppdatert 2026-06-19)

Microsoft dokumenterer nå fire formelle topologier for Azure OpenAI gateway:

| Topologi | Beskrivelse | Bruksscenario |
|----------|-------------|---------------|
| Multiple model deployments, single instance | Flere modell-deployments i én instans | Modellversjoner, blue-green, per-tenant kvoter |
| Single region, multiple instances | Én region, flere Azure OpenAI-instanser | Load balancing og failover |
| Single region, multiple subscriptions | Kvote-utvidelse via flere Azure-subscriptions | Høy TPM-kvote krav |
| Multiple regions | APIM i flere regioner, globalt | Global distribusjon, data residency |

### Topologi 3: Multiple subscriptions for kvote-utvidelse

```xml
<!-- APIM Policy: Distribuer last over subscriptions for kvote-utvidelse -->
<policies>
    <inbound>
        <base />
        <set-variable name="subscription-backends" value="@{
            var backends = new JArray(
                new JObject(
                    new JProperty('url', 'https://aoai-sub1.openai.azure.com'),
                    new JProperty('subscription', 'sub1')),
                new JObject(
                    new JProperty('url', 'https://aoai-sub2.openai.azure.com'),
                    new JProperty('subscription', 'sub2')),
                new JObject(
                    new JProperty('url', 'https://aoai-sub3.openai.azure.com'),
                    new JProperty('subscription', 'sub3'))
            );
            // Round-robin mellom subscriptions
            var idx = (int)(DateTimeOffset.UtcNow.ToUnixTimeSeconds() / 60) % 3;
            return backends[idx]['url'].ToString();
        }" />
        <set-backend-service base-url="@(context.Variables.GetValueOrDefault<string>("subscription-backends"))" />
    </inbound>
</policies>
```

## Norsk offentlig sektor

- **Primær region**: Norway East for alle workloads med personopplysninger. Sweden Central som failover.
- **Data Zone**: Bruk Data Zone deployments (Standard eller Provisioned) for automatisk EU-routing med data residency-garanti.
- **Private Link**: Konfigurer Private Endpoints for Azure OpenAI i hver region for å unngå at data traverserer offentlig internett.
- **Utredningsinstruksen**: Dokumenter regionvalg og data residency-implikasjoner i AI-utredningen.
- **Anskaffelsesreglement**: Ved bruk av Global deployments, verifiser at Microsoft DPA dekker alle regioner data kan prosesseres i.

## Beslutningsrammeverk

| Scenario | Anbefaling | Begrunnelse |
|----------|------------|-------------|
| Lav latens, norske brukere | Regional Norway East | 2ms nettverkslatens |
| EU data residency krav | Data Zone EU | Automatisk routing innen EU |
| Høy tilgjengelighet (99.99%) | Multi-region med Front Door | Overlevere regional outage |
| Sensitive personopplysninger | Regional Norway East, Private Link | Full kontroll, ingen global routing |
| Global brukerbase | Global Standard | Automatisk latens-optimalisering |
| PTU med failover | Data Zone Provisioned + Standard fallback | PTU for normal, Standard for peak |

## Referanser

- [Use a gateway in front of multiple Azure OpenAI deployments or instances](https://learn.microsoft.com/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend) — Multi-region patterns (Azure OpenAI i Foundry Models) — Verified (MCP 2026-06-19)
- [Azure Front Door](https://learn.microsoft.com/azure/frontdoor/front-door-overview) — Global load balancing
- [APIM multi-region deployment](https://learn.microsoft.com/azure/api-management/api-management-howto-deploy-multi-region) — Regional gateway
- [Azure OpenAI deployment types](https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types) — Global vs Regional
- [AI Ready — Establish AI reliability](https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/ready) — Multi-region best practices

## For Cosmo

- **Bruk denne referansen** når kunden trenger å velge Azure-region for Azure OpenAI, designer multi-region arkitektur, eller har krav til data residency.
- For norsk offentlig sektor: start med Regional Norway East + Data Zone EU failover — dette dekker de fleste krav.
- Azure API Management multi-region gir den mest fleksible løsningen med policy-basert routing og circuit breaker — anbefal dette for enterprise.
- Latensforskjellen mellom Norway East (2ms) og East US (90ms) er merkbar for interaktive applikasjoner — regionvalg påvirker brukeropplevelsen direkte.
- Private Link er obligatorisk for sensitive workloads — sørg for at Private Endpoints konfigureres i ALLE regioner som brukes.