ms-ai-architect/skills/ms-ai-engineering/references/azure-ai-services/ai-services-enterprise-architecture.md

# Azure AI Services - Enterprise Architecture Patterns
**Last updated:** 2026-05 | Verified: MCP 2026-05
**Status:** GA
**Category:** Azure AI Services (Foundry Tools)

---

## Introduksjon

Azure AI Services (tidligere Cognitive Services) krever robuste enterprise-arkitekturmønstre for å sikre høy tilgjengelighet, disaster recovery og effektiv skalering i produksjonsmiljøer. Dette dokumentet dekker arkitekturmønstre for multi-region deployment, load balancing, failover og infrastrukturdesign for AI-tjenester i Microsoft-stakken.

**Sentrale utfordringer:**
- Regional failover og business continuity
- Load balancing mellom flere Azure OpenAI-instanser
- Kostnadsoptimalisering vs. tilgjengelighet
- Network isolation og security perimeter
- Kvotestyring og throttling-håndtering

**Scope:** Dette dokumentet fokuserer på arkitekturmønstre for Azure OpenAI (del av Foundry Models, tidligere "OpenAI in Azure" — nå konsolidert under Foundry Tools), Azure AI Search, og støttetjenester som Azure API Management og Azure Front Door. Mønstrene gjelder både Foundry-baserte løsninger og standalone AI Services.

---

## Kjernekomponenter

### 1. Azure AI Services (Foundry Models)

**Deployment-typer:**
| Type | Beskrivelse | Bruksområde |
|------|-------------|-------------|
| **Global Standard** | Automatisk routing til regioner med kapasitet | Høyeste resilience, ingen data residency-krav |
| **Data Zone Standard** | Processing innenfor geografisk sone (US/EU) | Data residency-krav, god resilience |
| **Regional Standard** | Én spesifikk region | Lav latency, manuell failover |
| **Provisioned (PTU)** | Dedikert kapasitet, SLA på latency | Mission-critical workloads, predictable load |

**Multi-region strategi:**
- Minimum 2 regioner for produksjon (active-active eller active-passive)
- Data Zone deployments deler kapasitetspool på tvers av regioner i samme sone
- Separat subscription per region unngår kvote-konflikter
- Full quota allocation per endpoint gir høyest throughput

### 2. Generative AI Gateway (Azure API Management)

**Funksjonalitet:**
- **Load balancing:** Round-robin, weighted, priority-based, session-aware
- **Circuit breaker:** Automatisk deteksjon av 429-errors, dynamisk trip duration basert på `Retry-After`-header
- **Spillover:** Automatic failover til sekundære backends ved throttling
- **Managed identity:** Eliminerer API key management

**Backend pool configuration:**
- Inntil 30 backends per pool
- Priority groups: PTU som Priority 1, standard deployments som Priority 2+
- Session affinity for conversational agents
- Health probes og automatic retry uten client-side delay

**VIKTIG:** APIM circuit breaker for Azure OpenAI må håndtere `429 Too Many Requests` og respektere `Retry-After`-headeren (kan være opptil 24 timer).

### 3. Azure AI Search

**Zone redundancy:**
- Standard tier eller høyere + minimum 3 replicas
- Automatisk distribusjon på tvers av availability zones
- Ingen built-in disaster recovery — krever manuell gjenoppbygging eller support-kontakt
- Semantic ranker og advanced features øker kostnad

**Multi-region:**
- Separat service per region (ingen native multi-region replication)
- Geo-replication strategy må implementeres selv
- Index rebuilding fra separate source of truth ved data loss

### 4. Global Load Balancers

**Azure Front Door:**
- Global HTTP(S) load balancing og failover
- Latency-based routing
- Web Application Firewall (WAF) integration
- Health probes på application-nivå

**Azure Traffic Manager:**
- DNS-basert global routing
- Performance, priority, weighted, geographic routing
- Health endpoint monitoring
- Brukes ofte foran search-enabled clients (ikke direkte til AI Search)

---

## Arkitekturmønstre

### Mønster 1: Active-Active med Priority-Based Load Balancing

**Scenario:** Enterprise med PTU-deployment + standard deployments som fallback.

