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:

```bash
# 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

```bash
# 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

```yaml
# 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.

```bicep
// 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

```yaml
# 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:

```json
{
  "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](https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/high-availability-resiliency)
- [Foundry Agent Service disaster recovery](https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/agent-service-disaster-recovery)
- [Foundry Agent Service resource and data loss recovery](https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/agent-service-operator-disaster-recovery)
- [High availability and disaster recovery for hub projects](https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/hub-disaster-recovery)
- [Azure security baseline for Azure AI Foundry - Backup and recovery](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-ai-foundry-security-baseline#backup-and-recovery)
- [Continuous backup with point-in-time restore in Azure Cosmos DB](https://learn.microsoft.com/en-us/azure/cosmos-db/continuous-backup-restore-introduction)

## 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.