Typische Cloud Services im Enterprise-Überblick: IaaS, PaaS, SaaS, CaaS und FaaS

Die systematische Einteilung von Cloud-Diensten nach Servicemodellen bildet das grundlegende Ordnungsraster der betrieblichen IT-Architektur. Was in den Anfängen der Cloud-Ära als pragmatische Dreiteilung in Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS) begann, hat sich zu einem vielschichtigen Kontinuum spezialisierter Bereitstellungsformen entwickelt.

Für IT-Führungskräfte und Chefarchitekten im gehobenen Mittelstand sowie im regulierten Sektor geht die Relevanz dieser Einteilung weit über technische Begriffsdefinitionen hinaus. Jedes Servicemodell markiert eine präzise Grenzlinie im Verantwortungsgefüge zwischen Auftraggeber und externem Cloud-Anbieter.

Je höher die gewählte Abstraktionsebene ausfällt, desto mehr operative Routineaufgaben lassen sich an den Plattformbetreiber delegieren. Gleichzeitig steigen jedoch die Bindung an proprietäre Schnittstellen, das Risiko unkalkulierbarer Preissprünge und der Verlust technischer Handlungsautonomie.

Wer typische Cloud Services wirtschaftlich und rechtssicher steuern will, muss die architektonischen Eigenheiten jedes Bereitstellungsmodells bis ins Detail verstehen. Dieser Leitfaden dekonstruiert die fünf maßgeblichen Servicemodelle IaaS, CaaS, PaaS, FaaS und SaaS und analysiert deren Konsequenzen für Total Cost of Ownership und Portabilität.

Das Shared Responsibility Model: Dekonstruktion der Kontrollgrenzen im Rechenzentrum

Das Modell der geteilten Verantwortung (Shared Responsibility) bildet das vertragliche und betriebliche Fundament jeder Cloud-Nutzung. Es regelt exakt, welche Sicherheitsschichten in den Zuständigkeitsbereich des Anbieters fallen und für welche Bereiche das Kundenunternehmen die operative Sorgfaltspflicht trägt.

Auf der untersten Ebene übernimmt der Betreiber die physische Sicherheit der Rechenzentrumsgebäude, die Stromversorgung, die Klimatisierung und den Austausch defekter Serverkomponenten. Auch die Virtualisierungsschicht und die physische Netzwerkinfrastruktur gehören bei Public-Cloud-Hyperscalern zum geschützten Kern des Anbieters.

Oberhalb dieser Basisinfrastruktur vollzieht sich mit jedem Schritt auf der Abstraktionsleiter eine Verschiebung der Pflichten. Während der Kunde bei virtuellen Servern das Betriebssystem patchen und Firewalls konfigurieren muss, übernimmt der Provider bei Anwendungsplattformen die Pflege der Ausführungsumgebung.

Unveränderlich bleibt jedoch eine eiserne Regel: Die Daten selbst, das Identitäts- und Rechtemanagement sowie die Klassifizierung vertraulicher Informationen verbleiben stets in der uneingeschränkten Verantwortung des Anwenders. Ein strategisches Fundament für diesen Schutzansatz beschreibt unser Leitfaden zu Sovereignty by Design im Enterprise-Umfeld.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Public Cloud im Enterprise-Einsatz sowie zu Arten Cloud Computing im Enterprise-Einsatz.

Die fünf Servicemodelle im technischen Detail: Von Bare Metal bis Serverless

Um das passende Modell für die eigene Anwendungslandschaft auszuwählen, müssen Architekten die fünf etablierten Servicemodelle im Hinblick auf Flexibilität, Automatisierungsgrad und Portabilität differenzieren.

Infrastructure as a Service (IaaS): Das Rechenzentrumsfundament

Infrastructure as a Service stellt grundlegende Rechen-, Speicher- und Netzwerkressourcen als softwaredefinierte Dienste bereit. Der Anwender erhält Zugriff auf virtuelle Maschinen oder Bare-Metal-Server, dynamisch zuteilbaren Block- und Objektspeicher sowie virtuelle Router, Subnetze und Firewalls.

Der entscheidende Vorteil von IaaS liegt in der absoluten Kontrolle über den Betriebssystem-Kernel, Systembibliotheken und Netzwerk-Topologien. Unternehmen können beliebige Legacy-Anwendungen ohne Code-Anpassung betreiben und exakte Compliance-Vorgaben auf Betriebssystemebene umsetzen.