```
┌─────────────────────────────────────────────────────────┐
│ Azure API Management (Multi-region eller Frontend)      │
│ - Backend pool med circuit breaker                      │
│ - Session affinity for chat                             │
└─────────┬───────────────────────────────────────────────┘
          │
    ┌─────┴─────┐
    │  Priority │
    │  Routing  │
    └─────┬─────┘
          │
    ┌─────┴──────────────────────────────────────┐
    │                                             │
┌───▼─────────────────┐              ┌───────────▼──────────┐
│ Priority 1: PTU     │              │ Priority 2: Standard │
│ Region A            │              │ Multi-region (US/EU) │
│ - Dedicated capacity│              │ - Data Zone          │
│ - Fixed cost        │              │ - Pay-per-token      │
│ - SLA latency       │              │ - Spillover          │
└─────────────────────┘              └──────────────────────┘
```

**Fordeler:**
- Maksimal utnyttelse av PTU (fast kostnad)
- Automatisk spillover til standard ved PTU-overload
- Ingen client-side retry logic nødvendig

**Ulemper:**
- Kompleks konfigurasjon
- APIM koster ekstra
- Ikke transparent failover ved regional outage (krever DNS/Front Door)

---

### Mønster 2: Multi-Region med Azure Front Door

**Scenario:** Global applikasjon med latency-sensitive workloads.

```
                    ┌──────────────────┐
                    │ Azure Front Door │
                    │ + WAF            │
                    └────────┬─────────┘
                             │
                ┌────────────┴────────────┐
                │                         │
        ┌───────▼────────┐      ┌────────▼───────┐
        │ Region 1 (US)  │      │ Region 2 (EU)  │
        │ - APIM         │      │ - APIM         │
        │ - OpenAI       │      │ - OpenAI       │
        │ - AI Search    │      │ - AI Search    │
        │ - Cosmos DB    │      │ - Cosmos DB    │
        └────────────────┘      └────────────────┘
```

**Komponenter:**
- **Front Door:** Global routing, instant failover, health probes
- **Per-region:** Komplett stack (APIM, AI Services, data)
- **Data replication:** Cosmos DB global distribution, Storage GRS/GZRS

**Fordeler:**
- Minimal latency for globale brukere
- Transparent failover ved regional outage
- Høy SLA (multi-region SLA composite)

**Ulemper:**
- Høy kostnad (dobbel infrastruktur minimum)
- Data consistency-utfordringer
- Kompleks deployment og drift

---

### Mønster 3: Hot/Warm med Data Zone Deployments

**Scenario:** Compliance-krav (data residency i EU/US) med cost optimization.

```
Primary Region (Hot)          Secondary Region (Warm)
┌──────────────────┐         ┌──────────────────┐
│ Full capacity    │         │ Reduced capacity │
│ - OpenAI (PTU)   │         │ - OpenAI (Std)   │
│ - AI Search (3x) │ ──────> │ - AI Search (1x) │
│ - Cosmos DB      │ replica │ - Cosmos DB      │
│ - Active traffic │         │ - Standby        │
└──────────────────┘         └──────────────────┘
        │                              ▲
        └──────────────────────────────┘
           Manual DNS failover
```

**Failover-strategi:**
1. Detekter outage via health monitoring
2. Scale up secondary region capacity
3. DNS cutover (eller APIM backend pool update)
4. Validate service restoration

**RTO/RPO:**
- RTO: 5-15 minutter (avhenger av scaling speed)
- RPO: Nær null (Cosmos DB continuous backup, AI Search rebuild required)

**Fordeler:**
- 50-70% kostnadssparing vs. full hot/hot
- Data residency compliance
- Raskere failover enn cold standby

**Ulemper:**
- Ikke transparent failover
- Capacity scaling under outage er risikabelt
- Manual intervention required

---

### Mønster 4: Foundry Agent Service med Standard Setup

**Scenario:** Enterprise chat application med network isolation.

