ms-ai-architect/skills/ms-ai-engineering/references/api-management/multi-region-ai-gateway-design.md

Multi-Region AI Gateway Architecture

Last updated: 2026-06-24 Status: GA Category: API Management & AI Gateway Type: reference Source: https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types Verified: 2026-07-24 Verified by: judge-v3.1

---

Innhold

• Introduksjon
• Global APIM Distribution
• Region-Aware Routing
• Latency Optimization
• Data Residency Compliance
• Cross-Region Failover
• Nettverksarkitektur
• Referanser
• For arkitekten

Introduksjon

Organisasjoner som bygger AI-drevne tjenester med Azure OpenAI og andre LLM-tjenester trenger en gateway-arkitektur som tåler regionale feil, minimerer latens for geografisk distribuerte brukere, og overholder krav til dataresidency. Azure API Management (APIM) med multi-region deployment gir nettopp denne kapabiliteten, og er den anbefalte tilnærmingen for enterprise AI-workloads.

For norsk offentlig sektor er multi-region-design spesielt relevant: mange organisasjoner har krav om at data skal behandles innenfor EØS, men ønsker samtidig redundans og lav latens. APIM Premium (classic)-tier støtter multi-region gateways med én kontrollplan, noe som forenkler administrasjon og gir automatisk failover mellom regioner. (Merk: den nyere Premium v2-tieren støtter availability zones, men IKKE multi-region deployment — multi-region er kun Premium classic.) Denne referansen dekker alle aspekter ved design, deploy og drift av en geografisk distribuert AI-gateway.

En vellykket multi-region AI-gateway-arkitektur balanserer tre hensyn: pålitelighet (at tjenesten overlever regionale feil), ytelse (at brukere opplever lav latens uavhengig av lokasjon), og compliance (at data behandles i henhold til regulatoriske krav). API Management løser alle tre gjennom innebygd FQDN-routing, regionale gateways og policy-basert trafikkhåndtering.

---

Global APIM Distribution

Multi-Region Deployment Architecture

APIM Premium (classic)-tier støtter replikering av gateway-komponenten til flere Azure-regioner. Kontrollplanet (management plane) og utviklerportalen forblir i primærregionen, mens gateway-trafikk håndteres lokalt i hver region.

Komponent	Distribusjon	Merknader
Management plane	Kun primærregion	API-definisjoner, policyer, brukerhåndtering
Developer portal	Kun primærregion	Brukerregistrering, API-dokumentasjon
Gateway	Alle konfigurerte regioner	Håndterer API-trafikk, policy-kjøring
Policy-konfigurasjon	Synkronisert (< 10 sek)	Automatisk propagering til alle regioner

Deployment via Azure Portal

1. Naviger til APIM-instansen → Locations
2. Klikk "+ Add" → Velg region (f.eks. North Europe)
3. Konfigurer antall scale units
4. Aktiver availability zones (anbefalt)
5. Konfigurer VNet/subnet hvis nettverksintegrert
6. Klikk "Add" → gjenta for flere regioner
7. Klikk "Save" for å starte deployment

Bicep-template for Multi-Region APIM

resource apim 'Microsoft.ApiManagement/service@2023-09-01-preview' = {
  name: 'ai-gateway-apim'
  location: 'westeurope'
  sku: {
    name: 'Premium'
    capacity: 2
  }
  properties: {
    publisherEmail: 'admin@example.com'
    publisherName: 'AI Gateway'
    additionalLocations: [
      {
        location: 'northeurope'
        sku: {
          name: 'Premium'
          capacity: 1
        }
        zones: ['1', '2', '3']
      }
      {
        location: 'swedencentral'
        sku: {
          name: 'Premium'
          capacity: 1
        }
        zones: ['1', '2', '3']
      }
    ]
  }
}

Regional DNS-mønster

Hver region får et eget DNS-endepunkt:

Region	URL-mønster
Primary (West Europe)	https://ai-gateway-apim.azure-api.net
West Europe (regional)	https://ai-gateway-apim-westeurope-01.regional.azure-api.net
North Europe (regional)	https://ai-gateway-apim-northeurope-01.regional.azure-api.net
Sweden Central (regional)	https://ai-gateway-apim-swedencentral-01.regional.azure-api.net

---

Region-Aware Routing

Innebygd Latency-basert Routing

APIM tilbyr automatisk FQDN-basert routing som sender trafikk til gatewayen med lavest latens. Dette er standard oppførsel for multi-region deployments og krever ingen ekstra konfigurasjon.

Klient → DNS-oppslag (ai-gateway-apim.azure-api.net)
       → Latency-basert resolving → Nærmeste gateway
       → Lokal policy-kjøring → Backend-kall

Routing til Regionale Backend-tjenester

For å utnytte geografisk distribusjon fullt ut, bør Azure OpenAI-instanser deployes i samme regioner som APIM-gateways. Bruk context.Deployment.Region for å rute til lokale backends:

