ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/model-deployment-strategies-azure.md

Model Deployment Strategies on Azure

Område: MLOps & GenAIOps Dato: 2026-02-04 Målgruppe: Arkitekter som planlegger ML-modellutplassering i produksjon Konfidensgrad: ⚡️⚡️⚡️ Høy (basert på Microsoft Learn + offisielle code samples)

Last updated: 2026-04

Introduksjon

Model deployment strategies handler om hvordan man trygt og effektivt ruller ut nye ML-modeller eller modellversjoner til produksjon uten å forårsake nedetid eller forringet brukeropplevelse. Azure Machine Learning tilbyr flere deployment patterns som støtter progressive exposure, traffic routing, og rollback-mekanismer.

Korrekt valg av deployment strategy reduserer risiko, muliggjør raskere iterasjoner, og sikrer at feil oppdages tidlig før full produksjonsrullering. Dette er spesielt kritisk for GenAI-løsninger hvor modelloppførsel kan variere betydelig mellom versjoner.

Hovedutfordringer:

• Unngå service disruption ved modellbytte
• Validere ny modell mot reell produksjonstrafikk
• Kunne rulle tilbake raskt ved feil
• Sammenligne modellytelse mellom versjoner (A/B testing)
• Håndtere stateful components (databaser, schemas) ved rollback

Kjernekomponenter

1. Azure Machine Learning Online Endpoints

Online endpoints er det primære konseptet for real-time inferencing i Azure ML. Et endpoint fungerer som et API som klienter kan konsumere, mens underliggende deployments representerer den faktiske implementasjonen.

Nøkkelkonsept:

• Endpoint = API-kontrakten (URL, autentisering)
• Deployment = Konkret modellversjon + infrastruktur + scoring script
• Ett endpoint kan ha flere deployments samtidig
• Traffic routing styres på endpoint-nivå

To typer online endpoints:

1. Managed Online Endpoints – Azure administrerer infrastruktur (anbefalt)
2. Kubernetes Online Endpoints – Du administrerer AKS-cluster

Eksempel (Python SDK):

from azure.ai.ml.entities import ManagedOnlineEndpoint, ManagedOnlineDeployment

# Opprett endpoint
endpoint = ManagedOnlineEndpoint(
    name="heart-classifier-endpoint",
    auth_mode="key",
    description="Production endpoint for heart disease classifier"
)
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

# Deployment (med modell, environment, scoring script)
blue_deployment = ManagedOnlineDeployment(
    name="blue",
    endpoint_name="heart-classifier-endpoint",
    model=model,
    environment=env,
    code_configuration=CodeConfiguration(code="./src", scoring_script="score.py"),
    instance_type="Standard_DS3_v2",
    instance_count=2
)
ml_client.online_deployments.begin_create_or_update(blue_deployment).result()

# Allokér all trafikk til blue
endpoint.traffic = {"blue": 100}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

Referanse: Managed online endpoints

---

2. Blue-Green Deployment

Blue-green deployment er en strategi der to identiske miljøer (blue = nåværende, green = ny) kjører parallelt. Trafikken byttes gradvis fra blue til green, og man kan raskt rulle tilbake ved feil.

Workflow:

1. Blue (v1) kjører i produksjon med 100% trafikk
2. Deploy Green (v2) til samme endpoint med 0% trafikk
3. Test Green isolert (via deployment-name parameter)
4. Allokér små andeler trafikk til Green (10%, 25%, 50%)
5. Monitorér health metrics, error rates, latency
6. Gradvis øk til 100% Green
7. Fjern Blue deployment når Green er stabil

Eksempel (Azure CLI):

# Deploy green deployment (0% traffic)
az ml online-deployment create --name green \
  --endpoint-name $ENDPOINT_NAME \
  -f green-deployment.yml

# Test green isolert
az ml online-endpoint invoke --name $ENDPOINT_NAME \
  --deployment-name green \
  --request-file sample.json

# Allokér 10% trafikk til green
az ml online-endpoint update --name $ENDPOINT_NAME \
  --traffic "blue=90 green=10"

# Monitorér, deretter 100% til green
az ml online-endpoint update --name $ENDPOINT_NAME \
  --traffic "blue=0 green=100"

# Slett blue deployment
az ml online-deployment delete --name blue \
  --endpoint-name $ENDPOINT_NAME --yes

Fordeler:

• Null downtime
• Enkel rollback (bare bytt trafikk tilbake)
• Tester mot reell produksjonstrafikk
• Støtter gradvis rollout

Ulemper:

• Krever dobbelt ressurskapasitet under rullering
• Komplisert ved stateful components (database migrations)

Referanse: Safe rollout for real-time inference

---

3. Canary Deployment

