Migracja do Azure krok po kroku - App Service, AKS i Landing Zone dla .NET

Migracja do Azure dla aplikacji .NET wygląda z pozoru prosto - w końcu to ekosystem Microsoftu. W praktyce firmy napotykają te same problemy: brak struktury subskrypcji, źle zaprojektowany networking, koszty wymykające się spod kontroli po pierwszym miesiącu. Ten przewodnik opisuje proces, który minimalizuje te ryzyka.

Dlaczego Azure dla aplikacji .NET

Azure to naturalne środowisko dla aplikacji .NET z kilku powodów technicznych i biznesowych:

• Natywna integracja z .NET - App Service, Azure Functions i AKS mają pełne wsparcie dla .NET 8/9. Hot reload, diagnostyka, profiling - wszystko działa od razu bez konfiguracji dodatkowych agentów.
• Azure Hybrid Benefit - jeśli masz licencje Windows Server lub SQL Server z Software Assurance, możesz ich używać w Azure bez dodatkowych opłat. Dla typowej firmy z 10 serwerami Windows to oszczędność 40-60% na compute.
• Entra ID (Azure AD) - jeśli organizacja korzysta z Microsoft 365, tożsamości już istnieją. SSO do aplikacji wewnętrznych działa natychmiast bez budowania osobnego systemu IAM.
• Regiony w Europie - Poland Central (Warszawa) dostępny od 2023 roku. Dla aplikacji wymagających rezydencji danych w Polsce (sektor finansowy, administracja) to jedyna opcja wśród hyperscalerów.
• Compliance - certyfikaty KNF, UODO, ISO 27001 dla regionu Poland Central. Dokumentacja zgodności dostępna w Azure Compliance Manager.

To nie znaczy, że Azure jest jedynym wyborem. Jeśli Twoja aplikacja to czyste API w kontenerach bez zależności od ekosystemu Microsoft - AWS i GCP też są świetnymi opcjami. Ale jeśli masz .NET + SQL Server + Active Directory + licencje Microsoft - Azure daje najkrótszą drogę do chmury.

Landing Zone - fundament przed migracją

Landing Zone to przygotowane środowisko Azure z poprawną strukturą zarządzania, siecią, bezpieczeństwem i politykami. Bez tego migrujesz do chaosu.

Czym jest Azure Landing Zone

Landing Zone to nie produkt do kupienia - to architektura referencyjna Microsoftu (Cloud Adoption Framework), która definiuje:

• Strukturę Management Group i subskrypcji
• Topologię sieciową (hub-spoke lub Virtual WAN)
• Polityki governance (Azure Policy)
• Bazowe usługi bezpieczeństwa (Microsoft Defender for Cloud, Key Vault)
• Monitoring (Log Analytics Workspace, Azure Monitor)

Bez Landing Zone typowy scenariusz wygląda tak: zespół devów tworzy subskrypcję, wdraża aplikację, po 3 miesiącach nikt nie wie kto za co płaci, sieć jest płaska (wszystko widzi wszystko), a polityki bezpieczeństwa nie istnieją.

Struktura subskrypcji dla polskiej firmy

Minimalna sensowna struktura dla organizacji migrującej pierwszą aplikację:

Tenant Root Group
└── Devopsity (Management Group)
    ├── Platform
    │   ├── sub-connectivity    (hub VNet, DNS, firewall)
    │   └── sub-management      (Log Analytics, Automation)
    └── Workloads
        ├── sub-prod            (produkcja)
        └── sub-nonprod         (dev + staging)

Dlaczego osobne subskrypcje?

• Izolacja kosztów - widzisz ile kosztuje produkcja vs. dev bez tagowania
• Izolacja uprawnień - deweloperzy mają Contributor na nonprod, Reader na prod
• Limity - każda subskrypcja ma osobne limity (vCPU, public IPs)
• Alerty budżetowe - oddzielne progi dla każdej subskrypcji

