ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/multi-region-azure-openai-deployment.md

Multi-Region Azure OpenAI Deployment

Last updated: 2026-06-24 Status: GA Category: Business Continuity & Disaster Recovery Type: reference Source: https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure

---

Innhold

• Introduksjon
• Regionvalg for Norge og EU
• Lastbalansering mellom OpenAI-endepunkter
• Latensoptimalisering og Proximity Routing
• Kvoteadministrasjon per region
• Kostnadsmodell for multi-region
• Implementeringssjekkliste
• Referanser
• For arkitekten

Introduksjon

Azure OpenAI-tjenester er tilgjengelige i flere Azure-regioner, og når en ressurs opprettes, knyttes den permanent til den valgte regionen. For virksomhetskritiske AI-applikasjoner i norsk offentlig sektor er det avgjorende a planlegge for regional redundans. Et regionalt utfall -- selv om det er sjeldent -- kan lamme AI-drevne tjenester som chatboter, dokumentanalyse og beslutningsstotte dersom all trafikk er avhengig av et enkelt endepunkt. Multi-region-deployering loeser dette ved a spre arbeidsbelastningen over flere Azure-regioner med intelligent lastbalansering og automatisk failover.

For norske organisasjoner er regionvalg spesielt viktig pa grunn av krav til datasuverenitet og personvern under GDPR og Schrems II. Azure Norway East er den primaere regionen for norsk offentlig sektor, men modellutvalget er begrenset sammenlignet med Sweden Central. En velplanlagt multi-region-arkitektur kombinerer naerhet (lav latens), compliance (data innenfor EU/EOeS), og kapasitet (bredere modelltilgang) pa en balansert mate. Data Zone-deployeringer forenkler dette ved a la Azure optimere ruting innenfor en geografisk sone (f.eks. EU) uten at kunden selv ma administrere lastbalansering mellom individuelle regioner.

Denne referansen dekker regionvalg for Norge og EU, lastbalanseringsmonstre via Azure API Management, latensoptimalisering med proximity routing, kvoteadministrasjon per region, og kostnadsmodeller for multi-region-oppsett. Alt er forankret i Microsofts offisielle BCDR-veiledning for Azure OpenAI og arkitekturmoenstre for generative AI gateways.

Regionvalg for Norge og EU

Tilgjengelige regioner med Azure OpenAI

Region	Primaer bruk	Modellstotte	Latens fra Norge	Datasuverenitet
Norway East	Primaer region	Begrenset (gpt-4o 2024-11-20)	< 10 ms	Norge/EU
Sweden Central	Sekundaer/failover	Bred (gpt-4o, o1, gpt-4o-mini)	~15-25 ms	EU
West Europe	Alternativ	Begrenset (gpt-4o-mini)	~30-40 ms	EU
UK South	Alternativ	Moderat (gpt-4o, gpt-4o-mini)	~35-45 ms	UK (tilstrekkelig for mange bruksomrader)
France Central	Alternativ	Bred (gpt-4o, o1)	~35-45 ms	EU

Anbefalte regionkombinasjoner

For norsk offentlig sektor (strengt EU-krav):

Primaer:    Norway East   (lavest latens, norsk datasuverenitet)
Sekundaer:  Sweden Central (bredest modellstotte i Norden)
Tertiaer:   France Central (EU-failover utenfor Norden)

For Data Zone-deployeringer (anbefalt av Microsoft):

Data Zone:  EU
Primaer:    Norway East endpoint
Sekundaer:  Sweden Central endpoint (samme Data Zone-pool)

Viktig: Data Zone-deployeringer er mer effektive og enklere enn selvadministrert lastbalansering mellom regionale deployeringer. Azure optimerer ruting og prosessering pa tvers av tilgjengelig compute i datasonen. Bruk Data Zone som standard for Standard-deployeringer.

Beslutningstre for regionvalg

Trenger du datalagring KUN i Norge?
  |-- Ja --> Norway East (kun region)
  |       Merk: Begrenset modellstotte, hoeyre risiko ved utfall
  |
  |-- Nei --> Aksepterer du EU/EOeS databehandling?
              |-- Ja --> Data Zone EU (anbefalt)
              |       Primaer: Norway East
              |       Sekundaer: Sweden Central
              |
              |-- Nei --> Vurder Global Standard
                       (data kan behandles globalt, hoeyest kapasitet)