<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@("West Europe".Equals(context.Deployment.Region,
                              StringComparison.OrdinalIgnoreCase))">
                <set-backend-service backend-id="aoai-westeurope" />
            </when>
            <when condition="@("North Europe".Equals(context.Deployment.Region,
                              StringComparison.OrdinalIgnoreCase))">
                <set-backend-service backend-id="aoai-northeurope" />
            </when>
            <when condition="@("Sweden Central".Equals(context.Deployment.Region,
                              StringComparison.OrdinalIgnoreCase))">
                <set-backend-service backend-id="aoai-swedencentral" />
            </when>
            <otherwise>
                <set-backend-service backend-id="aoai-westeurope" />
            </otherwise>
        </choose>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Backend Pool med Priority-basert Load Balancing

Kombinér regionale backends med priority groups for automatisk failover:

resource backendPool 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'ai-gateway-apim/aoai-pool-westeurope'
  properties: {
    description: 'West Europe pool med failover til North Europe'
    type: 'Pool'
    pool: {
      services: [
        {
          id: '/subscriptions/.../backends/aoai-westeurope'
          priority: 1
          weight: 1
        }
        {
          id: '/subscriptions/.../backends/aoai-northeurope'
          priority: 2
          weight: 1
        }
      ]
    }
  }
}

Egendefinert Routing med Azure Traffic Manager

For scenarier der innebygd routing ikke er tilstrekkelig:

1. Opprett Azure Traffic Manager-profil
2. Konfigurer APIM regionale endepunkter som endpoints
3. Bruk Geographic routing for data residency
4. Konfigurer health probe mot /status-0123456789abcdef
5. Pek custom domain mot Traffic Manager

Routing-metode	Bruksområde
Geographic	Data residency-krav (EØS-region)
Performance	Lavest latens for sluttbrukere
Priority	DR-scenarier med primær/sekundær
Weighted	Gradvis migrering mellom regioner

---

Latency Optimization

Strategier for Lav Latens

Strategi	Beskrivelse	Latensreduksjon
Co-lokalisering	APIM gateway + Azure OpenAI i samme region	Eliminerer cross-region latens
Semantic caching	Cacher tidligere LLM-completions	50-90% for gjentatte prompts
Private endpoints	Direkte nettverksforbindelse uten offentlig internett	10-30ms reduksjon
Connection pooling	Gjenbruk av TCP-forbindelser	50-100ms per request
Regional DNS	Innebygd FQDN med latency-based routing	Automatisk optimal ruting

Semantic Caching med Azure Managed Redis

<inbound>
    <base />
    <llm-semantic-cache-lookup
        score-threshold="0.15"
        embeddings-backend-id="embedding-backend"
        embeddings-backend-auth="system-assigned" />
</inbound>
<outbound>
    <base />
    <llm-semantic-cache-store duration="3600" />
</outbound>

Måling av Regional Latens

Bruk llm-emit-token-metric med regiondimensjon for å spore latens per region:

<llm-emit-token-metric namespace="ai-gateway-metrics">
    <dimension name="Region" value="@(context.Deployment.Region)" />
    <dimension name="API" value="@(context.Api.Name)" />
    <dimension name="Backend" value="@(context.Request.Url.Host)" />
</llm-emit-token-metric>

---

Data Residency Compliance

EØS Data Residency-krav

For norsk offentlig sektor med krav om databehandling innenfor EØS:

Krav	APIM-implementasjon
Data-at-rest i EØS	Deploy APIM primærregion i West Europe/North Europe
Data-in-transit i EØS	Private endpoints + VNet-isolasjon
Ingen cross-geopolitical failover	Separate gateways per geopolitisk grense
Logging i EØS	Log Analytics workspace i EØS-region
Nøkkelhåndtering i EØS	Azure Key Vault i EØS-region

Viktige Advarsler

Ikke implementer en enhetlig gateway på tvers av geopolitiske regioner når data residency er påkrevd:

RIKTIG:
  Gateway (West Europe) → Azure OpenAI (West Europe)
  Gateway (North Europe) → Azure OpenAI (North Europe)
  Separate FQDN per region

FEIL:
  Gateway (West Europe) → Azure OpenAI (East US)  ← Bryter data residency
  Enhetlig gateway med failover til US-region     ← Bryter data residency

Azure OpenAI Deployment Types og Data Residency

Deployment Type	Data Residency	Egnet for offentlig sektor?
Standard	Data i angitt region	Ja, med EØS-region
Provisioned (PTU)	Data i angitt region	Ja, med EØS-region
Data Zone Standard	Data innenfor Azure data zone	Ja, med European data zone
Global Standard	Data kan prosesseres i enhver region	Nei, ikke for data residency-krav

Policy for Data Residency Enforcement

<inbound>
    <base />
    <!-- Blokkér requests som kan rutes utenfor EØS -->
    <choose>
        <when condition="@(!new[] { "West Europe", "North Europe",
                          "Sweden Central", "France Central", "Germany West Central" }
                          .Contains(context.Deployment.Region))">
            <return-response>
                <set-status code="403" reason="Forbidden" />
                <set-body>Data residency violation: Request routed outside EEA</set-body>
            </return-response>
        </when>
    </choose>
