ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/ai-foundry-disaster-recovery-planning.md

AI Foundry Disaster Recovery Planning

Last updated: 2026-02 Status: GA Category: Business Continuity & Disaster Recovery

---

Introduksjon

Azure AI Foundry (tidligere Azure AI Studio / Azure Machine Learning) er Microsofts sentrale plattform for utvikling, evaluering og deployering av AI-modeller og agenter. Plattformen tilbyr imidlertid ikke automatisk failover eller disaster recovery ut av boksen -- dette er eksplisitt dokumentert av Microsoft. Det betyr at organisasjoner i norsk offentlig sektor som bygger forretningskritiske AI-loesninger pa AI Foundry, ma planlegge og implementere sin egen DR-strategi.

Disaster recovery for AI Foundry-prosjekter er mer kompleks enn for tradisjonelle webapplikasjoner. Et AI-prosjekt bestar av mange sammenkoblede komponenter: modelldeployeringer, datasett, pipeline-konfigurasjoner, agentdefinisjoner, tilkoblinger til eksterne tjenester, og tilhoerende infrastruktur som Azure Cosmos DB, Azure AI Search og Azure Storage. Tap av en enkelt komponent kan gjore hele AI-loesningen uoperativ. Saerlig for Foundry Agent Service er tilstandsdata (samtalehistorikk, agent-definisjoner, trad-kontekst) fordelt pa tvers av flere lagringstjenester, og det finnes per i dag ingen innebygd en-klikks eksport/import-funksjon for komplett gjenoppretting.

Denne referansen dekker prosjektdata-backup og replikering, modellversjonskontroll og gjenoppretting, configuration as code for reproduserbarhet, RTO/RPO-definisjoner for AI-prosjekter, og testing og validering av DR-prosedyrer. Alt er forankret i Microsofts offisielle veiledning for high availability og disaster recovery for AI Foundry.

Prosjektdata-backup og replikering

Komponentoversikt for AI Foundry-prosjekter

Komponent	Lagringssted	Backup-ansvar	Replikeringsmetode
Prosjektkonfigurasjon	AI Foundry control plane	Kunde (IaC)	Bicep/Terraform redeploy
Modelldeployeringer	Azure OpenAI / AI Foundry	Kunde (IaC)	Redeploy fra kildekontroll
Agentdefinisjoner	Cosmos DB (Standard mode)	Kunde	Cosmos DB continuous backup
Samtalehistorikk (traader)	Cosmos DB (enterprise_memory)	Kunde	Cosmos DB PITR
Kunnskapsfiler (agent)	Azure Storage	Kunde	GRS/GZRS replikering
Soekeindekser (agent)	Azure AI Search	Kunde	Manuell gjenskapning
Datasett og artefakter	Azure Storage (prosjekt)	Kunde	GRS/GZRS replikering
Notebook-filer og kode	Azure Storage	Kunde	Git + Azure Storage
Tilkoblinger og secrets	Azure Key Vault	Microsoft	Auto-failover til sekundaer region
Container images	Azure Container Registry	Microsoft*	Geo-replikering (konfigurer)
Application Insights	Log Analytics workspace	Kunde	Opprett i begge regioner

*Azure Container Registry ma konfigureres for geo-replikering av kunden, men Microsoft haandterer selve replikeringsmekanismen.

Ressurskonfigurering for gjenoppretting

Microsoft anbefaler foelgende konfigurasjon foer en hendelse inntreffer:

+------------------------------------------------------------------+
|  Ressurs                    | Anbefalt konfigurasjon             |
+------------------------------------------------------------------+
|  Foundry account            | Purview-integrasjon for compliance |
|  Foundry project            | User-assigned managed identity     |
|  Agent Service              | Standard deployment mode           |
|  Cosmos DB                  | Continuous backup med PITR         |
|                             | Service-managed failover           |
|                             | Read replication til failover-reg. |
|  AI Search                  | Unikt navn (unnga kollisjon)       |
|  Storage account            | GZRS (geo-zone-redundant)          |
+------------------------------------------------------------------+

