# Azure AI Services - Enterprise Architecture Patterns **Last updated:** 2026-04 | Verified: MCP 2026-04 **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.