</inbound>

---

Cross-Region Failover

Automatisk Failover med Innebygd FQDN

Ved standard multi-region deployment håndterer APIM failover automatisk:

1. Gateway i Region A svarer ikke
2. DNS TTL utløper (typisk 5-10 minutter)
3. Trafikk rutes til Region B (lavest latens blant aktive)
4. Klienter MÅ respektere DNS TTL
5. Retry-logikk i klient håndterer overgangsperiode

Disable/Enable Regional Gateway

For planlagt vedlikehold eller DR-testing:

# Deaktiver gateway i North Europe
az apim update \
  --name ai-gateway-apim \
  --resource-group rg-apim \
  --set additionalLocations[location="North Europe"].disableGateway=true

# Verifiser status
az apim show \
  --name ai-gateway-apim \
  --resource-group rg-apim \
  --query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
  --output table

# Reaktiver etter vedlikehold
az apim update \
  --name ai-gateway-apim \
  --resource-group rg-apim \
  --set additionalLocations[location="North Europe"].disableGateway=false

Active-Active med Active-Passive Azure OpenAI

For maksimal pålitelighet, kombinér active-active gateway med active-passive backend:

Region A (Active):
  APIM Gateway → PTU Azure OpenAI (Priority 1)
               → Standard Azure OpenAI (Priority 2, failover)

Region B (Active):
  APIM Gateway → PTU Azure OpenAI (Priority 1)
               → Standard Azure OpenAI (Priority 2, failover)

Cross-region failover:
  Region A feil → All trafikk til Region B
  Region A PTU throttled → Standard deployment i Region A

Circuit Breaker for Backend Failover

resource backend 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'ai-gateway-apim/aoai-westeurope'
  properties: {
    url: 'https://aoai-westeurope.openai.azure.com'
    protocol: 'http'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: ['Server errors']
            interval: 'PT1M'
            statusCodeRanges: [
              { min: 429, max: 429 }
              { min: 500, max: 599 }
            ]
          }
          name: 'aoai-breaker'
          tripDuration: 'PT30S'
          acceptRetryAfter: true
        }
      ]
    }
  }
}

Kapasitetsplanlegging for Failover

Ved failover må gjenværende regioner absorbere all trafikk:

Scenario	Region A Kapasitet	Region B Kapasitet	Nødvendig overprovisionering
2 regioner, active-active	100% normal load	100% normal load	Hver region: 2x normal
2 regioner, active-passive	100% normal load	0% (standby)	Passiv region: 1x normal
3 regioner, active-active	33% normal load	33% normal load	Hver region: 1.5x normal

Bruk Azure OpenAI Capacity Calculator for PTU-kapasitetsplanlegging.

---

Nettverksarkitektur

Internal VNet Mode — Multi-Region

For scenarier med intern VNet-modus (typisk for offentlig sektor):

Klient → Azure Front Door (WAF) → Private Endpoint → APIM Gateway (Region A)
                                                    → APIM Gateway (Region B)
       → Egenhåndtert routing (Load Balancer/Traffic Manager)

Viktig: I internal VNet-modus håndterer APIM IKKE automatisk routing mellom regionale gateways. Organisasjonen må selv implementere routing via Azure Front Door, Traffic Manager, eller en annen load balancer.

VNet Krav per Region

Hver region krever eget VNet med nødvendige NSG-regler:

Port	Retning	Formål
3443	Inbound	Management traffic
443	Inbound	Client traffic (HTTPS)
1433	Outbound	Azure SQL (primærregion) — påkrevd fra alle regioner
443	Outbound	Azure Storage, Azure Monitor, Key Vault

---

Referanser

• Deploy an Azure API Management instance to multiple Azure regions — Offisiell guide for multi-region deployment
• Use a gateway in front of multiple Azure OpenAI deployments or instances — Arkitekturmønstre for AI gateway
• AI gateway in Azure API Management — Oversikt over AI gateway-kapabiliteter
• Access Azure OpenAI through a gateway — Well-Architected Framework-veiledning
• Azure OpenAI deployment types — Deployment types og data residency

---

For arkitekten

• Bruk denne referansen når kunder trenger en AI-gateway som dekker flere Azure-regioner, eller når data residency og failover er sentrale krav.
• For norsk offentlig sektor: Anbefal alltid EØS-regioner (West Europe, North Europe, Sweden Central) og advar eksplisitt mot Global Standard deployments som kan prosessere data utenfor EØS.
• Husk at rate-limiting policyer (rate-limit, llm-token-limit) teller separat per regional gateway — dette betyr at en 1000 TPM-grense gjelder per region, ikke totalt.
• Start enkelt med to EØS-regioner (West Europe + North Europe) og vurder tredje region (Sweden Central) kun ved behov for høyere tilgjengelighet.
• Kombiner alltid multi-region gateway med circuit breaker og backend pools for å sikre automatisk failover uten manuell intervensjon.