ktg-plugin-marketplace/plugins/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-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)

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
2. BCDR for Azure OpenAI
3. Baseline Foundry Chat Architecture (Foundry Agent Service + Microsoft Agent Framework) — Verified (MCP 2026-04)
4. Azure API Management - AI Gateway Capabilities
5. Reliability in Azure AI Search
6. Multi-Backend Gateway Guide — 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

GitHub Samples (Microsoft-verified): 8. Smart Load Balancing for Azure OpenAI (APIM) 9. Smart Load Balancing (Container Apps/YARP) 10. Foundry Baseline Reference Implementation

Verifikasjon:

• ✅ Alle arkitekturdiagrammer basert på Microsoft offisiell dokumentasjon
• ✅ Deployment-typer (Global/Data Zone/Regional/PTU) verifisert mot Deployment Types
• ✅ APIM circuit breaker pattern bekreftet i Backends Documentation
• ✅ Zone redundancy requirements verifisert mot 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.