Dieser Gestaltungsspielraum erfordert jedoch kontinuierlichen administrativen Aufwand für Patch-Management, Kernel-Härtung und Hochverfügbarkeit. Welche Wege aus teuren Virtualisierungsmonopolen führen, zeigt unsere Analyse zum VMware-Broadcom-Exit mit Proxmox VE und Ceph.

Container as a Service (CaaS): Der universelle Souveränitätsstandard

Container as a Service schließt die Lücke zwischen roher Infrastruktur und stark eingeschränkten Plattformdiensten. CaaS stellt standardisierte Container-Laufzeitumgebungen und Orchestrierungs-Cluster auf Basis von Kubernetes bereit, bei denen der Betreiber die Hochverfügbarkeit der Control Plane gewährleistet.

Für moderne Software-Architekturen fungiert CaaS als idealer technologischer Ausgleich. Entwickler paketieren ihre Software mitsamt allen Abhängigkeiten in standardisierte OCI-Container (Open Container Initiative), während Plattform-Teams die Skalierung, das Service-Routing und die Ressourcenzuteilung deklarativ über GitOps-Pipelines steuern.

Durch den Einsatz Kubernetes-nativer Operatoren wie CloudNativePG für PostgreSQL oder Rook für Ceph lassen sich selbst komplexe Datenbank- und Speicher-Cluster vollautomatisiert betreiben. Wie offene Plattformstandards Multi-Cloud-Portabilität garantieren, beleuchtet unser Leitfaden zum Sovereign Cloud Stack (SCS).

Platform as a Service (PaaS): Bequemlichkeit gegen API-Bindung

Platform as a Service stellt vollständige Entwicklungs- und Laufzeitumgebungen bereit, bei denen Entwickler lediglich ihren Quellcode und Konfigurationsdateien übergeben. Der Provider übernimmt das Betriebssystem, Runtimes für Java, Node.js oder Python, automatische Skalierung und das Einspielen von Sicherheitspatches.

Die gewonnene Entwicklungsgeschwindigkeit birgt jedoch erhebliche architektonische Risiken, wenn proprietäre Managed Services der Hyperscaler zum Einsatz kommen. Wer proprietäre NoSQL-Datenbanken, herstellerspezifische Message-Broker oder proprietäre Monitoring-Schnittstellen tief in seinen Code einbindet, erzeugt eine feste Abhängigkeit von diesem spezifischen Plattformbetreiber.

Ein späterer Wechsel zu einem alternativen Anbieter erfordert in der Praxis aufwendige Code-Refactorings, die bestehende Budgets massiv belasten. PaaS sollte daher primär auf Basis quelloffener Standards wie Red Hat OpenShift oder herstellerneutralen Cloud-Foundry-Derivaten genutzt werden.

Function as a Service (FaaS): Serverless zwischen Effizienz und Trap

Function as a Service treibt die Abstraktion auf die Spitze. Bei diesem serverlosen Architekturmuster laden Software-Ingenieure isolierte Funktionen hoch, die ausschließlich durch definierte Ereignisse wie HTTP-Aufrufe, Nachrichten in einer Queue oder Datenbank-Mutationen ausgelöst werden.

Die Abrechnung erfolgt sekundengenau oder gar im Millisekundentakt anhand der verbrauchten Rechenzeit, während bei Inaktivität keine Kosten anfallen. Was für asynchrone Hintergrundverarbeitung oder sporadische Webhooks hochgradig kosteneffizient ist, verwandelt sich bei dauerhaften Dauerlasten schnell in einen teuren Kostentreiber.

Zudem binden proprietäre Implementierungen wie AWS Lambda oder Google Cloud Functions die Anwendungslogik an spezifische Event-Schemata. Wer Serverless herstellerneutral betreiben will, setzt auf quelloffene Frameworks wie Knative oder OpenFaaS auf eigener Kubernetes-Basis.

Software as a Service (SaaS): Datenhoheit bei fertigen Applikationen

Software as a Service repräsentiert die oberste Stufe des Cloud-Portfolios. Der Anbieter betreibt die vollständige Anwendung inklusive Datenbanken, Servern, Backups und Netzwerkkomponenten, während Endanwender über Webbrowser oder mobile Clients auf die Fachfunktionen zugreifen.

