IaaS vs. PaaS vs. SaaS: Architekturentscheidungen im KMU treffen

Warum diese Entscheidung wichtiger ist, als sie aussieht

“Machen wir doch einfach eine VM in Azure” ist einer der teuersten Sätze, die in einem KMU-IT-Meeting fallen können. Nicht weil eine VM falsch wäre – sondern weil sie oft die Antwort auf die falsche Frage ist. Die Wahl zwischen IaaS, PaaS und SaaS ist keine reine Technikfrage, sondern eine Architektur- und Budgetentscheidung, die sich über Jahre auswirkt: auf den Patch-Aufwand deines Teams, auf die Total Cost of Ownership, auf die Abhängigkeit von einem einzigen Hersteller und darauf, wie schnell ihr bei einem Sicherheitsvorfall reagieren könnt.

In einem Schweizer KMU mit typischerweise ein bis drei IT-Verantwortlichen ist diese Entscheidung besonders heikel, weil jede Stunde Wartungsaufwand direkt von Projekten abgezogen wird, die eigentlich Mehrwert schaffen sollten. Dieser Artikel gibt dir das Handwerkszeug, um bei der nächsten Projektanfrage nicht aus dem Bauch heraus, sondern strukturiert zu entscheiden.

Das Shared-Responsibility-Modell im Detail

Das Shared-Responsibility-Modell (geteilte Verantwortung) ist das zentrale Konzept, um Cloud-Sicherheit und Betriebsverantwortung richtig zuzuordnen. Microsoft beschreibt es offiziell für Azure, aber das Prinzip gilt analog für AWS, Google Cloud und jeden SaaS-Anbieter: Je nach Servicemodell verschiebt sich die Grenze zwischen “das macht der Anbieter” und “das machst du”.

Wichtig: Egal welches Modell – die Verantwortung für Identitäten, Zugriffsrechte und Datenklassifizierung bleibt immer bei dir. Microsoft, AWS oder Google übernehmen niemals die Verantwortung dafür, dass du sinnvolle Berechtigungsgruppen pflegst oder MFA aktivierst. Das ist der Grund, warum in praktisch jedem Cloud-Sicherheitsvorfall die Ursache eine Fehlkonfiguration auf Kundenseite ist, nicht ein Leck beim Hyperscaler.

Die drei Modelle in der Praxis

IaaS – Infrastructure as a Service

Du mietest virtuelle Hardware: Rechenleistung, Storage, Netzwerk. Das Betriebssystem installierst, patchst und härtest du selbst. Beispiel: eine Azure VM mit Windows Server, auf der eine ERP-Applikation läuft, die der Hersteller nur “on Windows Server 2022” unterstützt.

Typische Azure-Dienste: Azure Virtual Machines, Azure Disks, Azure Virtual Network (VNet), Azure Load Balancer.

PaaS – Platform as a Service

Du lieferst nur noch den Code oder die Konfiguration, der Anbieter kümmert sich um Betriebssystem, Patching, Runtime und Skalierung. Beispiel: Eine interne Web-App wird als Azure App Service betrieben, die Datenbank läuft als Azure SQL Database (managed).

Typische Azure-Dienste: Azure App Service, Azure Functions, Azure SQL Database, Azure Container Apps, Azure Static Web Apps.

SaaS – Software as a Service

Du nutzt fertige Software über den Browser oder einen Client, ohne dich um Infrastruktur oder Plattform zu kümmern. Beispiel: Microsoft 365, eine Cloud-Buchhaltungslösung wie Abacus oder Bexio, ein Cloud-CRM.

Typische Beispiele: Microsoft 365, Dynamics 365, Salesforce, Bexio, Abacus my Cloud.

Azure VM vs. App Service vs. SaaS – der direkte Vergleich

Nehmen wir ein konkretes Szenario: Ein Schweizer KMU mit 40 Mitarbeitenden braucht eine interne Web-Applikation (z.B. ein Zeiterfassungstool oder ein internes Ticketsystem). Die Optionen:

Für unser Beispiel würde ich in den meisten Fällen zu App Service raten, sofern die Applikation intern entwickelt wird oder eine gängige Web-Technologie (Node.js, .NET, Python, PHP) nutzt. Nur wenn die Software zwingend spezifische OS-Konfigurationen, Treiber oder einen lokalen Windows-Dienst braucht, bleibt IaaS die richtige Wahl.

