Azure OpenAI EU Data Zone: residens uten kapasitet

EU Data Zone i Azure OpenAI bestemmer hvor prompter og svar behandles, men sier ingenting om hvor mye kapasitet abonnementet ditt får. Et nytt abonnement kan starte med null kvote, og forespørsler om mer kan bli avslått. Jeg mener residens og kapasitet må planlegges som to ulike spørsmål, og at det andre ofte glemmes.

Residens er løst, kapasitet er det ikke

KSJ driver en SharePoint-assistent på Azure OpenAI i EU og har beskrevet en sak mange vil kjenne igjen. 19. september 2026 opprettet de et abonnement. Tildelingen for flaggskipmodellen i EU Data Zone sto på 0, og embedding-modellen text-embedding-3-large lå på 0 der, men på 350 000 tokens per minutt (TPM) i regional Standard. De sendte fire forespørsler om mer kvote, tre for EU Data Zone og én for Global Standard. Alle ble avslått, to av dem innen fire minutter. Teksten ba om et bredere regionvalg eller minst 30 dagers ventetid før nytt forsøk i samme region. Slik jeg ser det er det et typisk hull i compliance-planer: de svarer på hvor data behandles, men ikke på om modellen lar seg kjøre der.

Hva Data Zone lover

Dokumentasjonen om deployment-typer skiller mellom lagring og prosessering. For alle typer ligger data i hvile i den valgte Azure-geografien. Prosesseringen varierer: Global kan behandle prompter og svar i hvilken som helst Azure-region, Data Zone bare i den angitte sonen, og Standard i geografien du har valgt. For EU følger sonen EU Data Boundary, som ifølge Microsoft kan omfatte EFTA-land som Norge og Sveits. Microsoft kan også legge til regioner i en sone uten forhåndsvarsel. Jeg vil anbefale at behandlingsprotokollen sier «EU Data Boundary», ikke en enkelt region eller et enkelt land. Hvordan du ellers sikrer personopplysninger i norske virksomheter, har jeg skrevet om i GDPR-guiden.

Deployment-type	Hvor prosesseringen skjer	Når nye modeller kommer
Global Standard	Hvilken som helst Azure-region	Først
Data Zone Standard	Innenfor EU-sonen	Som nummer to
Standard (regional)	Innenfor valgt geografi	Sist, uten garantert dato

Rekkefølgen for nye modeller er Global først, deretter sone og til slutt geografi. Microsoft peker på Global Standard som utgangspunkt. Jeg synes det forteller hva et EU-krav koster: du aksepterer bevisst å ligge ett steg bak på nye modeller.

Residens betyr heller ikke at ingenting forlater sonen. Microsoft beskriver at noen overføringer ut av grensen fortsetter: for driftsformål, ved kontrollert fjerntilgang fra personell utenfor grensen, og når kundens egen bruk fører data ut. Jeg foreslår at risikovurderingen nevner alle tre, siden en Data Zone-deployment bare avgjør hvor selve modellkjøringen skjer.

Kvote følger abonnementet

Kvote tildeles per abonnement, region, modell og deployment-type, målt i TPM. Høyeste scope er abonnementet, ikke tenant. Når potten er tom, kan du flytte TPM fra andre deployments av samme modell eller be om mer. Etter 7. mai 2026 flytter Microsoft tildelingen til delte pooler på abonnementsnivå. Det begynner med et par modeller, og alle skal følge på sikt. Data Zone Standard får én pool per modell og versjon per sone, mens Global Standard får én pool per modell og versjon på tvers av alle regioner. Jeg synes det gir bedre fleksibilitet, men taket forsvinner ikke.

Trinnene er Free og Tier 1 til 6. Starttrinnet avhenger av bruksnivå og forholdet til Microsoft, som EA- eller MCA-E-avtale, og oppgradering styres av forbruk, relasjon og betalingshistorikk. Nivået slår ut i tallene: i Tier 1 er sonegrensen for gpt-5.6-sol 100 000 TPM, mot 250 000 for Global Standard. Det gjør Global til den fristende snarveien, og jeg liker å lese tabellen over grensene per nivå før arkitekturen tegnes. Kommandoen for å se trinnet ditt står i gjennomgangen av Foundry-modellbølgen.

Kvoteøkninger tas i innsendt rekkefølge, og kunder som bruker det de har fått aktivt, får prioritet. Andre kan få nei. Blir økningen godkjent, beholder abonnementet trinnet sitt og får tillegget lagt oppå. Det overrasker meg ikke at et abonnement uten aktivitet havner bakerst i køen.

Sjekk kapasitet før du lover go-live

Dokumentasjonen beskriver to Resource Manager-APIer. Usages API viser forbruk og grense per region, og Model Capacities API viser ledig kapasitet per sted og deployment-type for én modell. For å se tallene kreves rollen Cognitive Services Usages Reader på abonnementsnivå. Jeg pleier å kjøre begge før en leveransedato havner i prosjektplanen.

# Kvote og forbruk i Sweden Central, bare Data Zone-linjer
az cognitiveservices usage list --location swedencentral \
  --query "[?contains(name.value, 'DataZone')].{kvote:name.value, brukt:currentValue, grense:limit}" \
  --output table

