Ein mittelständischer Maschinenbauer will sein Angebotswesen modernisieren. Die eine Abteilung schlägt vor, einen Server bei einem Hyperscaler zu mieten und die bisherige Software darauf weiterzubetreiben. Die andere möchte ein fertiges CRM-Werkzeug im Browser abonnieren. Die Entwicklungsabteilung wiederum würde am liebsten eine eigene Anwendung schreiben und sie auf einer Plattform betreiben, die sich um Server und Updates selbst kümmert. Alle drei Vorschläge laufen unter dem Etikett „Cloud“ – und unterscheiden sich doch grundlegend.

Der Unterschied liegt weniger in der Technik als in der Frage, wer was betreibt. Genau dafür gibt es die Kürzel IaaS, PaaS und SaaS. Wer sie versteht, kann Angebote vergleichen, Verantwortung sauber verteilen und realistischer einschätzen, was ein Cloud-Projekt kostet.

Was Cloud Computing technisch bedeutet

Cloud Computing heißt im Kern: Rechenleistung, Speicher, Datenbanken oder ganze Anwendungen werden über das Netz bereitgestellt, nach Bedarf gebucht und nach Verbrauch oder Nutzerzahl abgerechnet. Das US-amerikanische Normungsinstitut NIST hat dafür schon 2011 fünf Merkmale festgehalten, die bis heute als Referenz gelten: Selbstbedienung auf Abruf, Zugriff über das Netz, gemeinsam genutzte Ressourcen, schnelle Elastizität und gemessene Nutzung.

Elastizität ist dabei das Merkmal, das den Unterschied zum klassischen Hosting ausmacht. Angenommen, ein Webshop hat im Dezember die dreifache Last wie im Februar. Im eigenen Rechenzentrum müsste er Hardware für den Spitzenmonat vorhalten, die den Rest des Jahres halb leer steht. In der Cloud lassen sich zusätzliche Instanzen für die Wochen vor Weihnachten starten und danach wieder abschalten.

Virtualisierung und Container als Fundament

Möglich wird das durch Virtualisierung: Ein sogenannter Hypervisor teilt einen physischen Server in mehrere virtuelle Maschinen auf, die jeweils ein eigenes Betriebssystem haben und voneinander abgeschottet sind. Darüber hat sich in den vergangenen Jahren eine zweite Schicht etabliert, die Container. Sie teilen sich den Kernel des Betriebssystems, starten in Sekunden und lassen sich mit Orchestrierungswerkzeugen wie Kubernetes über viele Maschinen verteilen. Viele Plattformdienste der großen Anbieter laufen intern auf genau dieser Technik, ohne dass Kunden das sehen.

Die Servicemodelle im Vergleich

Die drei klassischen Servicemodelle lassen sich am besten als Stapel verstehen. Ganz unten liegen Rechenzentrum, Hardware und Netzwerk, darüber Betriebssystem und Laufzeitumgebung, ganz oben die Anwendung und die Daten. Je weiter oben das gemietete Angebot ansetzt, desto mehr übernimmt der Anbieter.

Infrastructure as a Service: Bausteine zum Selbstbauen

Bei IaaS mieten Sie virtuelle Maschinen, Speicher und Netzwerke. Alles darüber liegt bei Ihnen: Betriebssystem patchen, Firewall-Regeln pflegen, Backups einrichten, Software installieren. Das bietet die meisten Freiheiten und eignet sich für Anwendungen, die sich nicht ohne Weiteres umbauen lassen – etwa eine ältere Warenwirtschaft, die einen bestimmten Windows-Server erwartet.

Der Haken: IaaS spart vor allem Hardware und Rechenzentrumsfläche, aber kaum Betriebsaufwand. Wer eine Anwendung unverändert von der eigenen Hardware auf eine virtuelle Maschine verschiebt („Lift and Shift“), hat danach dieselbe Wartungsarbeit wie vorher, nur mit anderer Rechnung.

Platform as a Service: Code hinein, Betrieb inklusive

PaaS setzt eine Ebene höher an. Ein Entwicklungsteam lädt seinen Code oder ein Container-Image hoch, die Plattform kümmert sich um Server, Betriebssystem-Updates, Skalierung und oft auch um Zertifikate und Protokollierung. Verwaltete Datenbanken gehören ebenfalls in diese Kategorie: Sie bekommen eine PostgreSQL- oder MySQL-Instanz samt automatischer Sicherung, ohne selbst einen Datenbankserver zu pflegen.