Dla firmy 20-50 osób z jedną aplikacją - 4 subskrypcje to minimum. Dla większych organizacji z wieloma zespołami - jedna subskrypcja na każde obciążenie i środowisko.

Networking - topologia hub-spoke

Hub-spoke to najprostsza topologia, która daje izolację i centralną kontrolę:

• Hub VNet (sub-connectivity) - centralny punkt: Azure Firewall lub NVA, VPN Gateway do on-premise, DNS Private Resolver
• Spoke VNet (sub-prod, sub-nonprod) - sieci dla aplikacji, peerowane z hubem

┌─────────────────────────────────────────────┐
│ Hub VNet (10.0.0.0/16)                      │
│  ├── AzureFirewallSubnet (10.0.1.0/24)      │
│  ├── GatewaySubnet (10.0.2.0/24)            │
│  └── DNSResolverSubnet (10.0.3.0/24)        │
└─────────────┬───────────────┬───────────────┘
              │ peering       │ peering
┌─────────────▼──────┐  ┌────▼──────────────┐
│ Spoke-Prod          │  │ Spoke-NonProd      │
│ (10.1.0.0/16)       │  │ (10.2.0.0/16)      │
│  ├── AppSubnet      │  │  ├── AppSubnet     │
│  ├── DataSubnet     │  │  ├── DataSubnet    │
│  └── AKSSubnet      │  │  └── AKSSubnet     │
└────────────────────┘  └────────────────────┘

Kluczowe decyzje:

• Azure Firewall vs NVA - Azure Firewall to managed service (~$900/miesiąc bazowy koszt). Dla mniejszych firm wystarczy NSG + Route Tables bez firewalla. Firewall dodaj, gdy masz wymagania compliance na inspekcję ruchu egress.
• DNS - Azure Private DNS Zones dla usług PaaS (Private Endpoints). Jeśli masz AD DS on-premise - DNS forwarding do on-prem DNS przez Private Resolver.
• VPN vs ExpressRoute - VPN Gateway (~$140/miesiąc) dla ruchu <1 Gbps. ExpressRoute (~$200/miesiąc + opłata za port u providera) dla dedicated connection i niższych latency.

App Service vs AKS - kiedy które wybrać

To najczęstsze pytanie przy migracji .NET do Azure. Odpowiedź zależy od złożoności aplikacji, wymagań operacyjnych i kompetencji zespołu.

App Service - kiedy wystarczy

App Service to w pełni zarządzana platforma PaaS. Nie zarządzasz serwerami, nie konfigurujesz OS, nie martwisz się o patche. Wdrażasz kod lub kontener - Azure robi resztę.

Idealny dla:

• Monolitycznych aplikacji .NET (Web API + frontend)
• Prostych mikroserwisów (do ~5-10 serwisów)
• Zespołów bez doświadczenia z Kubernetes
• Aplikacji z przewidywalnym ruchem
• MVP i pierwszych faz migracji (lift-and-shift)

Ograniczenia:

• Maks. 30 instancji na App Service Plan (skalowanie horyzontalne)
• Brak kontroli nad OS i runtime poza tym co oferuje platforma
• Networking - VNet Integration działa, ale z ograniczeniami (brak inbound private endpoint w planach niższych niż Premium v3)
• Koszty rosną nieliniowo przy dużej skali

Typowa architektura .NET na App Service:

Internet → Application Gateway (WAF)
    → App Service (Web API)
        → Azure SQL Database
        → Azure Cache for Redis
        → Azure Service Bus
        → Azure Blob Storage

Koszt orientacyjny (produkcja, Poland Central):

AKS (Azure Kubernetes Service) - kiedy jest potrzebny

AKS to zarządzany Kubernetes. Control plane jest darmowy - płacisz za node’y (VM-ki) i dodatkowe usługi. Daje pełną kontrolę, ale wymaga wiedzy operacyjnej.

Idealny dla:

• Architektury mikroserwisowej (>10 serwisów)
• Aplikacji wymagających zaawansowanego skalowania (HPA, KEDA, node autoscaler)
• Zespołów z doświadczeniem Kubernetes
• Aplikacji wymagających wzorców sidecar (service mesh, observability)
• Migracji z on-premise Kubernetes lub Docker Swarm