Für nicht-differenzierende Büro- und Kollaborationsprozesse bietet SaaS unbestreitbare Skaleneffekte. Dennoch verlagert sich das Kontrollproblem hier vollständig auf die Datenebene: Unternehmen müssen gewährleisten, dass geschäftskritische Dokumente nicht in proprietären Silos gefangen bleiben.

Europäische Alternativen beweisen, dass moderne SaaS-Funktionalität ohne Verlust der Datenhoheit realisierbar ist. Praxisnahe Einblicke bieten unsere Fachvergleiche zu Nextcloud Hub versus Microsoft 365 sowie zum behördlichen openDesk-Arbeitsplatz.

„Die Wahl zwischen IaaS, CaaS, PaaS und FaaS ist keine reine Technologieentscheidung, sondern die Festlegung der unternehmerischen Kontrolltiefe: Wer betriebliche Bequemlichkeit mit proprietären Bindungen erkauft, verliert die Souveränität über seine digitale Wertschöpfungskette.“

Eine fundierte Architekturstrategie betrachtet die verschiedenen Servicemodelle nicht als isolierte Silos, sondern als abgestimmtes Portfolio. Entscheidend für den Unternehmenserfolg ist es, für jeden geschäftlichen Einsatzzweck das Modell zu wählen, das das optimale Verhältnis aus Entwicklungsgeschwindigkeit und dauerhafter Portabilität bietet.

Architektur- und Kontrollmatrix: Die fünf Servicemodelle im Enterprise-Vergleich

Für IT-Lenkungsausschüsse und Beschaffungsteams liefert die systematische Gegenüberstellung aller fünf Modelle eine klare Orientierung. Die folgende Matrix vergleicht Verantwortungsbereiche, Verwaltungsebenen und strategische Bewertungen für den souveränen IT-Betrieb:

Wie die Gegenüberstellung unterstreicht, markiert Container as a Service (CaaS) den strategischen Ruhepol moderner Enterprise-Architekturen. Während reines IaaS das interne Betriebsteam mit Routineaufgaben bindet und PaaS den Code an proprietäre Hyperscaler-APIs kettet, sichert CaaS maximale Agilität bei vollständiger technologischer Unabhängigkeit.

Anwendungen, die auf standardisierten OCI-Containern aufsetzen und persistente Zustände über Kubernetes-Operatoren verwalten, lassen sich bei Bedarf innerhalb weniger Stunden zwischen unterschiedlichen Cloud-Anbietern oder in das eigene Rechenzentrum verschieben.

Wirtschaftlichkeitsanalyse über 60 Monate: TCO^*-Divergenz von CaaS und Hyperscaler-PaaS

Die Wahl des Servicemodells hat fundamentale Auswirkungen auf die laufenden Betriebskosten (OPEX) über den gesamten Lebenszyklus einer Software. Um die wirtschaftliche Tragweite zu veranschaulichen, betrachten wir eine repräsentative Transaktionsplattform mit 100 Millionen monatlichen API-Aufrufen und 15 Terabyte relationalem Datenvolumen.

Wird diese Plattform vollständig auf proprietären PaaS- und FaaS-Komponenten eines US-Hyperscalers abgebildet (Managed Serverless Functions, proprietäre NoSQL-Datenbank, proprietäre API Gateways), summieren sich die monatlichen Nutzungsgebühren auf durchschnittlich 28.000 Euro. Über einen Betrachtungszeitraum von 60 Monaten belaufen sich die Gesamtkosten unter Berücksichtigung moderater Laststeigerungen auf rund 1,85 Millionen Euro.

Wird dieselbe Anwendungslogik stattdessen auf einer standardisierten CaaS-Architektur betrieben (dedizierte Kubernetes-Cluster bei einem europäischen IaaS-Anbieter, Persistenz über den CloudNativePG-Operator und softwaredefiniertem Ceph-Speicher), betragen die monatlichen Infrastruktur- und Colocation-Kosten lediglich 6.200 Euro.

Selbst unter Einrechnung eines internen Betreuungsaufwands von monatlich 4.000 Euro sowie initialer Härtungskosten von 85.000 Euro liegen die Fünfjahres-Gesamtkosten bei nur 697.000 Euro. Die CaaS-Umgebung spart dem Unternehmen somit über 1,15 Millionen Euro ein. Strategische Repatriierungsoptionen analysiert unser Beitrag zur Bare-Metal-Repatriation in der Praxis.

Der EU Data Act als regulatorischer Hebel: Artikel 23 bis 31 in der Praxis

