ms-ai-architect/skills/ms-ai-security/references/performance-scalability/regional-deployment-latency.md

Regional Deployment for Latency Reduction

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

---

Innhold

• Introduksjon
• Kjernekomponenter
• Region Selection Criteria
• Traffic Routing Strategies
• Cross-Region Redundancy
• Data Residency Requirements
• Azure Front Door — oppdatert (2026-06-19)
• Gateway Multi-Backend — 4 topologier (oppdatert 2026-06-19)
• Norsk offentlig sektor
• Beslutningsrammeverk
• Referanser
• 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

# 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

<!-- 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

# 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

# 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

# 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

<!-- 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 — Multi-region patterns (Azure OpenAI i Foundry Models) — Verified (MCP 2026-06-19)
• Azure Front Door — Global load balancing
• APIM multi-region deployment — Regional gateway
• Azure OpenAI deployment types — Global vs Regional
• AI Ready — Establish AI reliability — 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.