Ograniczenia:

• Krzywa uczenia się - Kubernetes to złożony system
• Overhead operacyjny - upgrades, node pool management, networking (CNI)
• Minimalna sensowna konfiguracja produkcyjna kosztuje więcej niż App Service
• Potrzebujesz inżyniera, który rozumie K8s na poziomie operacyjnym

Typowa architektura .NET na AKS:

Internet → Azure Front Door (WAF + CDN)
    → AKS Ingress Controller (NGINX lub AGIC)
        → Pod: Web API (.NET 8)
        → Pod: Background Worker
        → Pod: gRPC Service
    → Azure SQL Database (Private Endpoint)
    → Azure Service Bus
    → Azure Key Vault (CSI Secret Store)

Koszt orientacyjny (produkcja, Poland Central, 3 node cluster):

Matryca decyzyjna

Nasza rekomendacja: Jeśli nie masz mocnego powodu, żeby użyć AKS - zacznij od App Service. Migracja z App Service do AKS jest prostsza niż próba nauki Kubernetes w trakcie migracji produkcji. AKS dodaj, gdy App Service stanie się ograniczeniem (>10 serwisów, potrzeba service mesh, skomplikowane skalowanie).

Proces migracji krok po kroku

Faza 1: Ocena gotowości (1-2 tygodnie)

Zanim cokolwiek przeniesiesz, musisz wiedzieć co masz:

Inwentaryzacja:

• Lista aplikacji i ich zależności (bazy danych, kolejki, cache, pliki)
• Wersje .NET Framework vs .NET Core/.NET 8 (krytyczne - .NET Framework wymaga Windows containers lub App Service Windows)
• Wymagania dotyczące latency (czy aplikacja musi być blisko użytkowników w Polsce?)
• Obecne wzorce ruchu (peak hours, sezonowość)
• Zależności od usług on-premise (AD DS, file shares, legacy APIs)

Narzędzia do oceny:

• Azure Migrate - discovery agent instalowany on-premise, skanuje VM-ki, mapuje zależności, sugeruje sizing w Azure
• Azure App Service Migration Assistant - sprawdza kompatybilność aplikacji IIS/.NET z App Service
• .NET Upgrade Assistant - ocenia nakład pracy przy migracji z .NET Framework do .NET 8

Rezultat fazy oceny:

• Decyzja: App Service vs AKS (dla każdej aplikacji osobno)
• Strategia migracji: lift-and-shift vs re-platform vs re-architect
• Wstępny budżet Azure (miesięczny koszt docelowy)
• Lista blokerów (np. aplikacja wymaga .NET Framework 4.5 + API specyficznych dla Windows)

Faza 2: Landing Zone Setup (1-2 tygodnie)

Terraformem lub Bicepem - nie ręcznie. Infrastruktura musi być powtarzalna.

Minimum do uruchomienia:

# Terraform - przykład struktury modułów
module "management_groups" {
  source = "./modules/management-groups"
}

module "connectivity" {
  source              = "./modules/connectivity"
  hub_address_space   = "10.0.0.0/16"
  dns_servers         = ["10.0.3.4"]
  vpn_gateway_sku     = "VpnGw1"
  location            = "polandcentral"
}

module "workload_prod" {
  source              = "./modules/spoke"
  spoke_address_space = "10.1.0.0/16"
  hub_vnet_id         = module.connectivity.hub_vnet_id
  environment         = "prod"
  location            = "polandcentral"
}

Checklist Landing Zone:

• ☐ Management Groups i subskrypcje utworzone
• ☐ Hub VNet z DNS skonfigurowany
• ☐ Spoke VNets z peeringiem do huba
• ☐ Azure Policy przypisane (allowed locations = polandcentral, westeurope)
• ☐ Log Analytics Workspace centralny
• ☐ Key Vault dla każdego środowiska
• ☐ RBAC - role assignments dla zespołów
• ☐ Budget alerts ($X/miesiąc na subskrypcję)
• ☐ Microsoft Defender for Cloud włączony (przynajmniej Free tier)