Neben rein wirtschaftlichen Überlegungen verändern neue gesetzliche Rahmenbedingungen die strategische Bewertung von Cloud-Diensten. Mit der Verordnung (EU) 2023/2854 (EU Data Act) hat der europäische Gesetzgeber ein scharfes regulatorisches Schwert gegen unfaire Marktpraktiken globaler Cloud-Monopole geschaffen.

Die Artikel 23 bis 31 des Data Acts verpflichten Anbieter von Datenverarbeitungsdiensten (IaaS, PaaS, SaaS) dazu, sämtliche vertraglichen, technischen und organisatorischen Hindernisse für einen Wechsel des Cloud-Providers schrittweise vollständig abzubauen.

Von herausragender Bedeutung ist Artikel 29: Bis zum Ablauf der gesetzlichen Übergangsfristen müssen sämtliche Entgelte für den Wechsel und insbesondere die berüchtigten Datentransfergebühren (Egress Fees) ersatzlos auf null gesenkt werden. Hyperscaler dürfen Kunden nicht länger durch künstliche finanzielle Strafgebühren beim Datenabzug festhalten.

Flankiert wird dies durch Artikel 30, der verbindliche Vorgaben zur funktionalen Äquivalenz und Interoperabilität offener Schnittstellen definiert. IT-Einkäufer sollten diese gesetzlichen Garantien in Ausschreibungen proaktiv einfordern. Weitere Handlungsanweisungen bündelt unser Cloud-Exit-Portal für IT-Entscheider.

Die Make-or-Buy Sourcing-Weiche: Drei operative Betriebsmodelle

Bei der operativen Bereitstellung von Cloud-Diensten stehen IT-Organisationen vor der grundlegenden Frage nach der optimalen Fertigungstiefe. In der betrieblichen Praxis haben sich drei dominierende Betriebsmodelle bewährt, die sich hinsichtlich Ressourcenbedarf und Kontrollniveau deutlich unterscheiden:

Erstens (Eigenbetrieb): Unternehmen betreiben ihre IaaS- und CaaS-Schichten vollständig in Eigenregie auf eigener Hardware im Colocation-Rechenzentrum. Dieses Modell garantiert maximale Datenhoheit und tiefste Kostenkontrolle, setzt jedoch ein hochqualifiziertes internes Infrastrukturteam voraus.

Zweitens (Co-Managed): Die Basisinfrastruktur wird bei einem europäischen Cloud-Provider angemietet, während das interne Team die Kubernetes-Plattform und die Middleware-Operatoren steuert. Diese Aufteilung entlastet von Hardware-Wartung und bewahrt vollständige Software-Portabilität.

Drittens (Managed Service): Spezialisierte europäische Dienstleister übernehmen den vollständigen Betrieb gehärteter Open-Source-Plattformen mit definierten Service Level Agreements. Der Auftraggeber behält alle Quellcodes und Datenbestände, ohne eigene Betriebsmannschaften aufbauen zu müssen.

Die Entscheidung für eines dieser Modelle sollte entlang der eigenen Kernkompetenzen getroffen werden. Nicht-differenzierende Standardprozesse eignen sich hervorragend für Co-Managed- oder SaaS-Strukturen, während das geschäftskritische Kern-IP ausnahmslos auf beherrschbaren CaaS- oder IaaS-Umgebungen liegen sollte.

Der 4-Phasen-Transformationsfahrplan: Vom Lock-in zur portablen Architektur

Die Entflechtung gewachsener Cloud-Abhängigkeiten und der Übergang zu einer portablen Multi-Service-Architektur gelingt durch ein strukturiertes Vorgehen in vier aufeinander aufbauenden Meilensteinen:

Phase 1: Bestandsaufnahme und Klassifizierung des Service-Portfolios

Zu Beginn erfolgt eine lückenlose Inventarisierung sämtlicher im Unternehmen eingesetzter Cloud-Dienste. Jede Anwendung wird im Shared-Responsibility-Raster verortet und auf proprietäre Abhängigkeiten (proprietäre Datenbank-APIs, herstellerspezifische IAM-Bindings) hin analysiert.

Phase 2: Etablierung einer herstellerneutralen CaaS-Plattform

Das Plattform-Team baut ein standardisiertes Kubernetes-Ökosystem auf, das entweder im eigenen Rechenzentrum oder bei einem europäischen IaaS-Anbieter betrieben wird. CI/CD-Pipelines werden auf deklarative GitOps-Abläufe und OCI-konforme Container-Images umgestellt.