Lastbalansering mellom OpenAI-endepunkter

Arkitekturmonstre

Microsoft anbefaler en Generative AI Gateway foran Azure OpenAI-endepunktene. Azure API Management (APIM) er den foretrukne PaaS-loesningen for dette.

Moenster 1: APIM single-region med multi-region backends

                    +------------------+
                    |    Klient/App    |
                    +--------+---------+
                             |
                    +--------v---------+
                    | Azure API Mgmt   |
                    | (Norway East)    |
                    +--+------------+--+
                       |            |
              +--------v--+  +-----v-------+
              | Azure AOAI |  | Azure AOAI  |
              | Norway East|  | Sweden Cent.|
              | (primaer)  |  | (sekundaer) |
              +------------+  +-------------+

Fordeler: Enklest a sette opp, sentralisert policy-styring. Ulemper: APIM er single point of failure. Egress-kostnader for cross-region trafikk.

Moenster 2: APIM multi-region deployment

                    +------------------+
                    |    Klient/App    |
                    +--------+---------+
                             |
                   +---------v----------+
                   | Azure Front Door / |
                   | Traffic Manager    |
                   +---------+----------+
                             |
              +--------------+---------------+
              |                              |
    +---------v----------+     +-------------v--------+
    | APIM Gateway       |     | APIM Gateway         |
    | Norway East        |     | Sweden Central       |
    +--------+-----------+     +-----------+----------+
             |                             |
    +--------v-----------+     +-----------v----------+
    | Azure AOAI         |     | Azure AOAI           |
    | Norway East        |     | Sweden Central       |
    +--------------------+     +----------------------+

Fordeler: Ingen single point of failure, ytelsesbasert ruting. Ulemper: Hoeyre kostnad, mer kompleks drift.

Moenster 3: Data Zone med enkel gateway

                    +------------------+
                    |    Klient/App    |
                    +--------+---------+
                             |
                    +--------v---------+
                    | Azure API Mgmt   |
                    | (Norway East)    |
                    +--------+---------+
                             |
                    +--------v---------+
                    | Azure AOAI       |
                    | Data Zone: EU    |
                    | (Azure ruter     |
                    |  automatisk)     |
                    +------------------+

Fordeler: Enklest, Azure haandterer intern ruting i EU-sonen. Ulemper: Mindre kontroll over noyaktig hvilken region som brukes.

APIM Backend Pool-konfigurasjon

Azure API Management stoetter backend pools med innebygd lastbalansering:

{
  "type": "Microsoft.ApiManagement/service/backends",
  "name": "openai-backend-pool",
  "properties": {
    "type": "Pool",
    "pool": {
      "services": [
        {
          "id": "/backends/norway-east-openai",
          "priority": 1,
          "weight": 3
        },
        {
          "id": "/backends/sweden-central-openai",
          "priority": 1,
          "weight": 1
        },
        {
          "id": "/backends/france-central-openai",
          "priority": 2,
          "weight": 1
        }
      ]
    }
  }
}

Lastbalanseringsalternativer i APIM

Metode	Beskrivelse	Bruksomrade
Round-robin	Fordeler jevnt mellom backends	Standard for lik kapasitet
Vektet	Basert pa vekt per backend	Ulik kapasitetsallokering
Prioritetsbasert	Hoeyere prioritet forst, lavere som fallback	PTU primaer, Standard sekundaer
Session affinity	Samme bruker til samme backend	Chat/agent-scenarier med kontekst

Circuit Breaker-policy i APIM

Gatewayen ma respektere throttling-signaler (HTTP 429) og fjerne feilede backends fra poolen:

<policies>
  <inbound>
    <base />
    <set-backend-service backend-id="openai-backend-pool" />
  </inbound>
  <backend>
    <retry condition="@(context.Response.StatusCode == 429)"
           count="3"
           interval="0"
           first-fast-retry="true">
      <set-backend-service backend-id="openai-backend-pool" />
      <forward-request buffer-request-body="true" />
    </retry>
  </backend>
  <outbound>
    <base />
  </outbound>
</policies>

Beste praksis: Bruk Retry-After-headeren fra Azure OpenAI for a styre circuit breaker-logikken. Ikke proev a forutsi throttling; bruk HTTP-responskoder for a drive rutingbeslutninger.