Für Teams, die eigene Software entwickeln, ist PaaS meist der wirtschaftlichste Einstieg. Der Preis dafür ist weniger Kontrolle: Laufzeitversionen, Netzwerkkonfiguration und Wartungsfenster gibt der Anbieter vor, und viele Dienste sind proprietär. Eine Anwendung, die tief auf solchen Diensten aufbaut, lässt sich später nur mit Aufwand zu einem anderen Anbieter umziehen.

Software as a Service: fertige Anwendung im Abo

SaaS ist das Modell, das die meisten Büros längst nutzen, oft ohne es so zu nennen: E-Mail und Office im Browser, Videokonferenzen, CRM, Lohnabrechnung. Sie zahlen pro Nutzer und Monat, Updates spielt der Anbieter ein, Installation entfällt.

Was bleibt bei Ihnen? Mehr, als viele denken. Wer Zugang hat, wie Passwörter und Mehrfaktor-Anmeldung geregelt sind, welche Daten im System landen und ob sie sich beim Kündigen vollständig exportieren lassen – das entscheidet das nutzende Unternehmen, nicht der Anbieter.

Serverless und Container-Dienste: die Zwischenstufen

Die drei Kürzel decken die Wirklichkeit nur grob ab. Dazwischen haben sich weitere Modelle etabliert. Bei Function as a Service (FaaS), oft als Serverless bezeichnet, schreiben Sie nur noch einzelne Funktionen, die bei einem Ereignis starten – etwa wenn eine Rechnung als PDF hochgeladen wird – und nach Ausführungszeit abgerechnet werden. Verwaltete Kubernetes-Dienste wiederum liegen zwischen IaaS und PaaS: Der Anbieter betreibt den Cluster, Ihr Team verantwortet die Container darauf. Welche Vor- und Nachteile serverlose Architekturen im Alltag haben, beschreibt der Beitrag zu Serverless-Architekturen und ihren Herausforderungen.

Geteilte Verantwortung: was beim Anbieter bleibt und was bei Ihnen

Alle großen Anbieter beschreiben ihr Verhältnis zum Kunden mit einem Modell der geteilten Verantwortung (Shared Responsibility). Vereinfacht gilt: Der Anbieter sichert die Cloud selbst ab, also Rechenzentren, Hardware und die eigenen Dienste. Der Kunde verantwortet, was er in der Cloud konfiguriert und speichert.

Dieser Satz klingt banal, erklärt aber viele Sicherheitsvorfälle der vergangenen Jahre. Selten wurde ein Anbieter gehackt. Häufiger waren Speicherbereiche versehentlich öffentlich lesbar, Zugangsschlüssel lagen im Quellcode oder Administratorkonten hatten keine Mehrfaktor-Anmeldung. Angenommen, eine Agentur legt Kundendaten in einem Objektspeicher ab und gibt den Bereich zum Testen kurz öffentlich frei: Dann liegt das Problem nicht beim Anbieter, sondern bei der Konfiguration.

Je höher das Servicemodell, desto kleiner wird Ihr Anteil, aber er verschwindet nie. Identitäten, Berechtigungen und Daten bleiben in jedem Modell Ihre Aufgabe. Wie sich Cloud-Umgebungen systematisch absichern lassen, ist Thema unserer Beratung und Seminare zu Cloud Security.

Datenschutz und Standortfragen

Werden personenbezogene Daten verarbeitet, ist der Cloud-Anbieter in der Regel Auftragsverarbeiter nach Art. 28 DSGVO, und es braucht einen entsprechenden Vertrag. Bei Anbietern mit Sitz außerhalb der EU kommt die Frage der Drittlandübermittlung hinzu. Seit Juli 2023 gibt es dafür mit dem EU-US Data Privacy Framework wieder einen Angemessenheitsbeschluss der EU-Kommission für zertifizierte US-Unternehmen. Viele Datenschutzfachleute halten ihn allerdings für angreifbar, weil seine Vorgänger vor dem Europäischen Gerichtshof gescheitert sind. Eine Klage gegen den Beschluss wies das Gericht der EU im September 2025 ab; über das Rechtsmittel dagegen entscheidet nun der Europäische Gerichtshof (Rechtssache C-703/25 P). Dieser Abschnitt ersetzt keine Rechtsberatung; für konkrete Verträge sollten Sie Ihre Datenschutzbeauftragten einbeziehen.