Phase 3: Entkopplung proprietärer PaaS- und Serverless-Dienste

In der dritten Phase werden proprietäre Cloud-Datenbanken und Message-Broker schrittweise durch quelloffene Operatoren wie CloudNativePG für PostgreSQL und Apache Kafka ersetzt. Serverlose Funktionen wandern auf portable Frameworks wie Knative um.

Phase 4: Durchsetzung von Datenportabilität und Exit-Routinen

Abschließend werden für alle verbleibenden SaaS-Angebote automatisierte Export-Routinen und vertragliche Exit-Klauseln gemäß EU Data Act etabliert. Regelmäßige Desaster-Recovery-Übungen verifizieren, dass ein Umzug aller Systeme innerhalb festgelegter RTO-Ziele reibungslos funktioniert.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur Cloud-Servicemodell-Strategie

1. Welche Kernanwendungen unterliegen proprietären PaaS- oder FaaS-Abhängigkeiten?

Lassen Sie Ihr Architekturteam transparent aufschlüsseln, welche Softwarekomponenten direkt an proprietäre Hyperscaler-APIs gekoppelt sind. Oft zeigt sich erst bei dieser Prüfung, dass vermeintlich moderne Cloud-Anwendungen bei einem Anbieterwechsel einen millionenschweren Neuentwicklungsaufwand verursachen würden.

2. Liegt für jeden produktiven SaaS-Dienst ein auditierbarer Exit- und Datenexportplan vor?

Verlangen Sie den Nachweis automatisierter, täglicher Datenbackups in offenen Formaten wie JSON, CSV oder SQL für alle geschäftskritischen SaaS-Systeme. Wer seine Datenbestände nicht täglich in eigener Hoheit sichert, begibt sich in eine existenzielle Abhängigkeit von der Preispolitik des jeweiligen Anbieters.

3. Wie werden die Wechselverpflichtungen nach Artikel 23 bis 31 des EU Data Act vertraglich abgesichert?

Prüfen Sie bestehende und künftige Cloud-Verträge auf die strikte Einhaltung des EU Data Acts. Stellen Sie sicher, dass Kündigungsfristen, technische Unterstützungsleistungen beim Umzug und der vollständige Verzicht auf Datentransfergebühren explizit im Vertragswerk verankert sind.

4. Entspricht die IAM- und Verschlüsselungskontrolle den Anforderungen von BSI C5 und DORA?

Verifizieren Sie, dass kryptografische Schlüssel für sensible Daten nach dem Prinzip Bring Your Own Key (BYOK) oder Hold Your Own Key (HYOK) unter Ihrer ausschließlichen Kontrolle verbleiben. Nur so erfüllen Sie die strengen Prüfkriterien des BSI IT-Grundschutzes und europäischer Resilienzverordnungen.

5. Welche Einsparpotenziale eröffnet die Standardisierung auf CaaS gegenüber teuren Hyperscaler-Laufzeiten?

Führen Sie eine fundierte 60-Monats-TCO-Rechnung durch, die dauerhafte PaaS- und Serverless-Gebühren mit einer containerisierten CaaS-Infrastruktur auf Basis von Kubernetes vergleicht. In den meisten Szenarien amortisieren sich Standardisierung und Open-Source-Operatoren bereits im ersten Betriebsjahr.

Strategisches Fazit: Vom Bequemlichkeits-Lock-in zur souveränen Mehrschichten-Architektur

Die Evolution typischer Cloud Services von simpler IaaS-Hardware bis zu vollautomatisiertem FaaS und SaaS hat die Geschwindigkeit der Softwareentwicklung grundlegend beschleunigt. Doch die scheinbare Bequemlichkeit hochintegrierter Plattformdienste hat in vielen Unternehmen zu einer bedrohlichen Anhäufung technischer und wirtschaftlicher Abhängigkeiten geführt.

Eine zukunftssichere IT-Strategie widersteht der Versuchung monolithischer All-in-One-Angebote globaler Hyperscaler. Indem Organisationen austauschbare Büroanwendungen als SaaS beziehen, ihr digitales Kern-IP jedoch konsequent auf offenen CaaS- und Kubernetes-Standards betreiben, vereinen sie maximale Entwicklungsagilität mit dauerhafter technologischer Souveränität und robuster Kostendisziplin.

Häufig gestellte Fragen (FAQ) zu typischen Cloud Services und Architekturen