Eine App Service-Instanz per CLI aufsetzen

# Ressourcengruppe in der Schweiz erstellen
az group create --name rg-webapp-prod --location switzerlandnorth

# App Service Plan (Standard S1, Linux)
az appservice plan create `
  --name plan-webapp-prod `
  --resource-group rg-webapp-prod `
  --sku S1 `
  --is-linux

# Web App mit Node.js-Runtime erstellen
az webapp create `
  --name kmu-zeiterfassung `
  --resource-group rg-webapp-prod `
  --plan plan-webapp-prod `
  --runtime "NODE:20-lts"

# Deployment-Slot für Staging anlegen (nur ab Standard-Tier)
az webapp deployment slot create `
  --name kmu-zeiterfassung `
  --resource-group rg-webapp-prod `
  --slot staging

# Auto-Scale-Regel: Skalieren bei CPU über 70 Prozent
az monitor autoscale create `
  --resource-group rg-webapp-prod `
  --resource plan-webapp-prod `
  --resource-type Microsoft.Web/serverfarms `
  --name autoscale-webapp `
  --min-count 1 --max-count 3 --count 1

Zum Vergleich die IaaS-Variante mit einer VM – deutlich mehr Schritte, weil du selbst für Netzwerk, NSG und OS-Grundhärtung sorgen musst:

az group create --name rg-vm-prod --location switzerlandnorth

az vm create `
  --resource-group rg-vm-prod `
  --name vm-app01 `
  --image Win2022Datacenter `
  --size Standard_D2s_v5 `
  --admin-username kmuadmin `
  --admin-password (Read-Host -AsSecureString) `
  --nsg-rule RDP

# NSG-Regel: RDP nur aus dem Firmennetz erlauben, nicht aus dem Internet
az network nsg rule create `
  --resource-group rg-vm-prod `
  --nsg-name vm-app01NSG `
  --name Allow-RDP-Firmennetz `
  --priority 100 `
  --source-address-prefixes "203.0.113.0/24" `
  --destination-port-ranges 3389 `
  --access Allow --protocol Tcp

Kostenvergleich: TCO statt nur Listenpreis

Der grösste Fehler beim Kostenvergleich ist, nur die Rechnung des Cloud-Anbieters anzuschauen. Die Total Cost of Ownership (TCO) muss auch die Arbeitszeit deines Teams, Ausfallrisiken und Opportunitätskosten einrechnen.

TCO-Bausteine für einen realistischen Vergleich

Als grobe Praxisregel für ein KMU mit 1-2 IT-Vollzeitstellen: Rechne bei einer selbst verwalteten VM mit 10-15 Personentagen pro Jahr allein für Patch-Management, Backup-Kontrolle und Incident-Reaktion – pro Server. Bei fünf VMs sind das schnell 50-75 Personentage, also fast eine Vollzeitstelle nur für Basis-Betrieb. Das ist der eigentliche Grund, warum viele Schweizer KMU in den letzten Jahren konsequent von IaaS Richtung PaaS und SaaS migriert sind.

Wartungsaufwand und Patch-Verantwortung

Die Patch-Verantwortung ist einer der unterschätzten Kostentreiber. Bei IaaS bist du für den kompletten Patch-Zyklus zuständig:

1. Patch-Verfügbarkeit prüfen (Windows Update, Linux-Paketmanager)
2. Testen in einer Staging-Umgebung
3. Wartungsfenster kommunizieren
4. Patch einspielen, Reboot planen
5. Funktionstest nach dem Patch
6. Rollback-Plan bereithalten, falls etwas schiefgeht

Bei PaaS übernimmt Microsoft die Schritte 1, 2 (Plattform-seitig) und 4 automatisch für Betriebssystem und Runtime. Du bist nur noch für deinen eigenen Applikationscode und dessen Abhängigkeiten (z.B. NuGet- oder npm-Pakete) verantwortlich. Bei SaaS entfällt der gesamte Prozess für dich komplett – der Anbieter patcht im Hintergrund, oft ohne dass du es merkst.

# Beispiel: Azure Update Manager Wartungsfenster für IaaS-VMs (ARM/Bicep-Auszug)
maintenanceConfiguration:
  name: "mw-patch-sonntagnacht"
  properties:
    maintenanceScope: InGuestPatch
    installPatches:
      linuxParameters:
        classificationsToInclude: ["Critical", "Security"]
      windowsParameters:
        classificationsToInclude: ["Critical", "Security", "UpdateRollUp"]
      rebootSetting: IfRequired
    window:
      startDateTime: "2026-07-13 02:00"
      duration: "03:00"
      recurEvery: "1Week Sunday"
      timeZone: "W. Europe Standard Time"