Public, Private, Hybrid und Multi-Cloud

Neben dem Servicemodell gibt es das Bereitstellungsmodell, also die Frage, wo und für wen die Cloud betrieben wird.

• Public Cloud: Ressourcen eines Anbieters, die sich viele Kunden teilen, logisch voneinander getrennt. Das ist die übliche Form bei AWS, Microsoft Azure oder Google Cloud.
• Private Cloud: Eine Cloud-Umgebung, die nur einer Organisation dient, im eigenen Rechenzentrum oder bei einem Dienstleister. Sie bietet Selbstbedienung und Automatisierung, aber nicht die nahezu unbegrenzte Kapazität der großen Anbieter.
• Hybrid Cloud: Eine Kombination aus eigener Infrastruktur und Public Cloud, etwa wenn Produktionsdaten im eigenen Werk bleiben und Auswertungen in der Cloud laufen.
• Multi-Cloud: Die Nutzung mehrerer Public-Cloud-Anbieter, oft nicht geplant, sondern gewachsen – das Office-Paket bei einem Anbieter, das Datenanalyseprojekt bei einem anderen.

Multi-Cloud wird gern als Schutz gegen Abhängigkeit verkauft. In der Praxis verdoppelt es zunächst den Aufwand für Know-how, Sicherheitsregeln und Kostenkontrolle. Für die meisten mittelständischen Unternehmen ist ein Hauptanbieter mit bewusst gewählten Ausnahmen die realistischere Strategie.

Die Anbieterlandschaft: Hyperscaler und europäische Alternativen

Den Markt für Infrastruktur- und Plattformdienste prägen drei US-Konzerne, die sogenannten Hyperscaler: Amazon Web Services, Microsoft Azure und Google Cloud. Sie bieten jeweils mehr als hundert Dienste von der virtuellen Maschine bis zum KI-Modell an und betreiben Rechenzentrumsregionen auch in Deutschland. Wie Microsoft seine Cloud-Plattform aufgebaut hat und was sie heute umfasst, zeigt unser Beitrag zur Entwicklung von Microsoft Azure.

Daneben gibt es Anbieter mit Schwerpunkt in Europa, darunter STACKIT aus der Schwarz-Gruppe, IONOS, OVHcloud und T Cloud Public der Telekom (bis Januar 2026 Open Telekom Cloud). Ihr Angebot ist schmaler, sie werben aber mit Rechenzentren und Unternehmenssitz in der EU. Das Stichwort lautet digitale Souveränität: Gemeint ist, dass keine außereuropäische Rechtsordnung auf die Daten zugreifen kann. Die Hyperscaler haben darauf mit eigenen Souveränitätsangeboten reagiert, etwa durch Regionen mit europäischem Betriebspersonal. Was diese Zusagen rechtlich tragen, ist umstritten und sollte im Einzelfall geprüft werden.

Bei SaaS ist der Markt ohnehin viel breiter: Hier konkurrieren Tausende spezialisierte Anbieter, von der Zeiterfassung bis zur Branchensoftware.

Kosten: wo die Cloud teurer wird als gedacht

Die Cloud wandelt Investitionen in laufende Kosten um. Das ist bequem, macht die Ausgaben aber schwerer vorhersehbar. Typische Kostenfallen sind:

1. Vergessene Ressourcen: Testumgebungen, die nach dem Projekt weiterlaufen, oder Speicher-Snapshots, die sich über Jahre ansammeln.
2. Überdimensionierung: Virtuelle Maschinen, die nach dem Vorbild alter Hardware großzügig bemessen wurden und dauerhaft kaum ausgelastet sind.
3. Datenübertragung: Viele Anbieter berechnen Gebühren, wenn Daten die Cloud verlassen (Egress). Das fällt erst auf, wenn große Datenmengen regelmäßig heruntergeladen werden.
4. Dauerlast zum Listenpreis: Für Server, die rund um die Uhr laufen, bieten die Anbieter Rabatte gegen Laufzeitbindung. Wer sie nicht nutzt, zahlt deutlich mehr.