Cosmos DB-konfigurasjon for agentdata

Cosmos DB er kritisk for Foundry Agent Service da all agent-tilstand lagres her:

# Aktiver continuous backup med 30-dagers PITR
az cosmosdb create \
  --name ddt-ai-cosmos-prod \
  --resource-group rg-ai-foundry-prod \
  --locations regionName="norwayeast" failoverPriority=0 \
  --locations regionName="swedencentral" failoverPriority=1 \
  --backup-policy-type Continuous \
  --continuous-tier Continuous30Days \
  --enable-automatic-failover true \
  --default-consistency-level Session

Viktig: Aktiver Service-Managed Failover slik at Cosmos DB automatisk kan bytte skriveregion fra primaerregion til sekundaerregion ved et langvarig regionalt utfall.

Azure Storage-konfigurasjon

# Opprett GZRS storage account for prosjektdata
az storage account create \
  --name svvaiprodstorage \
  --resource-group rg-ai-foundry-prod \
  --location norwayeast \
  --sku Standard_GZRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

Redundanstype	Beskrivelse	Anbefaling
LRS	3 kopier i en region	Kun for utvikling
ZRS	3 kopier pa tvers av soner	Produksjon uten DR-krav
GRS	LRS + asynkron kopi til sekundaer region	Standard DR
GZRS	ZRS + asynkron kopi til sekundaer region	Anbefalt for produksjon
RA-GZRS	GZRS + lesetilgang til sekundaer region	Hoeyest tilgjengelighet

Modellversjonskontroll og gjenoppretting

Versjonskontroll-strategi

AI-modeller gjennomgar kontinuerlig endring -- nye versjoner, fine-tuning, evaluering og deployering. En robust DR-plan krever sporbarhet og reproduserbarhet for alle modellversjoner.

Git Repository (kildekontroll)
  |
  +-- /models/
  |     +-- model-config.yaml        # Modellkonfigurasjon
  |     +-- deployment-params.json   # Deployment-parametere
  |     +-- evaluation-results/      # Evalueringsresultater per versjon
  |
  +-- /agents/
  |     +-- agent-definitions/       # JSON-definisjoner for agenter
  |     +-- knowledge-sources/       # Referanser til kunnskapsfiler
  |     +-- tool-bindings/           # Tool-konfigurasjoner
  |
  +-- /infrastructure/
  |     +-- bicep/                   # IaC for alle ressurser
  |     +-- pipelines/               # CI/CD pipeline-definisjoner
  |
  +-- /prompts/
        +-- system-prompts/          # System-prompter per agent/modell
        +-- evaluation-datasets/     # Testdata for evaluering

Modellregistrering og sporing

# model-config.yaml -- Eksempel
model:
  name: gpt-4o
  version: "2024-11-20"
  deployment_type: data_zone_standard
  regions:
    primary: norwayeast
    secondary: swedencentral
  quota:
    primary_tpm: 120000
    secondary_tpm: 120000
  fine_tuning:
    enabled: false
    base_model: null
    training_data: null
  evaluation:
    last_evaluated: "2026-01-15"
    accuracy_score: 0.94
    dataset: "eval-dataset-v3"

Fine-tuned modeller

For fine-tuned modeller er det spesielt viktig med backup:

Artefakt	Lagringssted	Backup-metode
Treningsdata	Azure Storage	GZRS + versjonering
Modellvekter	AI Foundry model registry	Eksporter + lagre i Storage
Hyperparametere	Git (kildekontroll)	Standard Git-backup
Evalueringsresultater	AI Foundry + Git	Eksporter til Git
Deployment-konfig	Git (Bicep/Terraform)	Standard Git-backup

Merk: Global training (Public Preview) tilbyr rimeligere fine-tuning, men gir ikke datasuverenitet. For norsk offentlig sektor med strenge krav, bruk regional training i Norway East eller Sweden Central.