Vendor-Lock-in-Risiken realistisch einschätzen

Vendor-Lock-in wird oft als Totschlagargument gegen PaaS und SaaS verwendet (“dann sind wir für immer an Microsoft gebunden”). Das stimmt nur bedingt – jedes Modell hat sein eigenes Lock-in-Profil:

• IaaS: Niedrigstes Lock-in-Risiko auf Infrastrukturebene. Eine VM mit Windows Server oder Linux lässt sich als Image exportieren und bei einem anderen Anbieter (AWS, Google Cloud, On-Premises Hyper-V) wieder hochfahren. Das Lock-in entsteht eher durch Zusatzdienste wie Azure-spezifische Storage-Integrationen.
• PaaS: Mittleres Risiko. Code, der gegen Azure-spezifische SDKs entwickelt wurde (z.B. direkte Azure Functions Trigger, Azure-spezifische Storage-Bindings), lässt sich nicht 1:1 zu AWS Lambda oder Google Cloud Functions portieren. Mit sauberer Abstraktion (z.B. über Interfaces, Dependency Injection) lässt sich das Risiko deutlich senken.
• SaaS: Höchstes Risiko. Deine Daten liegen in einem proprietären Format, ein Wechsel bedeutet oft Datenmigration mit Qualitätsverlust, und Prozesse sind an die Eigenheiten der Software gewachsen. Frag bei jeder SaaS-Beschaffung explizit nach Exportmöglichkeiten (CSV, API, Standard-Formate).

Ein pragmatischer Ansatz, um Lock-in zu reduzieren, ohne auf die Vorteile von PaaS/SaaS zu verzichten: Setze auf offene Standards wo möglich (SQL statt proprietäre NoSQL-APIs, REST statt Azure-exklusive SDKs), dokumentiere Exit-Strategien pro kritischem System, und vermeide es, geschäftskritische Individuallogik tief in eine einzelne SaaS-Plattform zu bauen, die schwer zu ersetzen ist.

Entscheidungsbaum für neue Projekte

Wenn eine neue Anforderung reinkommt – “wir brauchen eine Lösung für X” – hilft dieser strukturierte Ablauf:

1. Gibt es eine etablierte SaaS-Lösung für diesen Anwendungsfall?
   ├── JA, und Compliance/Datenschutz sind unkritisch oder abgedeckt
   │   └── → SaaS wählen (schnellster Weg, geringster Betriebsaufwand)
   │
   └── NEIN oder SaaS deckt Kernanforderung nicht ab
       │
       2. Kann die Anwendung mit Standard-Runtimes (Node, .NET, Python, Java) laufen,
          ohne tiefen OS-Zugriff oder Spezialtreiber?
       ├── JA
       │   └── → PaaS wählen (Azure App Service, Functions, Container Apps)
       │
       └── NEIN (braucht z.B. lokalen Windows-Dienst, spezielle Treiber,
                  Legacy-Software mit fixen OS-Anforderungen)
           └── → IaaS wählen (Azure VM), aber:
                 - Patch-Prozess von Anfang an einplanen (Azure Update Manager)
                 - NSG-Regeln minimal halten (Zero Trust-Prinzip)
                 - Backup und Monitoring sofort mit einrichten, nicht "später"

Zusätzliche Prüffragen, die in die Entscheidung einfliessen sollten:

1. Wie kritisch ist die Verfügbarkeit? Bei Hochverfügbarkeitsanforderungen ist PaaS mit eingebautem Load Balancing oft einfacher zu realisieren als eine selbst gebaute IaaS-HA-Lösung.
2. Wie viel internes Know-how existiert bereits? Ein Team mit starkem Windows-Server-Hintergrund tut sich mit IaaS leichter, ein Team mit Entwicklungs-Hintergrund profitiert stärker von PaaS.
3. Wie sieht die Datenresidenz-Anforderung aus? Für Schweizer KMU mit Bezug zum revDSG/nDSG ist wichtig, dass Daten in Switzerland North/Switzerland West bleiben – das ist bei allen drei Modellen konfigurierbar, muss aber explizit geprüft werden.
4. Wie lange soll die Lösung im Einsatz bleiben? Bei kurzlebigen Projekten (Proof of Concept, befristete Kampagne) ist der geringere Lock-in von IaaS/Container-basierten Lösungen manchmal vorteilhafter als eine tiefe SaaS-Integration.