Gegen diese Fallen hat sich eine eigene Disziplin entwickelt, FinOps: Fachabteilung, IT und Controlling betrachten Cloud-Kosten gemeinsam, ordnen sie über Kennzeichnungen (Tags) einzelnen Projekten zu und setzen Budgetwarnungen. Das ist weniger eine Werkzeugfrage als eine Frage der Zuständigkeit. Jede Ressource braucht jemanden, der sie verantwortet.

Welches Modell zu welchem Vorhaben passt

Zurück zum Maschinenbauer vom Anfang. Für das Angebotswesen gibt es keine pauschal richtige Antwort, aber eine sinnvolle Reihenfolge der Fragen:

• Gibt es eine Standardsoftware, die den Prozess gut abdeckt? Dann ist SaaS meist die günstigste und sicherste Wahl, weil der Betrieb vollständig beim Anbieter liegt. Prüfen sollten Sie Datenexport, Schnittstellen und Vertragsbedingungen.
• Entwickeln Sie eine eigene Anwendung, weil der Prozess ein Wettbewerbsvorteil ist? Dann lohnt PaaS oder Serverless, damit sich das Team auf den Code statt auf Server konzentriert.
• Muss eine bestehende Anwendung unverändert weiterlaufen? Dann ist IaaS oft der pragmatische Zwischenschritt. Planen Sie aber von Anfang an, ob und wann die Anwendung modernisiert wird.

Unsere Einschätzung: Überschätzt wird häufig der reine Kostenvorteil, unterschätzt der organisatorische Wandel. Wer in die Cloud geht, ändert vor allem Zuständigkeiten. Aus Hardwarebetreuung wird Berechtigungsmanagement, aus Investitionsanträgen wird laufendes Kostenmonitoring. Der Gewinn liegt in Geschwindigkeit und Flexibilität: Eine neue Testumgebung steht in Minuten statt in Wochen. Wie sich bestehende Systeme schrittweise umziehen lassen, beschreibt der Beitrag von On-Premise zur Cloud.

Wer Servicemodelle, Anbieter und Architekturentscheidungen für das eigene Unternehmen sortieren möchte, findet auf unserer Seite zu Cloud-Beratung, Coaching und Seminaren die passenden Formate, darunter ein Seminar zu Cloud-Technologien und -Strategien.

Häufige Fragen zu Cloud-Diensten

Ist die Cloud sicherer als das eigene Rechenzentrum?

Die physische Sicherheit und der Schutz der Basisinfrastruktur sind bei großen Anbietern in der Regel höher, als ein mittelständisches Unternehmen sie selbst leisten kann. Die meisten Vorfälle entstehen jedoch durch Fehlkonfigurationen und schwache Zugänge auf Kundenseite. Sicher wird die Cloud also erst durch sauberes Berechtigungsmanagement, Mehrfaktor-Anmeldung und regelmäßige Prüfung der Einstellungen.

Lässt sich eine bestehende Anwendung einfach in die Cloud verschieben?

Technisch geht das bei den meisten Anwendungen über IaaS. Ob es sinnvoll ist, hängt davon ab, wie die Anwendung lizenziert ist, wie sie mit anderen Systemen kommuniziert und welche Latenz sie verträgt. Eine Bestandsaufnahme vor dem Umzug klärt, welche Systeme verschoben, modernisiert oder durch SaaS ersetzt werden sollten.

Wie lässt sich die Abhängigkeit von einem Anbieter begrenzen?

Ganz vermeiden lässt sie sich kaum. Begrenzen lässt sie sich durch offene Formate, Container statt proprietärer Laufzeiten, Infrastruktur als Code und einen dokumentierten Ausstiegsplan. Zusätzlich verpflichtet der EU Data Act Cloud-Anbieter seit September 2025, den Wechsel zu einem anderen Anbieter zu erleichtern.

Was ist der Unterschied zwischen SaaS und klassischer Mietsoftware?

Bei klassischer Mietsoftware installieren Sie das Programm auf eigenen Rechnern und zahlen nur die Lizenz periodisch. Bei SaaS läuft die Anwendung beim Anbieter, der auch Updates, Sicherung und Verfügbarkeit verantwortet. Sie nutzen sie über Browser oder App.