Configuration as Code for reproduserbarhet

Infrastruktur som kode (IaC)

Microsoft anbefaler eksplisitt a definere account, projects, capability host og avhengigheter i IaC (Bicep eller Terraform). IaC er kilden til sannhet for raskt a reprodusere konfigurasjon og rolletildelinger.

// main.bicep -- AI Foundry prosjekt med DR-konfigurasjon
param primaryLocation string = 'norwayeast'
param secondaryLocation string = 'swedencentral'
param projectName string = 'ddt-ai-project'

// Cosmos DB med continuous backup og failover
resource cosmosAccount 'Microsoft.DocumentDB/databaseAccounts@2024-05-15' = {
  name: '${projectName}-cosmos'
  location: primaryLocation
  properties: {
    databaseAccountOfferType: 'Standard'
    consistencyPolicy: {
      defaultConsistencyLevel: 'Session'
    }
    locations: [
      {
        locationName: primaryLocation
        failoverPriority: 0
        isZoneRedundant: true
      }
      {
        locationName: secondaryLocation
        failoverPriority: 1
        isZoneRedundant: true
      }
    ]
    backupPolicy: {
      type: 'Continuous'
      continuousModeProperties: {
        tier: 'Continuous30Days'
      }
    }
    enableAutomaticFailover: true
  }
}

// Storage med GZRS
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: '${projectName}storage'
  location: primaryLocation
  sku: {
    name: 'Standard_GZRS'
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
}

// AI Foundry project (primary region)
resource aiProject 'Microsoft.MachineLearningServices/workspaces@2024-04-01' = {
  name: projectName
  location: primaryLocation
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${managedIdentity.id}': {}
    }
  }
  properties: {
    friendlyName: 'DDT AI Project'
    storageAccount: storageAccount.id
    keyVault: keyVault.id
    applicationInsights: appInsights.id
  }
}

CI/CD Pipeline for dual-region deployment

# azure-pipelines.yml
trigger:
  branches:
    include:
      - main

stages:
  - stage: DeployPrimary
    displayName: 'Deploy to Norway East'
    jobs:
      - job: DeployInfra
        steps:
          - task: AzureCLI@2
            inputs:
              azureSubscription: 'ddt-ai-prod'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az deployment group create \
                  --resource-group rg-ai-foundry-norwayeast \
                  --template-file infrastructure/bicep/main.bicep \
                  --parameters location=norwayeast

  - stage: DeploySecondary
    displayName: 'Deploy to Sweden Central'
    dependsOn: DeployPrimary
    jobs:
      - job: DeployInfra
        steps:
          - task: AzureCLI@2
            inputs:
              azureSubscription: 'ddt-ai-prod'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az deployment group create \
                  --resource-group rg-ai-foundry-swedencentral \
                  --template-file infrastructure/bicep/main.bicep \
                  --parameters location=swedencentral

  - stage: DeployAgents
    displayName: 'Deploy Agent Definitions'
    dependsOn:
      - DeployPrimary
      - DeploySecondary
    jobs:
      - job: DeployAgentDefs
        steps:
          - script: |
              python scripts/deploy-agents.py \
                --config agents/agent-definitions/ \
                --regions norwayeast swedencentral

Viktige IaC-prinsipper for DR

1. Bruk user-assigned managed identity -- ved gjenskapning av ressurser forblir rolletildelinger gyldige
2. Unnga usporede endringer i portalen -- alle endringer gjennom IaC/pipeline
3. Bygg IaC modulaert -- uavhengig deployment per prosjekt
4. Opprett rolletildelinger i IaC -- ikke manuelt i portalen
5. Deploy til begge regioner i samme pipeline -- unnga drift

RTO og RPO-definisjoner for AI-prosjekter

Begrepsforklaring