Canary deployment er en variant av progressive exposure der en liten "kanari-gruppe" av brukere får tilgang til den nye versjonen først. Dette kan være interne brukere, beta-testere, eller en geografisk region.

Workflow:

1. Deploy ny versjon til subset av infrastruktur (f.eks. én AKS-node)
2. Route 5-10% av trafikk til canary
3. Samle metrics og feedback fra canary-gruppen
4. Utvid gradvis til 25%, 50%, 100%
5. Rulle tilbake hvis canary viser feil

Azure implementering:

• For AKS deployments: Bruk Kubernetes Deployment Stamps pattern
• For Managed Endpoints: Samme som blue-green, men fokus på små initial percentages

Eksempel (Azure DevOps Pipelines):

# Deploy canary with 10% traffic
- task: KubernetesManifest@1
  inputs:
    action: 'deploy'
    strategy: 'canary'
    percentage: '10'
    manifests: 'manifests/deployment.yml'

Fordeler:

• Tidlig feil-deteksjon
• Begrenset blast radius ved feil
• God for testing av nye features med ekte brukere

Ulemper:

• Krever sofistikert traffic routing (feature flags, load balancer)
• Kan være vanskelig å isolere canary-trafikk for debugging

Referanse: Canary deployment for Kubernetes

---

4. Shadow Deployment (Traffic Mirroring)

Shadow deployment kopierer en prosentandel av live trafikk til en ny deployment uten å returnere resultater til klienten. Dette lar deg validere ny modell mot reell produksjonsdata uten å påvirke brukere.

Nøkkelkonsept:

• Mirror traffic = Kopier requests til shadow deployment
• Klienten får alltid svar fra primær deployment (blue)
• Shadow deployment (green) logger metrics, men påvirker ikke response
• Maks 50% mirror traffic (bandwidth quota limits)

Eksempel (Python SDK):

# Mirror 10% av trafikk til green
endpoint.mirror_traffic = {"green": 10}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

# Invoke endpoint flere ganger (trafikk går til blue, 10% mirrors til green)
for i in range(100):
    ml_client.online_endpoints.invoke(
        endpoint_name=endpoint_name,
        request_file="sample.json"
    )

# Sjekk green logs for validering
ml_client.online_deployments.get_logs(
    name="green",
    endpoint_name=endpoint_name,
    lines=100
)

# Disable mirroring
endpoint.mirror_traffic = {"green": 0}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

Begrensninger:

• Ikke støttet for Kubernetes online endpoints
• Maks 50% mirror traffic (p.g.a. endpoint bandwidth quota)
• Kun én deployment kan motta mirrored traffic
• En deployment kan ikke motta både live og mirrored traffic

Use cases:

• Validere latency for ny modell
• Sjekke for HTTP errors før live traffic
• Sammenligne predictions mellom modeller (offline analysis)

Referanse: Traffic mirroring documentation

---

5. A/B Testing

A/B testing router trafikk mellom to (eller flere) modellversjoner for å sammenligne performance metrics, conversion rates, eller brukeropplevelse.

Implementering i Azure ML:

# 50/50 split mellom v1 og v2
endpoint.traffic = {"model-v1": 50, "model-v2": 50}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

Viktige poeng:

• Total traffic må summere til 100% (eller 0% for disable)
• Bruk Application Insights for å tracke metrics per deployment
• Samle nok data før konklusjon (statistisk signifikans)

Advanced: Target specific deployment via HTTP header:

# Klient kan overstyre traffic routing med header:
# azureml-model-deployment: model-v2

Referanse: Controlled rollout for online endpoints

---

Arkitekturmønstre

Mønster 1: Progressive Rollout for Managed Endpoints

Scenario: Du har en produksjonsmodell (v1) og vil deploye v2 med minimal risiko.

Steg:

1. Deploy v2 med 0% traffic

   az ml online-deployment create --name v2 \
     --endpoint-name prod-endpoint -f v2-deployment.yml
   

2. Test isolert

   az ml online-endpoint invoke --name prod-endpoint \
     --deployment-name v2 --request-file test-data.json
   

3. Mirror 10% trafikk for validation (valgfritt)

   az ml online-endpoint update --name prod-endpoint \
     --mirror-traffic "v2=10"
   

   Bake time: 6-12 timer. Sjekk logs for errors, latency, HTTP 500s.

4. Start live traffic med 10%

   az ml online-endpoint update --name prod-endpoint \
     --traffic "v1=90 v2=10" --mirror-traffic "v2=0"
   

   Bake time: 24 timer. Monitorér Application Insights metrics.