Faza 3: Migracja bazy danych (1-3 tygodnie)

Baza danych migrujemy w pierwszej kolejności - to najbardziej ryzykowny element i wymaga najwięcej testów.

SQL Server → Azure SQL Database:

Najczęstsza ścieżka migracji dla aplikacji .NET. Azure SQL Database to w pełni zarządzany PaaS - backupy, patche, HA (99.99% SLA) obsługiwane przez Azure.

Kroki:

1. Compatibility check - Azure SQL Database nie obsługuje 100% funkcjonalności SQL Server (brak SQL Agent, brak cross-database queries, brak linked servers). Użyj Data Migration Assistant do identyfikacji problemów.
2. Wybór modelu - DTU (prosty, przewidywalny koszt) vs vCore (elastyczny, Azure Hybrid Benefit). Dla migracji zacznij od DTU S2/S3, potem optymalizuj.
3. Migracja danych - Azure Database Migration Service (DMS) dla online migration (minimal downtime) lub bacpac export/import dla offline.
4. Private Endpoint - baza dostępna tylko z VNet, nie z publicznego internetu.
5. Connection string update - zmiana w aplikacji z Server=on-prem-sql na Server=tcp:mydb.database.windows.net,1433.

# Przykład - migracja online przez DMS (Azure CLI)
az dms project task create \
  --resource-group rg-migration \
  --service-name dms-prod \
  --project-name sql-migration \
  --task-name migrate-appdb \
  --source-connection-json '{
    "dataSource": "10.0.1.50",
    "authentication": "SqlAuthentication",
    "userName": "migration_user",
    "password": "***"
  }' \
  --target-connection-json '{
    "dataSource": "appdb-prod.database.windows.net",
    "authentication": "SqlAuthentication",
    "userName": "sqladmin",
    "password": "***"
  }' \
  --database-options-json '[{
    "name": "AppDatabase",
    "targetDatabaseName": "AppDatabase"
  }]'

Ważne dla polskich firm: Jeśli masz licencje SQL Server Enterprise z SA - użyj modelu vCore z Azure Hybrid Benefit. Oszczędność sięga 55% vs pełna cena.

Faza 4: Deploy aplikacji (1-2 tygodnie)

Ścieżka App Service

Dla aplikacji .NET 8 na Linuxie (zalecane):

# 1. Utwórz App Service Plan
az appservice plan create \
  --name asp-app-prod \
  --resource-group rg-app-prod \
  --sku P1v3 \
  --is-linux \
  --location polandcentral

# 2. Utwórz Web App
az webapp create \
  --name app-myapi-prod \
  --resource-group rg-app-prod \
  --plan asp-app-prod \
  --runtime "DOTNETCORE:8.0"

# 3. Skonfiguruj VNet Integration
az webapp vnet-integration add \
  --name app-myapi-prod \
  --resource-group rg-app-prod \
  --vnet spoke-prod-vnet \
  --subnet app-subnet

# 4. Ustaw connection string (z Key Vault reference)
az webapp config appsettings set \
  --name app-myapi-prod \
  --resource-group rg-app-prod \
  --settings "ConnectionStrings__Default=@Microsoft.KeyVault(VaultName=kv-app-prod;SecretName=sql-connection-string)"

Kluczowe konfiguracje produkcyjne:

• Always On = true - zapobiega zimnym startowi po 20 min bezczynności
• Health Check - endpoint /health sprawdzany co 30 sekund, niezdatne instancje usuwane z load balancera
• Deployment Slots - staging slot do blue-green deployment (swap bez downtime)
• Managed Identity - tożsamość zarządzana do dostępu do Key Vault, SQL i Storage bez haseł w ciągach połączeniowych

Ścieżka AKS

Dla architektury mikroserwisowej:

# Kubernetes deployment - .NET 8 API
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-orders
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-orders
  template:
    metadata:
      labels:
        app: api-orders
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: sa-api-orders
      containers:
      - name: api
        image: acrmyapp.azurecr.io/api-orders:1.2.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        env:
        - name: ASPNETCORE_ENVIRONMENT
          value: "Production"
        - name: ConnectionStrings__Default
          valueFrom:
            secretKeyRef:
              name: sql-connection
              key: connection-string
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 10
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5

Kluczowe elementy AKS dla .NET:

• Workload Identity - tożsamość zarządzana dla podów (zamiast statycznych sekretów). Konfiguracja przez federated credentials w Entra ID.
• KEDA - skalowanie podów na podstawie metryk zewnętrznych (długość kolejki Service Bus, liczba wiadomości w Event Hub)
• Azure CNI Overlay - networking dla dużych klastrów bez wyczerpywania adresów IP w subnecie
• Azure Key Vault CSI Driver - montowanie sekretów z Key Vault bezpośrednio jako volume w podach

CI/CD - automatyzacja wdrożeń

Migracja bez CI/CD to przepisywanie się na ręczne wdrożenia w nowym środowisku. Pipeline powinien być gotowy równolegle z infrastrukturą.

Dla App Service (GitHub Actions):

name: Deploy to App Service
on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - uses: actions/setup-dotnet@v4
      with:
        dotnet-version: '8.0.x'

    - run: dotnet publish -c Release -o ./publish

    - uses: azure/login@v2
      with:
        client-id: $
        tenant-id: $
        subscription-id: $

    - uses: azure/webapps-deploy@v3
      with:
        app-name: app-myapi-prod
        slot-name: staging
        package: ./publish

    - name: Swap slots
      run: |
        az webapp deployment slot swap \
          --name app-myapi-prod \
          --resource-group rg-app-prod \
          --slot staging \
          --target-slot production

Dla AKS (GitHub Actions + ArgoCD):

W ekosystemie Kubernetes preferujemy GitOps z ArgoCD - pipeline buduje obraz i pushuje go do ACR, ArgoCD synchronizuje manifest z repozytorium do klastra. Szczegóły opisaliśmy w artykule o Azure DevOps vs GitHub Actions.

Typowe błędy przy migracji do Azure

Na podstawie projektów migracyjnych, które realizowaliśmy - lista najczęstszych problemów:

1. Brak Landing Zone - “wrzucimy to do jednej subskrypcji”

Skutek: po 6 miesiącach nikt nie wie kto za co płaci, kto ma jakie uprawnienia, a networking to flat network bez segmentacji. Cofanie się z tego stanu kosztuje 2-3× więcej niż zrobienie tego dobrze od początku.

2. Wybór zbyt dużego SKU “na wszelki wypadek”

Zespoły przyzwyczajone do on-premise kupują D8s_v5 (8 vCPU, 32 GB) dla aplikacji, która potrzebuje 500 MB RAM. W chmurze zaczynasz od małego i skalujesz w górę. App Service P1v3 z autoscalingiem to lepszy wybór niż P3v3 na stałe.

3. Ignorowanie egress costs

Ruch wychodzący z Azure kosztuje ~$0.087/GB (do internetu). Jeśli aplikacja generuje dużo ruchu outbound (np. integracje z API zewnętrznymi, backup do zewnętrznego storage) - koszty egress mogą zaskoczyć. Private Endpoints eliminują ten koszt dla komunikacji między usługami Azure w tym samym regionie.

4. .NET Framework na Linuxie

App Service na Linuxie obsługuje tylko .NET Core/.NET 5+. Jeśli aplikacja jest na .NET Framework 4.x - potrzebujesz Windows App Service Plan (droższy) lub kontenerów Windows (wolniejszy start na zimno, mniej opcji skalowania). Rozważ upgrade do .NET 8 przed migracją - to inwestycja, która się zwraca.

5. Brak Private Endpoints

