IaaS, PaaS und SaaS im direkten Vergleich

IaaS liefert virtuelle Infrastruktur, PaaS eine verwaltete Laufzeitumgebung und SaaS eine fertige Anwendung. Mit jeder Stufe übernimmt der Anbieter typischerweise mehr Betrieb. Daten, Identitäten, Konfiguration und der Exit bleiben jedoch nie automatisch erledigt. Entscheidend sind der konkrete Dienst, der Vertrag und das eigene Betriebsmodell.

Die Kürzel beschreiben Fähigkeiten, keinen vollständigen Vertrag

Die NIST-Definition ordnet Cloud-Dienste nach der Fähigkeit, die ein Kunde nutzen kann. IaaS stellt grundlegende Rechenressourcen bereit. PaaS bietet eine Umgebung für eigene Anwendungen. SaaS liefert eine Anwendung zur direkten Nutzung.

Diese Einteilung ist nützlich, aber nicht fein genug für eine Betriebsfreigabe. Zwei Dienste derselben Kategorie können Updates, Netzwerkzugriff, Sicherungen, Schlüsselverwaltung und Support verschieden verteilen. Das Servicemodell ist der Anfang der Prüfung, nicht ihr Ergebnis.

Viele reale Systeme mischen die Modelle:

• eine virtuelle Maschine betreibt eigenen Anwendungscode;
• die Datenbank läuft als verwalteter Plattformdienst;
• Identität und Zusammenarbeit kommen aus einer fertigen Anwendung;
• Sicherung, Überwachung und DNS werden separat beschafft.

Wer nur eine Schichtenpyramide zeichnet, übersieht diese Schnittstellen. Dort entstehen die offenen Aufgaben: Zugang, Konfiguration, Wiederherstellung, Datenfluss und Eskalation.

IaaS, PaaS und SaaS in einer Entscheidungsmatrix

Die folgende Matrix zeigt typische Zuständigkeiten. Sie ersetzt keine Produktdokumentation. Ein verwalteter Dienst innerhalb eines IaaS-Kontos kann beispielsweise mehr Aufgaben übernehmen als die Kategorie erwarten lässt.

Mehr Abstraktion tauscht Betriebsarbeit gegen Vertrags- und Produktabhängigkeit. Das kann wirtschaftlich sinnvoll sein. Es muss nur als bewusster Tausch im Budget stehen.

IaaS gibt Kontrolle und überlässt den Gastbetrieb

Bei Infrastructure as a Service stellt der Anbieter Rechenleistung, Speicher, Netzwerke und Virtualisierung bereit. Der Kunde installiert und betreibt typischerweise das Gastbetriebssystem und die Anwendungen. Er konfiguriert Zugänge, Firewall-Regeln, Verschlüsselung, Überwachung und Wiederherstellung innerhalb seines Bereichs.

Das offizielle AWS-Modell nennt für eine IaaS-Instanz insbesondere Gastbetriebssystem, Sicherheitsupdates, Anwendungssoftware und die Konfiguration der bereitgestellten Firewall als Kundenaufgaben. Der Anbieter schützt die zugrunde liegende Infrastruktur, den Host und die Virtualisierung.

IaaS passt, wenn eine Anwendung besondere Systempakete, Netzwerkregeln oder eine eigene Laufzeit verlangt. Es passt auch, wenn bestehende Serverprozesse zunächst mit wenig Umbau in die Cloud verschoben werden sollen.

IaaS passt schlecht, wenn niemand folgende Arbeit übernimmt:

• Betriebssystem und Pakete zeitnah aktualisieren;
• Protokolle, Kapazität und Ausfälle überwachen;
• Sicherungen ausserhalb der Instanz erstellen;
• Wiederherstellung auf einer neuen Ressource testen;
• Zugänge und Schlüssel regelmässig prüfen.

Ein Snapshot ist noch kein vollständiger Notfallplan. Er kann vom selben Konto, derselben Region oder demselben Bedienfehler abhängen. Kontrolle ist nur wertvoll, wenn jemand sie tatsächlich ausübt.

PaaS entfernt Serverarbeit, nicht Anwendungsbetrieb

Platform as a Service gibt einer Entwicklungsmannschaft eine unterstützte Laufzeit, in der sie eigenen Code bereitstellt. Der Anbieter betreibt normalerweise Betriebssystem, Laufzeit und Teile der Plattform. Das Team bleibt für Anwendung, Daten, Abhängigkeiten, Geheimnisse, Berechtigungen und fachliche Fehler verantwortlich.

