Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
428 lines
18 KiB
Markdown
428 lines
18 KiB
Markdown
# Regional Deployment for Latency Reduction
|
|
|
|
**Last updated:** 2026-06-19
|
|
**Status:** GA
|
|
**Category:** Performance & Scalability
|
|
**Type:** reference
|
|
**Source:** https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types
|
|
|
|
---
|
|
|
|
## Innhold
|
|
|
|
- [Introduksjon](#introduksjon)
|
|
- [Kjernekomponenter](#kjernekomponenter)
|
|
- [Region Selection Criteria](#region-selection-criteria)
|
|
- [Traffic Routing Strategies](#traffic-routing-strategies)
|
|
- [Cross-Region Redundancy](#cross-region-redundancy)
|
|
- [Data Residency Requirements](#data-residency-requirements)
|
|
- [Azure Front Door — oppdatert (2026-06-19)](#azure-front-door--oppdatert-2026-06-19)
|
|
- [Gateway Multi-Backend — 4 topologier (oppdatert 2026-06-19)](#gateway-multi-backend--4-topologier-oppdatert-2026-06-19)
|
|
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
|
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
|
- [Referanser](#referanser)
|
|
- [For arkitekten](#for-arkitekten)
|
|
|
|
## 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
|
|
|
|
```python
|
|
# 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
|
|
|
|
```xml
|
|
<!-- 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
|
|
|
|
```bash
|
|
# 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
|
|
|
|
```python
|
|
# 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
|
|
|
|
```bash
|
|
# 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
|
|
|
|
```xml
|
|
<!-- 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](https://learn.microsoft.com/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend) — Multi-region patterns (Azure OpenAI i Foundry Models) — Verified (MCP 2026-06-19)
|
|
- [Azure Front Door](https://learn.microsoft.com/azure/frontdoor/front-door-overview) — Global load balancing
|
|
- [APIM multi-region deployment](https://learn.microsoft.com/azure/api-management/api-management-howto-deploy-multi-region) — Regional gateway
|
|
- [Azure OpenAI deployment types](https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types) — Global vs Regional
|
|
- [AI Ready — Establish AI reliability](https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/ready) — Multi-region best practices
|
|
|
|
## For arkitekten
|
|
|
|
- **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.
|