Domyślnie Azure SQL Database, Storage Account i inne usługi PaaS są dostępne z publicznego internetu. Wystarczy reguła firewalla z dozwolonymi adresami IP, ale to nie jest Zero Trust. Private Endpoint umieszcza usługę w Twoim VNet z prywatnym adresem IP - jedynym sposobem na dostęp jest bycie w sieci wirtualnej.

6. Ręczne wdrożenia po migracji

“Na razie wdrażamy ręcznie, CI/CD zrobimy później”. Później nigdy nie przychodzi. Automatyzacja wdrożeń to nie luksus - to higiena operacyjna. Swap slots w App Service + GitHub Actions to konfiguracja na 2 godziny.

Harmonogram i koszty typowej migracji

Co wpływa na koszt:

• Liczba aplikacji do przeniesienia (każda dodatkowa +20-40% czasu)
• Stan kodu źródłowego (.NET Framework vs .NET 8)
• Złożoność integracji (ile systemów zewnętrznych?)
• Wymagania compliance (KNF, UODO - dodatkowa dokumentacja i konfiguracja)
• Czy Landing Zone już istnieje, czy budujemy od zera

Dofinansowanie: Program Microsoft Azure Migrate and Modernize oferuje kredyty Azure na pierwsze 6 miesięcy po migracji. Wartość zależy od skali przenoszonej infrastruktury - typowo $10,000-$50,000 w kredytach.

Jak możemy pomóc

W Devopsity specjalizujemy się w migracjach do Azure dla polskich firm. Typowe zaangażowanie:

• Assessment (1-2 dni) - analiza obecnej infrastruktury, rekomendacja App Service vs AKS, wstępny kosztorys Azure
• Landing Zone (1-2 tygodnie) - setup Terraform, networking, governance, RBAC
• Migracja (2-6 tygodni) - baza danych, aplikacja, CI/CD, cutover
• Optymalizacja (ongoing) - right-sizing, Reserved Instances, monitoring kosztów

Jeśli planujesz migrację .NET do Azure - porozmawiajmy o Twoim przypadku. Bez zobowiązań, bez pitchu sprzedażowego.

Planujesz migrację do Azure?

Umów się na bezpłatną 30-minutową konsultację techniczną. Omówimy Twoją infrastrukturę i najlepszą ścieżkę migracji.

Umów rozmowę

Najczęściej zadawane pytania

Czy mogę migrować aplikację .NET Framework 4.x do Azure bez przepisywania na .NET 8?

Tak. App Service Windows obsługuje .NET Framework 4.x natywnie. Alternatywnie - kontener Windows na AKS. Ale długoterminowo warto zaplanować upgrade do .NET 8: lepsza wydajność, wsparcie Linuxa (tańsze plany), aktywny rozwój frameworka.

Jak długo trwa migracja jednej aplikacji .NET do Azure?

Minimum 4-5 tygodni (prosta aplikacja + SQL na App Service). Typowo 6-10 tygodni dla średniej złożoności. Migracja do AKS z pełnym Landing Zone - 10-14 tygodni. Największy wpływ na czas ma stan bazy danych i liczba integracji.

Ile kosztuje Azure miesięcznie po migracji?

Dla typowej aplikacji .NET (API + frontend + SQL + cache): $400-$800/miesiąc na App Service, $600-$1200/miesiąc na AKS. Z Azure Hybrid Benefit (istniejące licencje Windows/SQL) - 30-55% taniej.

Czy region Poland Central jest droższy niż West Europe?

Minimalnie (~5-10% droższy na niektórych usługach). Ale jeśli użytkownicy są w Polsce - niższe latency > niewielka różnica w cenie. Dla wymagań KNF/UODO dotyczących rezydencji danych - Poland Central to jedyna opcja.

Czy potrzebuję Azure Firewall?

Nie zawsze. Dla małych deploymentów (1-2 aplikacje) wystarczą NSG + UDR. Azure Firewall dodaj, gdy masz wymagania na centralną inspekcję ruchu egress, logowanie całego ruchu sieciowego, lub compliance wymaga L7 firewalla.