PaaS eignet sich, wenn das Produktteam schnell bereitstellen will und auf tiefe Kontrolle des Betriebssystems verzichten kann. Automatische Skalierung oder verwaltete Laufzeiten können Arbeit reduzieren. Sie beweisen jedoch weder passende Grenzwerte noch eine funktionierende Wiederherstellung.

Die Plattform entscheidet, welche Laufzeiten, Versionen, Build-Verfahren, Netzwerkwege und Erweiterungen verfügbar sind. Eine Änderung des Anbieters kann daher Codeanpassungen, neue Bereitstellungsabläufe und einen Ersatz für Datenbank, Warteschlange, Speicher oder Identitätsdienst verlangen.

PaaS verschiebt die Betriebsgrenze nach oben. Oberhalb dieser Grenze bleiben Tests, sichere Konfiguration, Datenmodell, Fehlerbehandlung und Beobachtbarkeit beim Kunden. Unterhalb der Grenze braucht es belastbare Aussagen des Anbieters zu Wartung und Verfügbarkeit.

PaaS passt schlecht, wenn die Anwendung nicht unterstützte Systemfunktionen benötigt oder eine proprietäre Plattformfunktion zum zentralen Geschäftsprozess würde. Dann müssen Nutzen und späterer Ersatz gemeinsam bewertet werden.

SaaS liefert eine Anwendung, aber keine ausgelagerte Verantwortung

Software as a Service stellt eine fertige Anwendung bereit. Der Anbieter betreibt Anwendung und Plattform. Der Kunde verwaltet normalerweise Benutzer, Rollen, Inhalte, Aufbewahrung, Freigaben, Einstellungen und die Anbindung an andere Systeme.

Microsoft ordnet Kundendaten, Identitäten, Benutzer sowie Konfigurationen auch bei SaaS dem Kunden zu. Der Anbieter kann technische Schutzfunktionen liefern. Er entscheidet aber nicht, wer im Unternehmen Zugriff erhalten soll oder welche Daten in die Anwendung gehören.

SaaS eignet sich für standardisierte Prozesse, bei denen eigene Entwicklung keinen ausreichenden Vorteil bringt. Der Nutzen entsteht aus schneller Einführung, zentralem Betrieb und klarer Produktverantwortung des Anbieters.

SaaS passt schlecht, wenn ein kritischer Prozess eine nicht verfügbare Anpassung benötigt oder Datenbeziehungen nicht vollständig exportiert werden können. Prüfen Sie auch, was nach Vertragsende mit Konten, Protokollen, Sicherungen und Integrationen geschieht.

Bequem im Alltag kann teuer beim Austritt sein. Eine CSV-Datei mit Stammdaten ersetzt keine Historie, Berechtigungslogik oder funktionsfähige Schnittstelle.

Gemeinsame Verantwortung endet nicht bei der Sicherheitsgrafik

Das Modell der gemeinsamen Verantwortung trennt Aufgaben des Anbieters von Aufgaben des Kunden. Es ist kein Freibrief für Lücken zwischen beiden Seiten. Jede Aufgabe braucht einen Namen, einen Kontrollnachweis und einen Eskalationsweg.

Unabhängig vom Modell bleiben typischerweise beim Kunden:

• Klassifikation und zulässige Nutzung der Daten;
• Verwaltung von Identitäten und Berechtigungen;
• Schutz der zugreifenden Endgeräte;
• Auswahl und Konfiguration der genutzten Funktionen;
• Kontrolle von Export, Löschung und Wiederherstellung;
• Bewertung der eigenen rechtlichen und vertraglichen Pflichten.

Verwaltet bedeutet ebenfalls nicht automatisch gesichert. Ein PaaS-Anbieter kann die Laufzeit patchen, während der Kunde eine verwundbare Bibliothek im Anwendungspaket belässt. Ein SaaS-Anbieter kann Mehrfaktor-Anmeldung anbieten, während der Kunde sie nicht erzwingt.

Fordern Sie deshalb keine bunte Grafik, sondern eine schriftliche Zuordnung. Für jede kritische Komponente sollte klar sein, wer verhindert, erkennt, reagiert und wiederherstellt. Geteilte Verantwortung ohne Zuordnung wird geteiltes Schweigen im Störungsfall.

Portabilität besteht aus mehreren Umzügen

NIST unterscheidet Portabilität von Daten, Diensten und Systemen. Diese Unterscheidung verhindert die bequeme Annahme, eine virtuelle Maschine oder ein Container mache die gesamte Anwendung anbieterneutral.

