# Multi-Region Azure OpenAI Deployment

**Last updated:** 2026-02
**Status:** GA
**Category:** Business Continuity & Disaster Recovery

---

## 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-35-turbo) | ~15-25 ms | EU |
| West Europe | Alternativ | Begrenset (gpt-35-turbo) | ~30-40 ms | EU |
| UK South | Alternativ | Moderat (gpt-4o, gpt-35-turbo) | ~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:

```json
{
  "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:

```xml
<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-35-turbo: 60K TPM
  |
  +-- Sweden Central
  |     +-- gpt-4o Data Zone: 120K TPM (sekundaer)
  |     +-- gpt-35-turbo: 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

```bash
# 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](https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/high-availability-resiliency)
- [Use a gateway in front of multiple Azure OpenAI deployments or instances](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend)
- [Backends in API Management - Load-balanced pool](https://learn.microsoft.com/en-us/azure/api-management/backends#load-balanced-pool)
- [Manage Azure OpenAI quota](https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/quota)
- [Azure OpenAI model availability by region](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure)
- [Smart Load Balancing for OpenAI with Azure API Management](https://github.com/Azure-Samples/openai-apim-lb)

## For Cosmo

- **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.