Latensoptimalisering og Proximity Routing

Strategier for lav latens

Strategi	Implementasjon	Effekt
Co-lokalisering	Gateway og AOAI i samme region	Eliminerer cross-region latens
Private Endpoints	Azure Private Link for alle AOAI-instanser	Reduserer nettverkshopp
Azure Front Door	Performance-based routing til naermeste gateway	Automatisk proximity routing
ExpressRoute	Dedikert forbindelse fra on-premises	Stabil, lav latens

Private Endpoint-arkitektur

On-premises nettverk (Direktoratet for digital tjenesteutvikling)
    |
    +-- ExpressRoute --> Azure vNet (Norway East)
                            |
                            +-- Private Endpoint --> APIM (Norway East)
                            |
                            +-- Private Endpoint --> AOAI (Norway East)
                            |
                            +-- vNet Peering --> Azure vNet (Sweden Central)
                                                    |
                                                    +-- Private Endpoint --> AOAI (Sweden Central)

DNS-konfigurasjon for failover

For privat nettverkstilgang kan en split-brain DNS-tilnaerming brukes:

Normaltilstand:
  aoai-gateway.intern.ddt.no --> APIM Norway East (privat IP)

Ved regional utfall:
  aoai-gateway.intern.ddt.no --> APIM Sweden Central (privat IP)
  (manuell DNS-endring eller Azure Private DNS zones)

Merk: Azure har per i dag ikke en native tjeneste for global server load balancer for arbeidsbelastninger som krever privat DNS-opploesning. Organisasjoner kan oppna active/passive-moenster gjennom a endre DNS-posten for gatewayen.

Kvoteadministrasjon per region

Kvotesystemet i Azure OpenAI

Kvote tildeles per abonnement + region + modell i enheter av Tokens-per-Minute (TPM). Nar en deployment opprettes, trekkes TPM fra tilgjengelig kvote.

Parameter	Beskrivelse
TPM (Tokens Per Minute)	Primaer kvoteenhet, tildelt per deployment
RPM (Requests Per Minute)	Avledet fra TPM, ratio varierer per modell
Maks ressurser per region	30
Deployeringer per modell	Ingen begrensning (fjernet med nytt kvotesystem)

Eksempel: RPM/TPM-ratio per modell

Modell	1 Kapasitetsenhet	RPM	TPM
gpt-4o og eldre chat	1	6	1 000
o1, o1-preview	1	1	6 000
o3-mini, o1-mini, o3-pro	1	1	10 000
o3, o4-mini	1	1	1 000

Kvotestrategi for multi-region

Abonnement: DDT-AI-Prod
  |
  +-- Norway East
  |     +-- gpt-4o Data Zone: 120K TPM (primaer)
  |     +-- gpt-4o-mini: 60K TPM
  |
  +-- Sweden Central
  |     +-- gpt-4o Data Zone: 120K TPM (sekundaer)
  |     +-- gpt-4o-mini: 120K TPM
  |     +-- o1-mini Global Standard: 80K TPM
  |
  +-- France Central (failover)
        +-- gpt-4o Standard: 60K TPM

Tips: Alloker full tilgjengelig kvote til hvert endepunkt. Siden kvote er per abonnement + region, pavirker ikke deployeringer i forskjellige regioner hverandre. Hvis kvoten er oppbrukt, kan et nytt abonnement deployeres pa samme mate bak gatewayen.

Overvaking av kvotebruk

# Sjekk kapasitet per modell/region via REST API
az rest --method get \
  --url "https://management.azure.com/subscriptions/{sub-id}/providers/Microsoft.CognitiveServices/modelCapacities?api-version=2024-06-01-preview&modelName=gpt-4o&modelVersion=2024-11-20"

Bruk Microsoft Foundry portal (Management > Quota) for oversikt over kvoteallokeringer pa tvers av deployeringer i en gitt region.

Kostnadsmodell for multi-region

Kostnadskomponenter