```
┌────────────────────────────────────────────────────┐
│ Virtual Network                                     │
│ ┌────────────────────────────────────────────────┐ │
│ │ App Service (Web UI)                           │ │
│ │ - VNet integration                             │ │
│ │ - Managed identity                             │ │
│ └─────────┬──────────────────────────────────────┘ │
│           │ Private Endpoint                        │
│ ┌─────────▼──────────────────────────────────────┐ │
│ │ Foundry Agent Service                          │ │
│ │ - Agent runtime                                │ │
│ │ - Private endpoint access only                 │ │
│ └─────────┬──────────────────────────────────────┘ │
│           │ Delegated subnet                        │
│ ┌─────────▼──────────────────────────────────────┐ │
│ │ Private Endpoints:                             │ │
│ │ - Azure OpenAI                                 │ │
│ │ - AI Search                                    │ │
│ │ - Cosmos DB (conversation state)               │ │
│ │ - Storage (file uploads)                       │ │
│ └────────────────────────────────────────────────┘ │
│                      │                              │
│           ┌──────────▼─────────┐                    │
│           │ Azure Firewall     │                    │
│           │ - FQDN filtering   │                    │
│           │ - Egress control   │                    │
│           └────────────────────┘                    │
└────────────────────────────────────────────────────┘
```

**Zone redundancy:**
- **Cosmos DB:** Zone-redundant (ZRS) eller global distribution
- **Storage:** ZRS eller GZRS
- **AI Search:** 3+ replicas med automatic zone distribution
- **App Service:** Zone-redundant (minimum 3 instances)

**Disaster recovery:**
- Cosmos DB: Continuous backup (7-day PITR)
- AI Search: Ingen native backup — rebuild fra source of truth
- Storage: Customer-managed failover for geo-redundant accounts
- Agent definitions: Infrastructure as Code (deploy from source control)

**Fordeler:**
- Enterprise-grade security (zero trust network)
- Full audit trail via NSG flow logs og Firewall logs
- Managed identity eliminerer secrets
- Foundry Agent Service håndterer orchestration og state (Microsoft Agent Framework koordinerer multi-agent orkestrasjon). Verified (MCP 2026-04).

**Ulemper:**
- Høyere kompleksitet
- Ikke multi-region (krever separate deployments)
- Foundry portal krever jump box eller VPN-tilgang

---

## Beslutningsveiledning

### 1. Velge Deployment Type

| Krav | Anbefaling |
|------|------------|
| Høyeste resilience, ingen data residency-krav | **Global Standard** |
| EU/US data residency | **Data Zone Standard** |
| Lavest latency, eksisterende regional infra | **Regional Standard** (+ manuell multi-region) |
| Predictable latency SLA, mission-critical | **Provisioned (PTU)** |
| Kostnadsoptimalisering, variabel load | **Standard** med APIM spillover til PTU |

### 2. Velge Load Balancing Strategy