Migrationsszenario: Von IaaS zu PaaS

Ein häufiges Praxisszenario: Ihr habt eine bestehende Applikation auf einer Azure VM laufen und wollt Richtung PaaS migrieren, um Wartungsaufwand zu senken. Grober Ablauf:

# 1. Bestandsaufnahme: Welche Abhängigkeiten hat die App vom OS?
#    (lokale Dateisysteme, Registry, installierte Dienste, feste IP-Bindungen)

# 2. App Service Migration Assistant nutzen (kostenloses Microsoft-Tool)
#    Läuft direkt auf der Quell-VM und analysiert Kompatibilität

# 3. Testmigration in eine Staging-Umgebung
az webapp create --name kmu-app-staging --resource-group rg-migration --plan plan-migration

# 4. Konfiguration und Connection Strings anpassen
az webapp config appsettings set `
  --name kmu-app-staging `
  --resource-group rg-migration `
  --settings ConnectionStrings__Default="Server=tcp:kmu-sql.database.windows.net;..."

# 5. DNS erst nach erfolgreichem Funktionstest umstellen (Slot-Swap oder CNAME)
az webapp deployment slot swap `
  --name kmu-app-staging `
  --resource-group rg-migration `
  --slot staging --target-slot production

Sicherheitsaspekte je nach Modell

Die Angriffsfläche verschiebt sich mit dem Servicemodell, verschwindet aber nie ganz:

• Bei IaaS bist du für OS-Härtung, Endpoint-Schutz, Firewall-Regeln und Patch-Level verantwortlich. Ein ungepatchter Windows Server mit offenem RDP ist nach wie vor eines der häufigsten Einfallstore.
• Bei PaaS verschiebt sich der Fokus auf Applikationssicherheit: sichere Authentifizierung (Entra ID Integration statt eigener Login-Logik), Input-Validierung, sichere Verwaltung von Secrets über Azure Key Vault statt Klartext in App Settings.
• Bei SaaS liegt der Fokus fast vollständig auf Identität und Zugriffssteuerung: Wer hat Zugriff auf welche Daten, ist MFA erzwungen, sind Freigabelinks korrekt eingeschränkt. Ein Blick in M365 Purview Compliance lohnt sich hier.

Fallstricke aus der Praxis

• “Lift and Shift” ohne Anpassung: Eine VM 1:1 von On-Premises nach Azure zu heben, ohne die Architektur zu überdenken, verschenkt fast das gesamte Kostenoptimierungspotenzial der Cloud.
• App Service Plan mit zu vielen Apps überladen: Mehrere ressourcenhungrige Apps auf einem einzigen Basic-Plan führen zu gegenseitigen Performance-Problemen. Ab einer gewissen Last gehört jede kritische App auf einen eigenen Plan.
• SaaS-Wildwuchs (“Schatten-IT”): Wenn Fachabteilungen eigenständig SaaS-Tools abonnieren (Kreditkarte, kein IT-Review), entstehen unkontrollierte Datenabflüsse und Lizenzkosten-Chaos. Ein Cloud-App-Discovery-Prozess gehört in jede IT-Governance.
• Fehlende Kostenkontrolle: Ohne Budget-Alerts und Auto-Shutdown-Regeln für Test-VMs laufen Kosten schnell aus dem Ruder – besonders bei GPU- oder Premium-SKUs.
• Backup vergessen: Bei PaaS und SaaS verlässt man sich oft fälschlicherweise darauf, dass “die Cloud ja schon Backups macht”. Azure SQL Database hat automatische Backups, aber die Aufbewahrungsdauer und Wiederherstellungsoptionen musst du aktiv konfigurieren. Mehr dazu unter Backup-Strategie 3-2-1-Regel.

Weiterlernen

• Shared responsibility in the cloud – Microsoft Learn
• Azure App Service Overview – Microsoft Learn
• Azure-Preisrechner
• Azure Update Manager Overview – Microsoft Learn
• App Service Migration Assistant – Microsoft Learn
• IaaS vs. PaaS vs. SaaS – Red Hat

Videos

YouTube