5. Øk gradvis til 25%, 50%, 100%

   # 50/50 split
   az ml online-endpoint update --name prod-endpoint \
     --traffic "v1=50 v2=50"
   
   # Full rollout
   az ml online-endpoint update --name prod-endpoint \
     --traffic "v1=0 v2=100"
   

   Bake time: Øk mellom hver fase (24-48 timer for 50%, 72 timer før 100%).

6. Fjern v1 deployment

   az ml online-deployment delete --name v1 \
     --endpoint-name prod-endpoint --yes
   

Health checks per fase:

• HTTP error rate < 0.1%
• p95 latency < SLA threshold
• Model prediction drift innenfor toleranse
• No increase in retry/timeout errors

---

Mønster 2: Blue-Green med Database Migrations

Utfordring: Stateful components (database schema endringer) kompliserer rollback.

Løsning: Backward-compatible schema migrations

Steg:

1. Deploy database schema v2 (backward compatible)

   • Nye kolonner har default values
   • Gamle kolonner beholdes (deprecated, ikke fjernet)
   • Applikasjonen kan kjøre mot begge schemas

2. Deploy blue (v1) og green (v2) parallelt

   • Begge deployments bruker samme database
   • v1 ignorerer nye kolonner
   • v2 populerer nye kolonner

3. Gradvis trafikk-bytte (som tidligere)

4. Cleanup fase (etter 100% green)

   • Kjør datamigrasjon script for å fylle nye kolonner (for gamle rader)
   • Etter 1-2 uker, fjern deprecated kolonner

Rollback-strategi:

• Hvis feil oppdages før cleanup: Bare bytt trafikk tilbake til blue
• Hvis feil oppdages etter cleanup: Krever restore fra backup (derfor lang bake time)

---

Mønster 3: Multi-Region Deployment with Canary

Scenario: Global produksjonsmodell med brukere i Europa, USA, Asia.

Arkitektur:

Azure Front Door (global load balancer)
├── Region: West Europe
│   ├── Endpoint: eu-prod-endpoint
│   │   ├── Deployment: blue (v1)
│   │   └── Deployment: green (v2) [canary]
├── Region: East US
│   └── Endpoint: us-prod-endpoint
│       └── Deployment: blue (v1)
└── Region: Southeast Asia
    └── Endpoint: asia-prod-endpoint
        └── Deployment: blue (v1)

Rollout plan:

1. Deploy green til West Europe endpoint (10% trafikk)
2. Bake time: 48 timer (dekker ulike tidssoner i Europa)
3. Hvis OK: Øk til 100% i West Europe
4. Deploy green til East US (10% trafikk)
5. Bake time: 48 timer
6. Hvis OK: Øk til 100% i East US
7. Deploy green til Southeast Asia (10% trafikk)
8. Final bake: 48 timer, deretter 100%

Fordel: Begrenser blast radius til én region. Hvis West Europe feiler, USA og Asia er upåvirket.

---

Beslutningsveiledning

Når bruke hvilken strategi?

Strategi	Bruk når...	Ikke bruk når...
Blue-Green	- Kritisk produksjonsmodell - Trenger rask rollback - Kan doble infrastruktur midlertidig	- Svært stateful (kompleks database) - Knappe ressurser (cost constraints)
Canary	- Ny feature med ukjent impact - Interne brukere kan teste først - Geografisk segmenterte brukere	- Alle brukere må få samme versjon - Real-time consistency krav
Shadow Deployment	- Validere ytelse før live traffic - Sammenligne modellpredictions offline - Testing av latency/throughput	- Bandwidth quotas er trange - Trenger immediate feedback fra brukere
A/B Testing	- Business-critical decision (f.eks. recommendation model) - Trenger statistisk signifikant sammenligning	- Raskt behov for rollout - Ikke nok trafikk for statistisk kraft
Progressive Rollout	- Standard for alle produksjonsdeployments - Alltid kombinert med en av strategiene over	- (Alltid bruk progressive rollout!)

---

Beslutningstre

START: Skal deploye ny modellversjon?
│
├─ Er dette første produksjonsdeployment?
│  └─ JA → Deploy single deployment (100% traffic) → Ferdig
│
├─ Har du stateful components (database)?
│  ├─ JA → Implementer backward-compatible migrations først
│  └─ NEI → Fortsett
│
├─ Trenger du sammenligne to versjoner for business metrics?
│  ├─ JA → A/B Testing (50/50 eller annen split)
│  └─ NEI → Fortsett
│
├─ Er modellen kritisk (høy blast radius ved feil)?
│  ├─ JA → Shadow deployment først (mirror 10-50%)
│  │      → Deretter Blue-Green med canary percentages (10% → 25% → 50% → 100%)
│  └─ NEI → Blue-Green med standard rollout (10% → 100%)
│
└─ Er brukerbasen geografisk spredt?
   ├─ JA → Multi-region canary (én region om gangen)
   └─ NEI → Single-region progressive rollout