| Scenario | Løsning |
|----------|---------|
| Single region, multiple Azure OpenAI instances | **Azure API Management** (backend pool + circuit breaker) |
| Multi-region global routing | **Azure Front Door** + regional APIM |
| Latency-sensitive, DNS-based | **Traffic Manager** + health probes |
| DIY, containerized | **YARP** (C# reverse proxy) på Azure Container Apps |

### 3. Velge RTO/RPO Strategi

| RTO/RPO Mål | Mønster | Relative Cost |
|-------------|---------|---------------|
| RTO < 1 min, RPO = 0 | Active-active (hot/hot) | 2.0x |
| RTO < 15 min, RPO < 5 min | Active-warm | 1.4x |
| RTO < 1 hour, RPO < 1 hour | Active-cold | 1.1x |

**Konfidensgradering:** 🟢 **Høy** — Basert på Microsoft Learn offisiell dokumentasjon (2026-02).

---

## Integrasjon med Microsoft-stakken

### Azure AI Foundry Integration

**Foundry Agent Service Dependencies (Standard Setup):**
- **Cosmos DB for NoSQL:** Agent state og conversation history (krever zone redundancy)
- **Azure Storage:** File uploads og static files (krever ZRS/GZRS)
- **Azure AI Search:** Chunked index av filer (krever 3+ replicas)

**Multi-project isolation:**
- Separate Foundry project per agent med distinct access patterns
- Project-level connections (ikke account-level) for least privilege
- User-assigned managed identity for project identity (survival ved accidental deletion)

**Disaster recovery:**
- Agent definitions som Infrastructure as Code
- Continuous backup på Cosmos DB (7-day PITR)
- Transactional consistency: Restore alle dependencies til samme point-in-time

### Power Platform Integration

**Copilot Studio:**
- Uses Azure OpenAI via Foundry Models
- Separate per-environment deployments anbefales
- Gateway-pattern mulig via custom connectors

**Power Automate:**
- AI Builder actions bruker dedikerte AI Services
- Premium connectors kan kalle APIM-fronted Azure OpenAI
- Regional availability varierer (sjekk [Products by Region](https://azure.microsoft.com/global-infrastructure/services/))

### M365 Copilot

**Ikke direkte integrasjon med custom Azure OpenAI:**
- M365 Copilot bruker Microsoft-managed AI infrastructure
- Grounding via Microsoft Graph, SharePoint, OneDrive
- Copilot Studio kan utvide med custom skills som kaller Azure OpenAI via gateway

---

## Offentlig sektor (Norge)

### Compliance og Data Residency

**Azure OpenAI i Norge:**
- Ingen Azure OpenAI-region i Norge per 2026-02
- **Nærmeste regioner:** Sweden Central, West Europe
- **Data residency:** Bruk **Data Zone EU** for GDPR-compliance
- **Schrems II:** Data Zone deployments prosesserer data innenfor EU

**Network Isolation:**
- Private endpoints + Azure Firewall (FQDN-filtering)
- NSG per subnet med deny-all default
- Jump box + Azure Bastion for admin-tilgang
- ExpressRoute for hybrid connectivity (ikke required for cloud-only workloads)

### Anbefalte Patterns for Norsk Offentlig Sektor

**Konfidensialitet Normal (N):**
- Data Zone EU Standard deployments
- Hot/warm multi-region (West Europe + Sweden Central)
- Azure API Management for load balancing
- Zone-redundant støttetjenester

**Konfidensialitet Høy (H):**
- Som Normal + Private endpoints på alt
- Azure Firewall med strict egress rules
- Customer-managed keys (CMK) for encryption
- Audit logging til Log Analytics Workspace (Norge-region hvis tilgjengelig, ellers EU)

**Konfidensialitet Særlig Høy (SH):**
- Vurder on-premises AI Services containers (begrenset funksjonalitet)
- Eller: Data Zone EU + customer-managed VNet med zero internet egress
- Dedikert subscription per sensitivity zone
- Enhanced monitoring og Security Operations Center (SOC) integration

**Kostnadsoversikt (estimat, NOK per måned):**

| Komponent | Normal (N) | Høy (H) | Særlig Høy (SH) |
|-----------|-----------|---------|-----------------|
| Azure OpenAI (50K tokens/dag) | ~1 500 | ~3 000 (2x regions) | ~6 000 (PTU dedicated) |
| Azure API Management (Standard) | ~6 000 | ~6 000 | ~12 000 (2x regions) |
| AI Search (Standard, 3 replicas) | ~9 000 | ~18 000 (2x regions) | ~18 000 |
| Cosmos DB (zone-redundant) | ~3 000 | ~6 000 (global) | ~6 000 |
| **Total (ca.)** | **~19 500** | **~33 000** | **~42 000** |

*Disclaimer: Priser er estimater basert på moderate workloads. Faktiske kostnader avhenger av trafikk, data volume og konkrete konfigurasjon.*

---

## Kostnad og lisensiering

### Azure OpenAI Pricing Model

**Standard Deployments (Pay-per-token):**
- **Input tokens:** ~0.003 USD per 1K tokens (GPT-4o)
- **Output tokens:** ~0.006 USD per 1K tokens (GPT-4o)
- **Image input:** Per image (varierer med resolution)
- **Ingen minimum commitment**

**Provisioned (PTU):**
- **Fixed monthly cost:** ~2 500 USD per 100 PTU
- **Inkluderer:** Dedikert kapasitet, latency SLA, priority access
- **Optimalt for:** >10M tokens/måned med forutsigbar load

**Cost Optimization Strategies:**
- **Prompt optimization:** Reducer input tokens (concise prompts, efficient context)
- **Model selection:** Bruk GPT-4o-mini for enklere tasks (10x billigere)
- **Caching:** (Planlagt feature) Reduserer repeterende context-tokens
- **APIM rate limiting:** Forhindre abuse og kostnadsoverskridelse
- **Spillover strategy:** PTU for baseline, standard for peaks

### Azure API Management Pricing

| Tier | Kostnad (ca. NOK/måned) | Max requests | Features |
|------|------------------------|--------------|----------|
| Developer | ~500 | 1M calls | Ingen SLA, dev/test |
| Basic | ~1 500 | 1M calls | SLA, 1 unit max |
| Standard | ~6 000 | 10M calls | Multi-region, 4 units |
| Premium | ~30 000+ | Unlimited | Multi-region, VNet, 10+ units |

**For AI Gateway:** Standard tier minimum (circuit breaker ikke i Consumption tier).

### Azure AI Search Pricing

**Standard Tier (anbefalt for prod):**
- **S1:** ~3 000 NOK/måned per search unit
- **Zone redundancy:** Requires 3+ replicas = ~9 000 NOK/måned minimum
- **Semantic ranker:** +~1 000 NOK/månd per search unit

### Total Cost of Ownership (TCO) Example

**Scenario:** Enterprise chat application, 100 users, 50 queries/dag per user.

**Forutsetninger:**
- 5 000 queries/dag total
- Average 1 000 input tokens + 500 output tokens per query
- 2 regioner (active-warm)

**Månedlig kostnad (NOK):**
```
Azure OpenAI: ~15 000 (2.5M in + 1.25M out tokens)
APIM Standard: ~6 000 (single region)
AI Search S1 (3 replicas): ~9 000
Cosmos DB (zone-redundant): ~3 000
Storage ZRS: ~200
Front Door: ~1 500
──────────────────────────────────────────────────────
TOTAL: ~34 700 NOK/måned
```

**Med PTU optimization (100 PTU i primary region):**
```
Azure OpenAI PTU: ~25 000 (fixed)
Azure OpenAI Standard (spillover): ~3 000
[Andre komponenter samme]
──────────────────────────────────────────────────────
TOTAL: ~46 700 NOK/måned (høyere cost, men forutsigbar)
```

**Konfidensgradering:** 🟡 **Medium** — Prisene er estimater basert på publiserte prislister (2026-02). Faktiske kostnader avhenger av detaljert bruksmønster.

---

## For arkitekten (Cosmo)

### Når bruke hvilke mønstre

**Velg Active-Active (Hot/Hot) hvis:**
- RTO < 1 minutt er strengt krav
- Global user base med latency-følsomhet
- Budsjett tillater 2x infrastructure cost
- Datakonsistens kan håndteres (eventual consistency OK)

**Velg Active-Warm hvis:**
- RTO < 15 minutter er akseptabelt
- Primært regional user base
- Kostnadsoptimalisering er prioritet
- Manual failover-prosess er akseptabel

**Velg Regional + APIM hvis:**
- Single-region deployment er OK
- Throttling-håndtering viktigere enn regional failover
- Lavere kostnad og kompleksitet prioriteres

### Kritiske spørsmål å stille kunden

1. **RTO/RPO requirements:** Hva er maksimal akseptabel downtime? Data loss?
2. **Data residency:** Er det juridiske krav til hvor data prosesseres? (GDPR, Schrems II)
3. **Budget:** Hva er månedlig budsjett for AI infrastructure? (Påvirker hot/warm/cold valg)
4. **User distribution:** Global eller regional? (Påvirker multi-region strategi)
5. **Load pattern:** Forutsigbar eller spiky? (PTU vs. standard)
6. **Security posture:** Network isolation required? (Påvirker VNet/private endpoint design)
7. **Existing footprint:** Azure landing zone existing? ExpressRoute? (Påvirker integration)

### Røde flagg å unngå

❌ **Single region uten throttling-håndtering** — Garantert 429-errors under peak load
❌ **Shared APIM backend pool på tvers av environments** — Dev throttling påvirker prod
❌ **Account-level Foundry connections** — Overprivileged access på tvers av prosjekter
❌ **Ingen disaster recovery plan for AI Search** — Index-tap er ikke-recoverable uten backup strategy
❌ **PTU-deployment uten fallback** — Fast cost uten elasticity ved overload
❌ **Client-side retry uten exponential backoff** — Amplified load under throttling
❌ **Colocating workload data i Foundry Agent Service dependencies** — Reliability og security risk

### Anbefalte Deployment Sequence

1. **Fase 1 - Single Region MVP:**
   - Regional Azure OpenAI (Standard)
   - APIM Basic tier (gateway pattern proof)
   - AI Search Standard (1 replica)
   - Cost: ~10K NOK/måned

2. **Fase 2 - Production Hardening:**
   - Upgrade til APIM Standard (circuit breaker)
   - AI Search 3 replicas (zone redundancy)
   - Add secondary region (warm standby)
   - Cost: ~35K NOK/måned

3. **Fase 3 - Enterprise Scale:**
   - Azure Front Door (global routing)
   - PTU deployment i primary region
   - Full hot/hot multi-region
   - Cost: ~70K+ NOK/måned

### Monitoring og Alerting

**Kritiske metrics:**
- **Azure OpenAI:** `TotalTokens`, `GeneratedTokens`, `HTTP 429 count`, `Latency P95`
- **APIM:** `Backend response time`, `Failed requests`, `Circuit breaker trips`
- **AI Search:** `Search latency`, `Throttled requests`, `Query volume`
- **Cosmos DB:** `Request units consumed`, `Availability`, `Latency P99`

**Alert thresholds (forslag):**
- HTTP 429 count > 1% av requests → Øk quota eller add fallback region
- APIM backend latency P95 > 5s → Investigate backend health
- AI Search throttled requests > 0 → Scale up replicas/partitions
- Cosmos DB RU utilization > 80% → Scale up RU/s eller enable autoscale

**Application Insights integration:**
- Foundry Agent Service sender automatisk metrics til linked App Insights
- Custom telemetry via SDK for client-side latency tracking
- Correlation ID på tvers av alle komponenter for distributed tracing

---

## Kilder og verifisering

**Microsoft Learn Documentation (offisiell, 2026-02):**
1. [AI Ready - Cloud Adoption Framework](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/ready)
2. [BCDR for Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/business-continuity-disaster-recovery)
3. [Baseline Foundry Chat Architecture (Foundry Agent Service + Microsoft Agent Framework)](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-microsoft-foundry-chat) — Verified (MCP 2026-04)
4. [Azure API Management - AI Gateway Capabilities](https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities)
5. [Reliability in Azure AI Search](https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search)
6. [Multi-Backend Gateway Guide](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend) — Verified MCP 2026-04: Dokumentet bekrefter fire gateway-topologier: (1) multiple model deployments i single instance, (2) multiple instances same region/single subscription, (3) multiple instances same region/multiple subscriptions (eksplisitt som egen topologi), (4) multiple instances multi-region. Tagger eksplisitt "Foundry Tools" og "Azure OpenAI in Foundry Models". Anbefaler sterkt credential termination og reestablishment ved gateway fremfor pass-through client credentials. Gateway muliggjør client-based usage tracking for chargeback-modeller. Verified (MCP 2026-04)
7. [Load Balancing Options - Azure Architecture](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview)

**GitHub Samples (Microsoft-verified):**
8. [Smart Load Balancing for Azure OpenAI (APIM)](https://github.com/Azure-Samples/openai-apim-lb)
9. [Smart Load Balancing (Container Apps/YARP)](https://github.com/Azure-Samples/openai-aca-lb)
10. [Foundry Baseline Reference Implementation](https://github.com/Azure-Samples/microsoft-foundry-baseline)

**Verifikasjon:**
- ✅ Alle arkitekturdiagrammer basert på Microsoft offisiell dokumentasjon
- ✅ Deployment-typer (Global/Data Zone/Regional/PTU) verifisert mot [Deployment Types](https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/concepts/deployment-types)
- ✅ APIM circuit breaker pattern bekreftet i [Backends Documentation](https://learn.microsoft.com/en-us/azure/api-management/backends)
- ✅ Zone redundancy requirements verifisert mot [Availability Zones Overview](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)

**Konfidensgradering - Samlet:** 🟢 **Høy** — Arkitekturmønstre og teknisk implementasjon er basert på Microsoft offisiell dokumentasjon (sist oppdatert april 2026). Verified (MCP 2026-04). Kostestimater er indikative og bør verifiseres mot Azure Pricing Calculator for spesifikke konfigurasjoner.