KB-currency refresh (medium priority, 2026-06-19) via /architect:kb-update. 74 medium-prioritets filer re-verifisert mot Microsoft Learn (MCP) — delegert til 15 parallelle Opus-subagenter (3 bølger) gruppert etter delt kilde, med disjunkte fil-sett. Verifisert i hovedkontekst (scope-sjekk + diff-review av de faktatunge gruppene + tester). Hovedendringer (faktuelle korreksjoner + currency): - Azure AI Search semantic ranker: TILGJENGELIG PÅ ALLE TIERS (også Free/Basic m/ gratis månedlig kvote) — gammel KB sa feilaktig "kun S1+". Korrigert i tier-tabell, anti-patterns og beslutningstabell (azure-ai-search-setup). - APIM score-threshold = DISTANSE (lavere = strengere): tuning-tabellen i rag-caching-optimization hadde retningen baklengs — invertert til korrekt. - Agentic retrieval GA/preview-nyanse presisert (hovedkontekst-korreksjon mot agentic-retrieval-how-to-migrate): GA via REST 2026-04-01 returnerer EKSTRAKTIV grounding (references + activity), IKKE syntetiserte svar. Answer synthesis, ikke-minimal reasoning effort (LLM query planning) og multi-turn messages forblir preview (2026-05-01-preview). Subagent hadde overforenklet til "hele kjernepipelinen GA"; rettet i agentic-rag-patterns + citation-tracking. - Copilot Studio modell-tabeller (platforms/copilot-studio): fjernet Claude Opus 4.5 + GPT-5.2 (borte fra kilde), lagt til Claude Sonnet 4.6/Opus 4.6 (GA), Opus 4.7 + Mistral Medium 3.5 (experimental); GPT-5 Reasoning/Auto = preview; A2A GA (apr 2026). - Computer Use (CUA): Copilot Studio GA 2026-05-07; 4 modeller m/ tier/status (OpenAI CUA + Sonnet 4.5 GA, Sonnet 4.6 + Opus 4.6 experimental); 5 credits/ steg standard, 15 premium; US-only region-krav FJERNET i GA-dok; Cloud PC pool + Hosted browser + bring-your-own-machine. - Azure AI Search REST API-versjoner bumpet: 2025-09-01 -> 2026-04-01 (stabil), 2025-11-01-preview -> 2026-05-01-preview (hybrid-search, rag-security-rbac, chunking). - Power Automate-integrasjon: trigger "Run a flow from Copilot" -> "When an agent calls the flow"; App Service innebygd MCP (preview) lagt til. - M365 Copilot-manifest v1.26 -> v1.28 (GA, mai) / v1.29 dokumentert (juni); "Tenant graph grounding" -> "Work IQ". - Speech fast transcription 2t/300MB -> 5t/500MB; multilingual 14 -> 15 locales (+ pt-BR). Content Understanding reasoning preview -> GA (v1.0, 2025-11-01). - Security Copilot E5 -> E5+E7. Død Databricks-URL ci-cd/best-practices -> ci-cd/flows. Prompt Flow retirement (2027-04-20 -> MAF) notert der den presenteres som go-forward. Gateway-topologi-tabell-feil rettet. - Alle 74 Last updated -> 2026-06-19. Discovery ikke kjørt (historisk kun Databricks-støy) -> 389-telling uendret, ingen resync. validate 239 PASS, kb-integrity 115/115 (262 orphan-warnings uendret), gitleaks clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01REiKFhP4w6xGXXqWKpPCJJ
17 KiB
Regional Deployment for Latency Reduction
Last updated: 2026-06-19 | Verified: MCP 2026-06-19 Status: GA Category: Performance & Scalability
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.