---

Integrasjon med Microsoft-stakken

1. Azure DevOps Pipelines

CI/CD for ML model deployment:

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

stages:
  - stage: Build
    jobs:
      - job: TrainModel
        steps:
          - task: AzureCLI@2
            inputs:
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az ml job create -f training-job.yml

  - stage: DeployCanary
    dependsOn: Build
    jobs:
      - deployment: DeployGreen
        environment: 'production'
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureCLI@2
                  displayName: 'Deploy green (0% traffic)'
                  inputs:
                    scriptType: 'bash'
                    inlineScript: |
                      az ml online-deployment create --name green \
                        --endpoint-name prod-endpoint -f green.yml

  - stage: Canary10Percent
    dependsOn: DeployCanary
    jobs:
      - job: UpdateTraffic
        steps:
          - task: AzureCLI@2
            displayName: 'Route 10% to green'
            inputs:
              scriptType: 'bash'
              inlineScript: |
                az ml online-endpoint update --name prod-endpoint \
                  --traffic "blue=90 green=10"
          - task: Delay@1
            inputs:
              delayForMinutes: '60'  # Bake time

  - stage: ValidateCanary
    dependsOn: Canary10Percent
    jobs:
      - job: CheckMetrics
        steps:
          - task: AzureCLI@2
            displayName: 'Query Application Insights'
            inputs:
              scriptType: 'bash'
              inlineScript: |
                # Sjekk error rate for green deployment
                ERROR_RATE=$(az monitor app-insights metrics show \
                  --app my-app-insights \
                  --metric "requests/failed" \
                  --filter "cloud/roleName eq 'green'" \
                  --aggregation avg --query value -o tsv)

                if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
                  echo "Error rate too high, failing pipeline"
                  exit 1
                fi

  - stage: RolloutFull
    dependsOn: ValidateCanary
    condition: succeeded()
    jobs:
      - deployment: FullRollout
        environment: 'production-approval'  # Manual approval gate
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureCLI@2
                  inputs:
                    scriptType: 'bash'
                    inlineScript: |
                      az ml online-endpoint update --name prod-endpoint \
                        --traffic "blue=0 green=100"

Approval gates:

• Environment protection rules i Azure DevOps sikrer manuell godkjenning før full rollout
• Integrer med Azure Monitor alerts for automatisk rollback ved feil

---

2. Azure Monitor & Application Insights

Health metrics for deployment validation:

# Python-script for å sjekke deployment health
from azure.monitor.query import MetricsQueryClient, MetricAggregationType
from azure.identity import DefaultAzureCredential
from datetime import timedelta

credential = DefaultAzureCredential()
client = MetricsQueryClient(credential)

# Hent metrics for green deployment (siste time)
response = client.query_resource(
    resource_uri=f"/subscriptions/{subscription_id}/resourceGroups/{rg}/providers/Microsoft.MachineLearningServices/workspaces/{ws}/onlineEndpoints/{endpoint}/deployments/green",
    metric_names=["RequestLatency", "RequestsPerSecond", "CpuUtilizationPercentage"],
    timespan=timedelta(hours=1),
    aggregations=[MetricAggregationType.AVERAGE, MetricAggregationType.P95]
)

for metric in response.metrics:
    print(f"{metric.name}: {metric.timeseries[0].data[0].average}")

Alerts for automatic rollback:

# Opprett alert rule for høy error rate
az monitor metrics alert create \
  --name "green-deployment-high-errors" \
  --resource-group myRG \
  --scopes /subscriptions/.../onlineEndpoints/prod-endpoint/deployments/green \
  --condition "avg requests/failed > 5" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action /subscriptions/.../actionGroups/rollback-webhook

---

3. Azure Machine Learning Registries (MLOps maturity)

Shared model registry på tvers av workspaces:

# Register model i shared registry (én gang)
from azure.ai.ml import MLClient
from azure.ai.ml.entities import Model

registry_client = MLClient(credential, registry_name="company-ml-registry")

model = Model(
    name="heart-classifier",
    version="2.0",
    path="./model",
    type="mlflow_model",
    tags={"production-ready": "true"}
)
registry_client.models.create_or_update(model)

# Deploy fra registry i flere workspaces (dev, staging, prod)
prod_client = MLClient(credential, subscription_id, "prod-rg", "prod-ws")

deployment = ManagedOnlineDeployment(
    name="green",
    endpoint_name="prod-endpoint",
    model=f"azureml://registries/company-ml-registry/models/heart-classifier/versions/2.0",
    instance_type="Standard_DS3_v2",
    instance_count=2
)
prod_client.online_deployments.begin_create_or_update(deployment).result()

Fordeler:

• Én kilde til sannhet for produksjonsmodeller
• Deploy samme modell-artifact til dev/staging/prod (consistency)
• Støtter multi-region deployment med samme modellversjon

Referanse: Machine Learning Registries for MLOps

---

4. MLflow for Model Packaging

No-code deployment av MLflow-modeller:

# Registrer MLflow model (inkluderer dependencies)
import mlflow

mlflow.set_tracking_uri(workspace.get_mlflow_tracking_uri())

with mlflow.start_run():
    mlflow.sklearn.log_model(
        sk_model=model,
        artifact_path="model",
        registered_model_name="heart-classifier",
        signature=signature,
        conda_env=conda_env
    )

# Deploy uten scoring script (Azure ML genererer automatisk)
deployment = ManagedOnlineDeployment(
    name="green",
    endpoint_name="prod-endpoint",
    model="azureml:heart-classifier@latest",  # MLflow model
    instance_type="Standard_DS3_v2",
    instance_count=2
    # Ingen code_configuration eller environment nødvendig!
)

Fordeler:

• Raskere deployment (ingen custom scoring script)
• Built-in support for scikit-learn, TensorFlow, PyTorch
• Enklere rollback (bare endre model version)

Auth note (Verified MCP 2026-04): For production deployments, use Microsoft Entra token-based authentication (aad_token) instead of key-based auth — provides identity-based access control.

Referanse: Deploy MLflow models to online endpoints

---

Offentlig sektor (Norge)

1. Krav til endringshåndtering (Digdir)

Utredningsinstruksen (2016) § 5:

• Alle større IT-endringer (inkludert ML-modellutplasseringer) må dokumenteres med beslutningsgrunnlag
• ADR (Architecture Decision Record) bør inkludere valg av deployment strategy

Eksempel ADR for deployment strategy:

# ADR-023: Blue-Green Deployment for Kredittscoring-modell

## Status
Akseptert (2026-02-04)

## Kontekst
Vi må deploye v2 av kredittscoring-modellen til produksjon. Modellen
påvirker 50 000 søknader per måned. Feil kan føre til feilaktige
kredittvurderinger med økonomiske og juridiske konsekvenser.

## Beslutning
Vi bruker **blue-green deployment** med følgende faser:
1. Shadow deployment (mirror 10%) i 48 timer
2. Live traffic 10% i 72 timer
3. Live traffic 50% i 72 timer
4. Live traffic 100%

## Konsekvenser
+ Redusert risiko for feil (gradvis rollout)
+ Rask rollback (bare bytt trafikk)
- Økte infrastrukturkostnader i rollout-perioden (2x compute)
- Krever 1 uke total rollout-tid

## Compliance
- Personvernforordningen (GDPR): Logging av alle modellpredictions
- Arkivloven: Bevaring av modellversjon-metadata i 5 år

---

2. Logging og Etterprøvbarhet

Krav (GDPR Art. 22 + Arkivloven):

• Alle automatiserte beslutninger må kunne etterprøves
• Ved modellbytte: Logg hvilken versjon som ga hver prediction

Implementering:

# Custom scoring script med versjon-logging
import json
import logging
from datetime import datetime

def init():
    global model, model_version
    model = mlflow.pyfunc.load_model(model_path)
    model_version = os.getenv("MODEL_VERSION", "unknown")

def run(raw_data):
    data = json.loads(raw_data)
    predictions = model.predict(data["input"])

    # Logg hver prediction med modellversjon
    for i, pred in enumerate(predictions):
        logging.info(json.dumps({
            "timestamp": datetime.utcnow().isoformat(),
            "model_version": model_version,
            "deployment_name": os.getenv("DEPLOYMENT_NAME"),
            "input_hash": hashlib.sha256(str(data["input"][i]).encode()).hexdigest(),
            "prediction": float(pred),
            "user_id": data.get("user_id", [None])[i]
        }))

    return predictions.tolist()

Log Analytics query for å finne alle predictions fra en deployment:

AppTraces
| where TimeGenerated > ago(7d)
| extend LogData = parse_json(Message)
| where LogData.deployment_name == "green"
| project TimeGenerated, LogData.model_version, LogData.prediction, LogData.user_id
| summarize PredictionCount = count() by model_version

---

3. Risikovurdering (ROS-analyse)

Trussel: Feil i ny modellversjon gir feilaktige beslutninger

Sannsynlighet	Konsekvens	Risiko	Tiltak
Middels (3/5)	Høy (4/5)	12 (Rød)	- Progressive rollout med 48t bake time - Shadow deployment før live - Automated rollback ved error rate > 0.1% - Manual approval gate før 100% rollout

Implementering av tiltak:

1. Automated rollback via Azure Monitor alert + Logic App
2. Manual approval via Azure DevOps environment protection
3. Shadow deployment i 48 timer (dekker helg + hverdag)

---

4. Kostnader for Progressive Rollout

Scenario: Blue-green deployment i 1 uke rollout-periode

Fase	Blue Instances	Green Instances	Varighet	Cost (NOK/mnd)*
Shadow (mirror 10%)	2x DS3_v2	2x DS3_v2	2 dager	~520 NOK
Live 10%	2x DS3_v2	2x DS3_v2	3 dager	~780 NOK
Live 50%	2x DS3_v2	2x DS3_v2	2 dager	~520 NOK
Live 100% (cleanup)	0	2x DS3_v2	-	0 NOK (baseline)

Total ekstra kostnad: ~1 820 NOK for 1 ukes rollout (dobbelt kapasitet i 7 dager).

Optimalisering:

• Bruk autoscaling på green deployment (start med 1 instance, skaler ved behov)
• Scheduled scaling: Reducer instances utenfor kontortid (hvis batch-scoring)

*Basert på DS3_v2 = ~2 600 NOK/mnd (per instance)

---

Kostnad og lisensiering

1. Compute-kostnader

Managed Online Endpoints (Pay-as-you-go):

VM Type	vCPU	RAM	Cost (NOK/time)*	Anbefalt for
Standard_DS2_v2	2	7 GB	~1,10	Dev/test, små modeller
Standard_DS3_v2	4	14 GB	~2,20	Produksjon (medium load)
Standard_DS4_v2	8	28 GB	~4,40	Produksjon (høy load)
Standard_NC6s_v3 (GPU)	6	112 GB	~25,00	Deep learning inferencing

Blue-green deployment cost multiplier:

• Under rollout: 2x compute cost (begge deployments kjører)
• Varighet: 1-2 uker (avhengig av bake times)
• Total overhead: ~5-10% av årlig compute-kostnad

Eksempel:

• Baseline produksjon: 2x DS3_v2 (24/7) = ~5 200 NOK/mnd
• Med 4 rollouts per år (1 uke each): 5 200 + (1 820 × 4/12) = ~5 807 NOK/mnd
• Overhead: ~12%

*Priser er estimat per jan 2026, Norway East region.

---

2. Bandwidth og Storage

Endpoint bandwidth quota:

• Default: 5 MBps per endpoint
• Shadow deployment: Teller mot bandwidth (derfor 50% max mirror traffic)
• Overskridelse: Throttling (HTTP 429 errors)

Kostnad ved throttling:

• Ikke direkte kostnad, men reduced throughput
• Løsning: Øk quota (support ticket) eller optimaliser payload size

Model registry storage:

• Gratis for første 10 GB
• Deretter: ~0,50 NOK/GB/mnd
• Ved mange modellversjoner: Implementer retention policy (slett gamle versjoner)

---

3. Lisensiering

Azure Machine Learning workspace:

• Gratis (betaler kun for underliggende compute/storage)
• Alle deployment-features (blue-green, mirroring, A/B) inkludert

MLflow:

• Open source, gratis
• Azure ML har innebygd MLflow tracking (ingen ekstra kostnad)

Azure DevOps:

• Gratis tier: 1 hosted pipeline (Microsoft-hosted agent)
• Basic plan: ~50 NOK/bruker/mnd + pipeline minutes
• Deployment-pipelines krever parallel jobs (ekstra cost hvis mange pipelines)

---

For arkitekten (Cosmo)

1. Checklist før du velger deployment strategy

Spørsmål å stille stakeholders:

1. Hva er maksimal akseptabel downtime?

   • 0 minutter → Blue-Green eller Canary
   • <30 minutter → In-place deployment med rolling update

2. Hvor kritisk er modellen for business?

   • Kritisk (påvirker revenue/compliance) → Shadow først, deretter gradvis rollout
   • Medium → Blue-Green med 10% → 100%
   • Lav → Direct deployment med basic smoke test

3. Har du stateful components (database)?

   • Ja → Implementer backward-compatible migrations først
   • Nei → Enklere rollback-strategi

4. Trenger dere sammenligne modellversjoner for metrics?

   • Ja → A/B testing (50/50 eller annen split)
   • Nei → Blue-Green

5. Hva er budget for ekstra compute under rollout?

   • Begrenset → Canary (én node om gangen)
   • Fleksibelt → Blue-Green (full parallell kapasitet)

6. Hvor lang tid har dere for å rulle ut?

   • 1-2 dager → Aggressiv rollout (10% → 100% raskt)
   • 1-2 uker → Konservativ (shadow + bake times)

---

2. Anti-patterns (hva du IKKE skal gjøre)

❌ Direct swap uten testing:

# IKKE GJØR DETTE!
endpoint.traffic = {"blue": 0, "green": 100}  # 0% → 100% instant
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

Problem: Ingen validering, ingen rollback-mulighet, høy blast radius.

✅ Gjør dette isteden:

# Shadow først
endpoint.mirror_traffic = {"green": 10}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()
time.sleep(3600 * 24)  # 24 timer bake time

# Så gradvis live
endpoint.mirror_traffic = {"green": 0}
endpoint.traffic = {"blue": 90, "green": 10}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

---

❌ Ingen health metrics monitoring:

• Deploye ny versjon uten å sjekke error rates, latency, throughput

✅ Implementer automated health checks:

def check_deployment_health(deployment_name, threshold_error_rate=0.01):
    """Sjekk health metrics for deployment."""
    response = metrics_client.query_resource(
        resource_uri=f".../{deployment_name}",
        metric_names=["RequestLatency", "RequestsPerSecond", "RequestsFailed"],
        timespan=timedelta(hours=1)
    )

    error_rate = response.metrics["RequestsFailed"].average / response.metrics["RequestsPerSecond"].average
    if error_rate > threshold_error_rate:
        raise Exception(f"Error rate {error_rate:.2%} exceeds threshold {threshold_error_rate:.2%}")

    return True

---

❌ Slett blue deployment for tidlig:

• Fjerne blue deployment rett etter 100% green rollout

✅ Behold blue i minst 1 uke:

# Vent 1 uke etter 100% rollout før cleanup
endpoint.traffic = {"blue": 0, "green": 100}
ml_client.online_endpoints.begin_create_or_update(endpoint).result()

# Sett reminder: Cleanup blue deployment etter 2026-02-11

Rasjonale: Hvis kritisk bug oppdages etter 3 dager, kan du raskt rulle tilbake til blue uten redeployment.

---

3. Rollback-playbook

Scenario: Green deployment viser økt error rate under 50% rollout

Steg:

1. Immediate action (< 5 min):

   # Bytt tilbake til 100% blue
   az ml online-endpoint update --name prod-endpoint \
     --traffic "blue=100 green=0"
   

2. Verifiser rollback (< 10 min):

   # Sjekk at error rate går ned
   az monitor app-insights query \
     --app my-app-insights \
     --analytics-query "requests | where timestamp > ago(5m) | summarize ErrorRate = countif(success == false) / count()"
   

3. Incident postmortem (< 24 timer):

   • Hva var root cause? (sjekk logs: az ml online-deployment get-logs --name green)
   • Hvorfor fanget vi ikke dette i shadow phase?
   • Oppdater deployment checklist med ny validering

4. Fix og redeploy (< 1 uke):

   • Fix bug i kode/modell
   • Re-run training/testing
   • Start ny rollout fra steg 1 (shadow deployment)

---

4. Conversation starters med kunden

Når kunden sier: "Vi vil bare deploye den nye modellen nå."

Cosmo: "Jeg forstår at dere er klare for produksjon. La meg stille noen raske spørsmål for å sikre en trygg deployment:

1. Hvis den nye modellen viser seg å ha feil i produksjon, hvor raskt må vi kunne rulle tilbake? 5 minutter? 1 time? 1 dag?

2. Har dere monitoring satt opp for å oppdage feil? Hvilke metrics ser dere på – error rate, latency, modell-drift?

3. Er det OK å kjøre begge modellversjonene parallelt i 1-2 uker (dvs. dobbel infrastrukturkostnad)? Eller må vi optimalisere for kostnad?

Basert på svarene kan vi velge rett strategi – f.eks. blue-green med gradvis rollout hvis dere trenger rask rollback, eller canary hvis kostnadsoptimalisering er prioritet."

---

Når kunden sier: "Vi har ikke tid til langsom rollout, vi må ha 100% i produksjon i morgen."

Cosmo: "Jeg skjønner at time-to-market er kritisk. La oss se på risiko vs. hastighet:

Rask rollout (1-2 dager):

• Deploy green med 0% traffic i kveld
• Test isolert i natt (automated smoke tests)
• 50% traffic i morgen tidlig (kl 09:00)
• 100% traffic samme dag (kl 15:00) hvis ingen kritiske feil
• Risiko: Hvis feil oppdages kl 16:00, har 50% av brukere fått dårlig service hele dagen

Balansert rollout (3-4 dager):

• Shadow deployment i 24 timer (validere mot real traffic)
• 10% live traffic dag 2
• 50% live traffic dag 3
• 100% live traffic dag 4
• Risiko: Redusert blast radius (maks 10% brukere påvirket hvis feil)

Hva er konsekvensen hvis 50% av brukere får feil predictions i ett døgn? Hvis det er akseptabelt, kan vi kjøre rask rollout. Hvis ikke, anbefaler jeg balansert."