# Ledig kapasitet for én modell, per sted og deployment-type
az rest --method get \
  --url "https://management.azure.com/subscriptions/<abonnement-id>/providers/Microsoft.CognitiveServices/modelCapacities?api-version=2024-10-01&modelFormat=OpenAI&modelName=<modell>&modelVersion=<versjon>" \
  --query "value[?properties.skuName=='DataZoneStandard'].{sted:location, ledig:properties.availableCapacity}" \
  --output table

Kvotenavnene bygger på formatet leverandør, deployment-type og modell, så filteret fanger alle sonelinjene. En grense på 0 betyr at du ikke har noe å bruke. Sjekk hver modell du skal ha, ikke bare chatmodellen. KSJ sto på 0 for embeddings i sonen, og jeg mener et RAG-oppsett står og faller på begge.

En 429-feil tilsier heller ikke alltid tom kvote. Microsoft skiller mellom kvote og midlertidig kapasitetspress, og mange tolker det siste som et kvoteproblem. Slik jeg ser det bør feilmeldingen leses før du ber om mer.

Slik leser du et avslag

Avslagsteksten KSJ fikk, handler om regional kapasitet hos Microsoft, ikke om oppsettet deres. Ifølge KSJ bekreftet en supportsak det samme: å døpe om deploymenten, bytte ressursgruppe eller endre portalinnstillinger hjelper ikke. Det realistiske er å deploye der kapasiteten finnes eller sende ny forespørsel senere, via skjemaet Microsoft peker til. Jeg foreslår å logge hver avslagstekst med tidspunkt, for ventetiden gjelder samme region og avgjør første nye forsøk.

Reserve uten å bryte residenskravet

KSJ løste det med en egen Azure OpenAI-ressurs i et annet abonnement som allerede hadde kapasitet i EU Data Zone, brukt av den grundigste svarmodusen. Selve kjøringen holdt seg i EU, men prisen er drift: to ressurser å vedlikeholde, med egne nøkler og hver sin kvotepool å følge med på. Jeg anbefaler å bygge for en slik løsning fra første dag, med endepunkt og autentisering i konfigurasjon per svarmodus. Bruk Entra ID i stedet for nøkler der du kan, så slipper du nøkkelrotasjon på tvers av ressurser. To abonnementer gir dessuten to budsjetter og to sett med tagger, og veikartet for kostnadsstyring gjelder her på samme måte.

{
  "svarmoduser": {
    "rask": {
      "endepunkter": [
        { "navn": "eu-primaer", "sku": "DataZoneStandard", "abonnement": "prod-1" }
      ]
    },
    "grundig": {
      "endepunkter": [
        { "navn": "eu-primaer", "sku": "DataZoneStandard", "abonnement": "prod-1" },
        { "navn": "eu-reserve", "sku": "DataZoneStandard", "abonnement": "prod-2" }
      ]
    }
  },
  "tillatteSku": ["DataZoneStandard"]
}

Reserven må ha samme residensnivå som hovedendepunktet. En reserve som lander på Global Standard fordi det finnes ledig kapasitet, bryter kravet i det stille. Etter min mening bør appen feile i stedet for å bytte deployment-type uten at noen har tatt den beslutningen.

Blokker Global Standard med Azure Policy

Residenskravet bør håndheves teknisk, ikke bare stå i et dokument. Microsoft har et eksempel på en policy som deaktiverer en bestemt deployment-SKU, med GlobalStandard som mål. Eksempelet inneholder bare if-delen, så deny-effekten under er lagt til av meg. Jeg vil anbefale å starte med enforcement-modus DoNotEnforce, så du ser hva som ville blitt blokkert før noe stopper.

{
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.CognitiveServices/accounts/deployments" },
      { "field": "Microsoft.CognitiveServices/accounts/deployments/sku.name", "equals": "GlobalStandard" }
    ]
  },
  "then": { "effect": "deny" }
}

az policy definition create --name deny-globalstandard \
  --display-name "Blokker GlobalStandard i Foundry" \
  --mode All --rules deny-globalstandard.json

az policy assignment create --name deny-globalstandard \
  --policy deny-globalstandard \
  --scope "/subscriptions/<abonnement-id>" \
  --enforcement-mode DoNotEnforce

Etter min mening stenger policyen omveien, men fyller ikke kvoten. Den hindrer bare at noen bytter til Global for å komme rundt problemet.

Min sjekkliste før go-live

Skriv residenskravet som «EU Data Boundary», og noter at Microsoft kan utvide sonen uten varsel
Kjør kapasitetssjekken for hver modell, også embeddings
Velg et abonnement med brukshistorikk til produksjon, eller regn med ventetid
Hold endepunkt, autentisering og tillatte SKU-er utenfor koden, per svarmodus
La reserveendepunkter bare peke til samme residensnivå
Hold personopplysninger borte fra ressurs- og deployment-navn. Microsoft regner navn og tekniske innstillinger som konfigurasjon, ikke kundedata
Bytt policyen fra DoNotEnforce til Default når rapporten er ren
Loggfør avslagstekst og tidspunkt for hver forespørsel om mer kvote

Jeg anbefaler å ta kapasitetssjekken i arkitekturfasen, før noen har lovet forretningen en leveranse. Residens kan du bestille på papiret, mens kapasitet er noe abonnementet enten har eller ikke har. Vil dere ha hjelp med kvoteplan eller et EU-only oppsett i Microsoft Foundry? Kontakt meg på kontakt@jas-azure.com.