Bei IaaS müssen neben einem Maschinenabbild auch Netzwerk, Identitäten, Schlüssel, Blockspeicher, DNS und Automatisierung neu aufgebaut werden. Anbieterspezifische Erweiterungen im Abbild oder in der Steuerung müssen dokumentiert und ersetzt werden.

Bei PaaS liegt die Bindung oft in Laufzeitannahmen und verwalteten Diensten. Code kann portabel aussehen, während Datenbankfunktionen, Ereignisdienste, Berechtigungen oder Bereitstellung eng an die Plattform gekoppelt sind.

Bei SaaS steht die Datenextraktion im Vordergrund. Prüfen Sie Format, Vollständigkeit, Beziehungen, Anhänge, Protokolle und Frist nach Vertragsende. Fragen Sie ausserdem, wie Integrationen und Benutzerzuordnungen in einem Zielsystem nachgebildet werden.

Exit ist Teil des Preises. Ein Ausstieg umfasst nicht nur Datentransfer, sondern auch Entwicklung, Tests, Parallelbetrieb, Schulung, Vertragsfristen und die kontrollierte Abschaltung des alten Dienstes.

Ein realistischer Exit-Test arbeitet mit einer Stichprobe. Exportieren Sie Daten und Konfiguration, bauen Sie einen begrenzten Zielpfad auf und dokumentieren Sie manuelle Schritte. Erst dann ist erkennbar, ob die Bindung akzeptiert oder reduziert werden sollte.

Die Kosten folgen der übernommenen Arbeit

IaaS wirkt auf der Rechnung oft transparent, lässt aber Personalaufwand für Betrieb, Bereitschaft, Patches und Wiederherstellung ausserhalb der Ressourcenpreise. PaaS berechnet möglicherweise Laufzeit, Aufrufe, Speicher und verwaltete Dienste getrennt. SaaS bündelt Betrieb, kann aber Benutzer, Speicher, Zusatzmodule und Support staffeln.

Vergleichen Sie daher nicht nur Monatsbeträge. Erfassen Sie diese Kostenblöcke über denselben Zeitraum:

• Grunddienst und nutzungsabhängige Ressourcen;
• Betrieb, Überwachung und Bereitschaft im eigenen Team;
• Sicherung, Wiederherstellung und Notfallübungen;
• Lizenzen, Zusatzmodule und Supportstufe;
• Datenübertragung, Parallelbetrieb und Anbieterwechsel.

Für ein Unternehmen in Deutschland oder Österreich ist eine Euro-Rechnung leichter planbar. Ein Schweizer KMU sollte in der eigenen Währung rechnen und mögliche Umrechnung sowie Steuerbehandlung im konkreten Vertrag prüfen. Eine günstige Ressource kann durch fremde Währung und manuelle Betriebsarbeit ihre Attraktivität verlieren.

Datenstandort und Servicemodell sind getrennte Entscheidungen

IaaS, PaaS und SaaS sagen nicht, in welchem Land Daten gespeichert, gesichert oder durch Support verarbeitet werden. Auch eine auswählbare Region beschreibt nicht automatisch alle Protokolle, Metadaten, Sicherungen und Unterauftragnehmer.

Datenstandort ist kein Sticker. Prüfen Sie Speicherort, Sicherungsort, Supportzugriff, Vertragspartei, Löschverfahren und Nachweise als einzelne Punkte. Daraus ergibt sich noch keine pauschale Rechtsbewertung, aber eine belastbare Grundlage für die interne Prüfung.

Bei AWS, Microsoft Azure oder einer IaaS-Basis von Hetzner müssen Sie den konkreten Dienst untersuchen. Der Anbietername allein beantwortet weder Verantwortung noch Datenpfad oder Exit-Aufwand.

Die passende Wahl beginnt beim eigenen Team

Wählen Sie IaaS, wenn Sie Systemkontrolle benötigen und Betrieb zuverlässig besetzen können. Wählen Sie PaaS, wenn das Team Anwendungen entwickeln, aber Betriebssystem und Laufzeit abgeben will. Wählen Sie SaaS, wenn ein standardisierter Prozess wichtiger ist als eigene technische Gestaltung.

Die Modelle können bewusst kombiniert werden. Entscheidend ist, dass jede Grenze dokumentiert ist. Wenn eine Aufgabe weder beim Anbieter noch intern benannt ist, handelt es sich nicht um eingesparten Betrieb, sondern um ein offenes Risiko.