Komponent	Kostnadsdriver	Estimat (NOK/maned)
Azure OpenAI Standard	Token-forbruk per region	Varierer per bruk
Azure OpenAI PTU	Fast pris per PTU-enhet	~170 NOK/PTU/time
APIM Premium	Per gateway-enhet per region	~30 000 NOK/enhet/maned
APIM Standard v2	Per enhet	~8 000 NOK/enhet/maned
Egress-trafikk	Cross-region dataoverforing	~0,70 NOK/GB
Private Endpoints	Per endepunkt per time	~80 NOK/endepunkt/maned
Azure Front Door	Per profil + trafikk	Fra ~3 500 NOK/maned

Kostnadsoptimaliseringsstrategi: PTU + Standard spillover

Microsoft anbefaler a kombinere Provisioned Throughput Units (PTU) med Standard-deployeringer:

Prioritet 1: Enterprise PTU Pool (Region A)
  - Fast pris, garantert kapasitet
  - Bruk all kapasitet foerst

Prioritet 2: Enterprise PTU Pool (Region B)
  - Beskytter mot regionalt utfall
  - Redundans for PTU

Prioritet 3: Standard Data Zone (EU)
  - Pay-per-token for trafikktopper
  - Spillover fra PTU

Eksempel: Kostnadssammenligning (maned)

Scenario	Oppsett	Estimert kostnad (NOK)
Enkel region	1x AOAI Standard + APIM Std v2	15 000 - 25 000
Dual region (Data Zone)	2x AOAI Data Zone + APIM Std v2	20 000 - 35 000
Enterprise PTU + failover	PTU (100 enheter) + Standard failover + APIM Premium	200 000 - 350 000
Full HA multi-region	APIM Premium multi-region + 3x AOAI + Front Door	120 000 - 250 000

Merk: Kostnadsestimatene er veiledende og avhenger sterkt av trafikkvolum, modellvalg og PTU-allokering. Bruk Azure Pricing Calculator for noyaktige estimater.

Kostnadsbesparende tips

1. Bruk Data Zone-deployeringer fremfor selvadministrert multi-region -- enklere og mer kostnadseffektivt
2. Alloker PTU for baseline-trafikk, Standard for topper (spillover-moenster)
3. Plasser PTU og Standard i forskjellige regioner -- unnga a miste begge ved regionalt utfall
4. Konsolider gjennom felles Enterprise PTU Pool -- hoeyere utnyttelse nar trafikk fra flere applikasjoner jevnes ut
5. Unnga APIM Premium med mindre du trenger multi-region gateway -- Standard v2 er tilstrekkelig for mange scenarier

Implementeringssjekkliste

• Velg primaer og sekundaer region basert pa compliance-krav og modellbehov
• Deploy Azure OpenAI-ressurser i begge regioner med identiske modelldeployeringer
• Konfigurer APIM med backend pool og prioritetsbasert lastbalansering
• Implementer circuit breaker-policy som respekterer 429 og Retry-After
• Sett opp Private Endpoints for alle AOAI-instanser
• Konfigurer overvaking av kvotebruk og latens per region
• Dokumenter failover-prosedyre og test regelmessig
• Etabler varsling ved regionalt utfall eller hoey feilrate

Referanser

• Business Continuity and Disaster Recovery (BCDR) considerations with Azure OpenAI
• Use a gateway in front of multiple Azure OpenAI deployments or instances
• Backends in API Management - Load-balanced pool
• Manage Azure OpenAI quota
• Azure OpenAI model availability by region
• Smart Load Balancing for OpenAI with Azure API Management

For arkitekten

• Bruk denne referansen nar kunden spoer om multi-region-deployering, lastbalansering, eller failover for Azure OpenAI -- spesielt for produksjonsmiljoeer som krever hoey tilgjengelighet.
• Anbefal Data Zone-deployeringer som foerstevalg for norsk offentlig sektor. De fleste organisasjoner trenger ikke selvadministrert multi-region lastbalansering -- Data Zone haandterer dette innenfor EU-sonen.
• Vurder regionkombinasjonen Norway East + Sweden Central som standard for nordiske organisasjoner med EU-compliance-krav, men paapek at Norway East har begrenset modellstotte.
• Bruk kostnadstabellene for a gi konkrete estimater i NOK nar kunden trenger budsjettgrunnlag. Juster basert pa trafikkvolum og modellvalg.
• Flagg alltid APIM som anbefalt gateway -- Microsoft anbefaler dette eksplisitt i sin arkitekturveiledning, og det gir circuit breaker, retry, logging og lastbalansering som en PaaS-tjeneste.