---

5. Teknisk deep-dive: Hvordan traffic routing fungerer

Under panseret på Azure ML Online Endpoints:

Client Request (HTTP POST)
    ↓
Azure Front Door (global load balancer)
    ↓
Endpoint (prod-endpoint.norwayeast.inference.ml.azure.com)
    ↓
Traffic Routing Logic:
    - Hvis HTTP header "azureml-model-deployment: green" → Route til green
    - Ellers: Bruk traffic percentage (f.eks. 90% blue, 10% green)
    ↓
Deployment (blue eller green)
    ↓
Scoring Container (Docker image med model + scoring script)
    ↓
Return Prediction

Mirror traffic flow:

Client Request
    ↓
Endpoint
    ├─→ Primary Deployment (blue) → Return Response til client
    └─→ Shadow Deployment (green) → Logg metrics, IKKE return response

Viktig implementasjonsdetalje:

• Traffic routing skjer før request når deployment container
• Mirror traffic er async (non-blocking for primary deployment)
• Hvis shadow deployment crasher, påvirker det ikke client response

---

Kilder og verifisering

Denne kunnskapsreferansen er basert på følgende Microsoft Learn-artikler og code samples (verifisert 2026-02-04):

Primære kilder:

1. Perform safe rollout of new deployments for real-time inference → Komplett guide til blue-green deployment og traffic mirroring (Verified MCP 2026-04)

2. MLOps model management with Azure Machine Learning → Oversikt over deployment capabilities og controlled rollout

3. Online endpoint deployment for real-time inferencing → Konsepter: endpoints vs. deployments, traffic routing, mirroring

4. Tutorial: Use a canary deployment strategy for Kubernetes → Canary deployment med Azure DevOps Pipelines

5. Progressive rollout of MLflow models to Online Endpoints → MLflow-spesifikk progressive rollout; supports model packaging (--with-package) for endpoints without egress connectivity (Verified MCP 2026-04)

Code samples:

• azureml-examples/sdk/python/endpoints/online/managed/online-endpoints-safe-rollout.ipynb
• azureml-examples/cli/endpoints/online/managed/sample/

Well-Architected Framework:

• Architecture strategies for safe deployment practices → Progressive exposure model, bake times, rollback strategies (Verified MCP 2026-04 — adds safe decommissioning guidance + AI opportunity note for GenAI-assisted rollout tuning)

Pricing (sist verifisert: 2026-02-04):

• Azure Machine Learning pricing → Compute costs for managed endpoints

MCP-kall utført: 8 (microsoft_docs_search × 5, microsoft_docs_fetch × 2, microsoft_code_sample_search × 1)

---

Sist oppdatert: 2026-04-10 Neste review: 2026-07-10 (eller ved større endringer i Azure ML deployment capabilities)

Safe Rollout / Blue-Green Deployment (Azure Well-Architected 2026)

Azure ML managed online endpoints support blue-green (safe rollout) deployments natively:

# Deploy green deployment with 0% traffic initially
az ml online-deployment create --name green --endpoint my-endpoint --traffic-allocation 0

# Test green deployment in isolation (direct routing)
az ml online-endpoint invoke --name my-endpoint --deployment-name green

# Mirror 10% of live traffic to green for shadow testing
# Then progressively shift: 10% → 50% → 100%
az ml online-endpoint update --name my-endpoint --traffic blue=90 green=10

Azure Well-Architected SDP principles (OE:11):

• Progressive exposure: Canary → Blue-Green → Deployment Stamps
• Health models: Pass health checks before each rollout phase
• Bake time: Hours/days between phases (not minutes) to capture time-zone usage patterns
• Failure detection: Automatic halt + investigation when health signals degrade
• Recovery options: Roll back (revert), roll forward (hotfix), or redeploy last known good

Azure facilitation:

• Azure Pipelines + GitHub Actions support multi-stage deployments with approval gates
• Azure App Configuration for feature flag management
• Azure Load Balancers for traffic routing and health monitoring
• Point-in-time restore available for Azure SQL, Cosmos DB, MySQL, PostgreSQL

Emergency SDP: Prescriptive protocols for hotfix acceleration — approval stage and bake time reduction — with explicit approval criteria.

Safe decommissioning (new in 2026-04): Removing components is highest-risk. Steps: validate inactivity → preserve state (backup/export) → disable before deleting → monitor watch window covering full usage cycle → clean up residual references. Skip disable only if compliance requires immediate removal.

AI opportunity: AI can assist rollout tuning — analyze deployment docs, code reviews, incident history to suggest rollout strategies and parameters (low/medium GenAI approach). Advanced agentic solutions can auto-update rollout configurations.