Begrep	Definisjon	Relevans for AI
RTO	Recovery Time Objective -- maks akseptabel tid for a gjenopprette	Hvor lenge kan AI-tjenesten vaere nede?
RPO	Recovery Point Objective -- maks akseptabelt datatap malt i tid	Hvor mye samtalehistorikk/data kan vi miste?
MTTR	Mean Time To Recovery -- gjennomsnittlig gjenopprettingstid	Faktisk maalt gjenopprettingstid
MTBF	Mean Time Between Failures -- gjennomsnittlig tid mellom feil	Paalitelighetsmal for AI-tjenesten

Anbefalte RTO/RPO per komponent

Komponent	RTO-mal	RPO-mal	Gjenopprettingsmetode
Azure OpenAI inference	< 5 min	N/A (stateless)	Automatisk failover via gateway
Agent Service	< 30 min	< 1 time	Redeploy fra IaC + Cosmos PITR
Samtalehistorikk	< 2 timer	< 5 min	Cosmos DB continuous backup
Kunnskapsbaser (RAG)	< 1 time	< 24 timer	Reindeksering fra kilde
Fine-tuned modeller	< 4 timer	< 24 timer	Redeploy fra model registry
Pipeline/evaluering	< 8 timer	< 24 timer	Redeploy fra Git

Tier-basert DR-strategi

Tier 1 -- Virksomhetskritisk (RTO < 5 min, RPO ~0)
  - Azure OpenAI inference med multi-region gateway
  - Automatisk failover via APIM backend pool
  - Eksempel: Innbyggertjenester, sanntids beslutningsstotte

Tier 2 -- Forretningsviktig (RTO < 30 min, RPO < 1 time)
  - Agent Service med Cosmos DB failover
  - Forhands-deployert sekundaer region (warm standby)
  - Eksempel: Intern chatbot, saksbehandlingsassistent

Tier 3 -- Stottende (RTO < 4 timer, RPO < 24 timer)
  - Manuell gjenskapning fra IaC
  - Cold standby i sekundaer region
  - Eksempel: Batch-analysejobber, treningspipelines

Testing og validering av DR-prosedyrer

DR-testrammeverk

Testtype	Frekvens	Omfang	Ansvarlig
Tabletop exercise	Kvartalsvis	Gjennomgang av prosedyrer	Arkitekturteam
Komponent-failover	Manedlig	Enkeltkomponent (f.eks. Cosmos DB)	Driftsteam
Full DR-drill	Halvaarlig	Komplett failover til sekundaer region	Hele teamet
Chaos engineering	Lopende	Automatisert feilinjeksjon	CI/CD pipeline

DR-testprosedyre

Fase 1: Forberedelse (1 dag foer)
  [ ] Verifiser at IaC er oppdatert og synkronisert
  [ ] Bekreft at Cosmos DB backup er aktiv og fungerer
  [ ] Sjekk at sekundaer region har tilstrekkelig kvote
  [ ] Varsle relevante interessenter

Fase 2: Simulert utfall (testdag)
  [ ] Deaktiver primaer region i gateway (APIM policy-endring)
  [ ] Verifiser at trafikk rutes til sekundaer region
  [ ] Kjoer funksjonelle tester mot sekundaer region
  [ ] Mal faktisk RTO og RPO

Fase 3: Validering (under test)
  [ ] Verifiser AI-inferens fungerer korrekt
  [ ] Sjekk at agentsamtaler kan fortsette
  [ ] Kontroller at data-konsistens er ivaretatt
  [ ] Verifiser overvaking og varsling

Fase 4: Tilbakeforing (etter test)
  [ ] Reaktiver primaer region
  [ ] Verifiser at trafikk returnerer til normalt moenster
  [ ] Dokumenter resultater og avvik
  [ ] Oppdater DR-plan basert pa laerdommer

Azure Chaos Studio-integrasjon

Bruk Azure Chaos Studio for automatisert feilinjeksjon:

{
  "type": "Microsoft.Chaos/experiments",
  "name": "ai-foundry-dr-test",
  "properties": {
    "steps": [
      {
        "name": "CosmosDB-failover",
        "branches": [
          {
            "name": "main",
            "actions": [
              {
                "type": "continuous",
                "name": "urn:csci:microsoft:cosmosDB:failover/1.0",
                "duration": "PT10M",
                "parameters": [
                  {
                    "key": "readRegion",
                    "value": "Norway East"
                  }
                ],
                "selectorId": "cosmos-selector"
              }
            ]
          }
        ]
      }
    ],
    "selectors": [
      {
        "id": "cosmos-selector",
        "type": "List",
        "targets": [
          {
            "id": "/subscriptions/.../cosmosdb-account",
            "type": "ChaosTarget"
          }
        ]
      }
    ]
  }
}

Dokumentasjon av DR-tester

Felt	Beskrivelse
Testdato	Dato og tidspunkt for testen
Testtype	Tabletop / Komponent / Full DR
Deltakere	Navn og roller
Scenario	Hva ble simulert
Faktisk RTO	Malt gjenopprettingstid
Faktisk RPO	Malt datatap
Avvik fra mal	Var det gap mellom mal og resultat?
Funn og laerdommer	Hva fungerte, hva ma forbedres?
Tiltak	Konkrete forbedringspunkter med eier og frist

Gjenopprettingsprosedyre ved regionalt utfall

Steg-for-steg gjenoppretting

1. DETEKSJON (automatisk)
   - Azure Monitor-varsling om regionalt utfall
   - Health check-feil fra APIM gateway

2. VURDERING (5-10 min)
   - Er utfallet midlertidig eller vedvarende?
   - Hvilke tjenester er pavirket?
   - Utloes DR-plan hvis utfall > 15 min

3. FAILOVER (15-30 min)
   - Oppdater APIM til a rute all trafikk til sekundaer region
   - Verifiser Cosmos DB automatisk failover
   - Deploy manglende agentdefinisjoner fra kildekontroll
   - Oppdater DNS hvis relevant

4. VALIDERING (15 min)
   - Kjoer smoke tests mot sekundaer region
   - Verifiser at alle endepunkter responderer
   - Kontroller data-tilgjengelighet

5. KOMMUNIKASJON
   - Varsle interne brukere om situasjonen
   - Oppdater statusside

6. FAILBACK (nar primaer region er tilbake)
   - Verifiser primaer region er stabil
   - Gradvis ruter trafikk tilbake
   - Synkroniser eventuelle endringer fra sekundaer region

Referanser

• High availability and resiliency for Microsoft Foundry projects and Agent Services
• Foundry Agent Service disaster recovery
• Foundry Agent Service resource and data loss recovery
• High availability and disaster recovery for hub projects
• Azure security baseline for Azure AI Foundry - Backup and recovery
• Continuous backup with point-in-time restore in Azure Cosmos DB

For Cosmo

• Bruk denne referansen nar kunden planlegger disaster recovery for AI Foundry-prosjekter, spesielt nar det gjelder Agent Service, fine-tuned modeller, eller komplekse AI-pipelines som ma overleve regionalt utfall.
• Fremhev at AI Foundry IKKE tilbyr automatisk failover -- dette er kundens ansvar. Krav til IaC, dual-region deployment og Cosmos DB continuous backup ma kommuniseres tydelig.
• Anbefal user-assigned managed identity som standard -- dette forenkler gjenoppretting dramatisk ved a eliminere behovet for a gjenskape rolletildelinger.
• Tilpass RTO/RPO-maler til organisasjonens faktiske behov -- ikke alle AI-tjenester er virksomhetskritiske. Bruk tier-modellen for a differensiere innsats og kostnad.
• Undersstrek viktigheten av regelmessig DR-testing -- en DR-plan som ikke er testet er ingen plan. Anbefal kvartalsvis tabletop og halvaarlig full DR-drill som minimum.