Zehn Jahre lang war die Antwort auf fast jede IT-Frage dieselbe: Cloud. Neue Applikation? Cloud. Altes System migrieren? Cloud. Storage wächst? Cloud. Skalierung nötig? Cloud. Die Cloud war nicht nur eine Technologie — sie war eine Ideologie. „Cloud-first“ stand in den Strategiepapieren von Unternehmen, die nicht einmal verstanden hatten, was „first“ in diesem Kontext bedeutet.
Jetzt, zehn Jahre später, kommt die Ernüchterung. Nicht bei allen, aber bei vielen. Die Rechnungen sind da. Die Abhängigkeiten sind da. Die Fragen, die man hätte stellen sollen, bevor man migriert hat, sind immer noch da — nur dass sie jetzt teurer zu beantworten sind.
Einleitung
Die Migration in die Cloud war die dominierende IT-Strategie der letzten Dekade. Getrieben von Versprechen wie „unbegrenzter Skalierung“, „pay-as-you-go“ und „Zero Administration“ haben Unternehmen aller Größen Systeme, Daten und Prozesse in die Cloud verlagert — oft ohne die langfristigen Konsequenzen zu verstehen.
Heute beginnt eine Gegenbewegung. Nicht weil die Cloud gescheitert ist — sie hat ihre Vorteile —, sondern weil die Unternehmen, die in den letzten Jahren massiv in die Cloud gewandert sind, feststellen, dass die versprochene Einfachheit mit einem Preis kommt, der nicht nur finanziell ist.
Die Frage ist nicht mehr: „Cloud oder nicht?“ Die Frage ist: „Wofür Cloud, wofür On-Premise, und wie beides so kombinieren, dass die Souveränität über die eigenen Daten und Prozesse erhalten bleibt?“
Die Cloud-Revolution — und was sie wirklich verändert hat
Was die Cloud versprach
Die Argumente für die Cloud waren — und sind — attraktiv:
Skalierung. Mehr Last? Ein paar Klicks, und die Ressourcen sind da. Keine neue Hardware bestellen, kein Rack einbauen, kein Kabel ziehen. Die Cloud skaliert theoretisch unbegrenzt, und diese Skalierung ist innerhalb von Minuten verfügbar, nicht Wochen oder Monaten.
Geschwindigkeit. Eine neue Instanz starten, ein neues Deployment ausrollen, einen neuen Service aufsetzen — in der Cloud geht das in Minuten. On-Premise brauchte früher Tage oder Wochen für Hardware-Beschaffung und Einrichtung. In der Cloud ist alles sofort verfügbar.
Weniger Betriebsaufwand. Keine Server, die man warten muss. Keine Klimaanlage im Serverraum. Keine Hardware-Reparaturen am Freitagabend. Keine Ersatzteil-Lieferketten. Der Cloud-Provider kümmert sich um alles — Strom, Kühlung, Hardware, Netzwerk, physische Sicherheit.
Kapex vs. Opex. Statt hoher Investitionskosten (Capital Expenditure) für Hardware gibt es monatliche Betriebskosten (Operational Expenditure). Das ist für die Finanzabteilung attraktiv: planbare Kosten, keine Abschreibungen, keine Restwerte.
Managed Services. Datenbanken, Message Queues, Container-Orchestrierung, Authentication — alles als Service verfügbar. Kein Betrieb, keine Patches, keine Skalierungssorgen. Der Provider macht das.
Was die Cloud wirklich verändert hat
Die Cloud hat die Einstiegshürde massiv gesenkt. Das ist ihr größter Verdienst. Startups können heute innerhalb von Stunden eine Produktionsinfrastruktur aufbauen, die früher Wochen gedauert hätte. Kleine Unternehmen können auf Enterprise-Grade-Services zugreifen, ohne Enterprise-Grade-Personal zu brauchen.
Aber die Cloud hat auch die Wahrnehmung von IT-Kosten verzerrt. Die monatliche Rechnung fühlt sich anders an als eine einmalige Hardware-Investition — aber über drei bis fünf Jahre gerechnet ist sie oft teurer. Viel teurer. Und das ist nicht die einzige Überraschung.
Die Nachteile — die Rechnung kommt
Kostenentwicklung
Die Cloud ist billig, wenn man klein anfängt. Und sie wird teuer, wenn man wächst. Nicht linear teuer — exponentiell teuer.
Daten-Egress. Daten in die Cloud zu schicken ist kostenlos. Daten aus der Cloud herauszuholen kostet Geld. Das ist kein Zufall — es ist das Geschäftsmodell. AWS berechnet $0.09 pro GB für Daten-Transfer nach draußen. Bei einem Terabyte sind das $90. Bei zehn Terabyte $900. Und das ist nicht die einmalige Migration — das ist jede Replikation, jeder Backup-Restore, jeder Datenabgleich.
Storage-Kosten. S3-Storage kostet $0.023 pro GB und Monat (Standard-Tier). Das klingt wenig. Bei 50 TB sind das $1.150 pro Monat. Bei 500 TB — und das ist für mittelständische Unternehmen keine ungewöhnliche Größenordnung — sind es $11.500 pro Monat. $138.000 pro Jahr. Für Storage. Ohne Compute, ohne Netzwerk, ohne Managed Services.
Compute-Kosten. Eine m5.xlarge-Instanz bei AWS kostet ca. $0,192 pro Stunde. Das sind $1.682 pro Jahr. Eine vergleichbare Dedizierte-Server-Miete kostet ca. $200–400 pro Jahr. Faktor 4–8. Und bei Dediziert-Servern ist die Rechenleistung garantiert, nicht geteilt mit anderen Instanzen auf derselben Hardware.
Lizenz-Kosten. Microsoft-Lizenzen in der Cloud sind oft teurer als on-prem. Oracle-Lizenzen in der Cloud sind ein Albtraum. Red Hat Subscriptions in der Cloud kosten mehr als on-prem. Die Cloud macht Softwarelizenzen nicht billiger — sie macht sie teurer, weil die Cloud-Provider ihre Margen draufschlagen.
Der Faktor 3–10. Studien von 451 Research, IDC und mehreren Cloud-Financial-Management-Firmen zeigen konsistent: Über einen Zeitraum von 3–5 Jahren sind Cloud-Kosten für dauerhaft laufende Workloads 3- bis 10-mal höher als vergleichbare On-Premise-Kosten. Das gilt nicht für kurzlebige Workloads, nicht für Burst-Szenarien, nicht für Startups in der Wachstumsphase — aber für den typischen Dauerbetrieb mittelständischer und großer Unternehmen.
Vendor Lock-in
Die Cloud ist wie ein Hotel: Check-in ist einfach. Check-out ist das Problem.
Proprietäre Services. Wer AWS Lambda, DynamoDB, S3 Event Notifications, SQS, SNS und CloudFormation einsetzt, hat eine Architektur gebaut, die auf AWS funktioniert — und nur auf AWS. Die Migration weg davon ist nicht nur technisch aufwendig, sie ist organisatorisch eine Katastrophe, weil jede Komponente berührt werden muss.
Datenformate. Selbst wenn die Daten theoretisch portabel sind — SQL ist SQL, oder? —, sind die Unterschiede zwischen AWS Aurora, Google Cloud SQL und Azure Database für PostgreSQL substanziell genug, dass eine Migration kein einfacher Dump/Restore ist.
Operational Lock-in. Wer CloudFormation, Terraform-Provider-spezifische Module oder AWS CDK einsetzt, hat Infrastruktur-Code, der nicht portabel ist. Die IaC-Abstraktion, die eigentlich Unabhängigkeit schaffen sollte, ist selbst abhängig vom Provider.
Vertragsstrukturen. Reserved Instances, Savings Plans, Enterprise Agreements — die Vertragsstrukturen der Cloud-Provider sind darauf ausgelegt, Kunden langfristig zu binden. Der Rabatt für ein 3-Jahres-Commitment ist attraktiv, aber er bedeutet: Drei Jahre lang bezahlt man für Ressourcen, unabhängig davon, ob man sie noch braucht.
Datenhoheit
Wer seine Daten in der Cloud hat, hat sie nicht. Der Cloud-Provider hat sie. Und der Cloud-Provider hat eine Rechtsordnung, der er unterliegt.
Cloud Act. Der US-Cloud-Act von 2018 ermächtigt US-Behörden, Daten von US-Unternehmen auch dann einzufordern, wenn die Daten in einem Rechenzentrum außerhalb der USA liegen. AWS, Azure und Google sind US-Unternehmen. Das bedeutet: Daten, die bei diesen Providern liegen — egal ob in Frankfurt, Tokio oder Sydney — können von US-Behörden angefordert werden, ohne dass der Kunde davon erfährt.
GDPR. Die DSGVO verlangt, dass personenbezogene Daten in der EU verarbeitet werden oder ein angemessenes Schutzniveau besteht. Der EU-US Data Privacy Framework ist die aktuelle Lösung — aber er ist ein politisches Abkommen, kein technisches. Und er kann, wie sein Vorgänger (Privacy Shield), jederzeit für ungültig erklärt werden.
Datenzugriff durch Provider. Die AGB der großen Cloud-Provider erlauben ihnen Zugang zu Kunden-Daten in bestimmten Fällen — etwa bei Verdacht auf Missbrauch oder auf Anordnung eines Gerichts. Die Verschlüsselung der Daten ändert daran nichts, wenn der Provider die Schlüssel verwaltet.
Souveränität ist kein theoretisches Konzept. Für Unternehmen im öffentlichen Sektor, im Gesundheitswesen, in der Finanzindustrie und in kritischen Infrastrukturen ist Datenhoheit keine Frage der Präferenz, sondern der regulatorischen Pflicht. Wer Patientendaten, Finanzdaten oder Regierungsdaten in einer US-Cloud speichert, riskiert nicht nur Bußgelder — er riskiert den Entzug der Betriebserlaubnis.
Datenschutz
Datenschutz ist nicht dasselbe wie Datenhoheit. Datenhoheit fragt: Wer kann rechtlich auf meine Daten zugreifen? Datenschutz fragt: Wie schütze ich meine Daten vor unbefugtem Zugriff?
In der Cloud teilt man die Verantwortung mit dem Provider. Das „Shared Responsibility Model“ von AWS, Azure und Google ist klar definiert: Der Provider sichert die Infrastruktur, der Kunde sichert die Daten. Aber in der Praxis bedeutet das:
- Der Provider hat physischen Zugriff auf die Hardware.
- Der Provider kontrolliert das Hypervisor-Management.
- Der Provider kann Memory-Dumps erstellen.
- Der Provider hat Zugriff auf verschlüsselte Daten, wenn die Entschlüsselung in der Cloud stattfindet.
Das ist kein Misstrauen gegen die Provider. Es ist die Anerkennung einer Tatsache: Wer die Schlüssel nicht selbst verwaltet, hat keine volle Kontrolle über den Zugriff. Und „volle Kontrolle“ ist genau das, was Datenschutz in vielen Szenarien verlangt.
On-Premise ist nicht tot
Die Proklamation „On-Premise ist tot“ war die am häufigsten wiederholte Unwahrheit der letzten zehn Jahre. On-Premise war nie tot. On-Premise war nur nicht mehr sexy.
Was sich geändert hat
On-Premise bedeutet nicht mehr: Ein kalter Keller, ein Rack, ein überlasteter Administrator. Moderne On-Premise-Infrastruktur sieht anders aus:
Infrastructure as Code. Ansible, Terraform, Salt, Puppet — die gleichen Tools, die in der Cloud verwendet werden, funktionieren on-prem. Die Konfiguration ist versioniert, reproduzierbar, automatisiert. Der Unterschied zwischen Cloud und On-Premise ist nicht mehr die Automatisierung — es ist nur noch der Ort, wo die Hardware steht.
Virtualisierung ist gereift. Proxmox, bhyve, KVM — moderne Virtualisierungslösungen bieten Snapshots, Live-Migration, Resource-Pooling und Hochverfügbarkeit. Der Funktionsumfang ist mit Cloud-Virtualisierung vergleichbar, nur dass man die Hardware selbst kontrolliert.
ZFS. ZFS als Storage-Grundlage bietet Datenintegrität, Snapshots, inkrementelle Replikation, Kompression und Caching — alles, was man für robusten On-Premise-Storage braucht. ZFS macht den Unterschied zwischen „ein Filesystem“ und „ein Storage-Management-System“.
Container. Docker, Podman, Kubernetes on-prem — Container laufen nicht nur in der Cloud. Ein On-Premise-Kubernetes-Cluster mit Terraform-Provisioning und Ansible-Konfiguration ist kein Hexenwerk mehr.
Automatisches Patching. FreeBSD mit pkgbase, Ubuntu mit unattended-upgrades, Red Hat mit auto-updates — die Automatisierung von Security-Patches ist on-prem genauso möglich wie in der Cloud.
Stabilität
On-Premise-Infrastruktur ist stabil, wenn sie richtig gebaut ist. „Richtig gebaut“ heißt:
- ZFS mit Redundanz. Mirror oder RAID-Z vdevs, reguläre Scrubs, Snapshots, Replikation auf einen zweiten Server.
- CARP oder keepalived für Hochverfügbarkeit. Automatisches Failover bei Server-Ausfall.
- Monitoring. Prometheus, Grafana, Alertmanager — die gleichen Tools wie in der Cloud.
- Proaktive Wartung. ZFS-Scrubs wöchentlich, Smart-Monitoring für Disk-Failures, Firmware-Updates planvoll, nicht panisch.
Die Unterscheidung ist wichtig: Instabile On-Premise-Infrastruktur ist kein Argument gegen On-Premise. Es ist ein Argument gegen instabile Infrastruktur.
Sicherheit
On-Premise ist sicherer als die Cloud — wenn man die Security-Kontrolle nutzt, die man hat. In der Cloud gibt man physische Sicherheit und Netzwerk-Sicherheit an den Provider ab. On-Premise behält man beides:
- Physische Kontrolle. Der Server steht im eigenen Rack. Kein fremder Administrator hat Zugriff. Kein Cloud-Provider-Mitarbeiter kann ein Image erstellen.
- Netzwerk-Kontrolle. Die Firewall ist die eigene Firewall. Die Netzwerkstruktur ist die eigene Netzwerkstruktur. Es gibt keinen Shared-Tenant-Netzwerk-Pfad, über den ein anderer Cloud-Kunde Angriffe durchführen kann.
- Verschlüsselung. Daten können on-prem verschlüsselt werden, mit eigenen Schlüsseln, eigener Verwaltung, eigenem KMS. Die Entschlüsselung findet auf der eigenen Hardware statt, nicht auf einem Server, der einem US-Konzern gehört.
Kosteneffizienz
Die Rechnung ist einfach, wenn man sie ehrlich macht:
- Hardware-Anschaffung. Ein Server mit 256 GB RAM, 2x 1 TB NVMe und 4x 8 TB HDD kostet ca. 8.000–15.000 € — je nach Spezifikation. Geschrieben über 5 Jahre: 1.600–3.000 € pro Jahr.
- Strom und Kühlung. Ca. 500–1.500 € pro Jahr pro Server, je nach Effizienz.
- Netzwerk und Housing. Wenn man nicht selbst hostet: Colocation kostet ca. 100–300 € pro Monat pro HE. 1.200–3.600 € pro Jahr.
- Personal. Das ist der größte Kostenfaktor — aber das Personal braucht man in der Cloud auch. Cloud-Infrastruktur managt sich nicht selbst.
Vergleich: Dieselbe Rechenleistung und denselben Storage in der Cloud kosten — konservativ geschätzt — 30.000–80.000 € pro Jahr. Bei wachsendem Storage-Volumen wird der Unterschied größer, nicht kleiner.
Der Break-Even liegt typischerweise bei 18–24 Monaten. Danach ist On-Premise günstiger. Und der Kostenvorteil wächst, weil die Hardware bezahlt ist, während die Cloud-Rechnung jeden Monat kommt.
Wann Cloud sinnvoll ist
Die Cloud ist nicht schlecht. Sie ist das falsche Default.
Cloud ist sinnvoll, wenn:
Burst-Workloads. Lastspitzen, die unvorhersehbar sind und kurzfristig viel Ressourcen brauchen. Black Friday, eine virale Kampagne, ein einmaliger Daten-Processing-Job. Die Cloud kann in Minuten skalieren und danach wieder schrumpfen. On-Premise muss die Hardware für den Worst Case vorhalten.
Prototyping und MVPs. Wenn man nicht weiß, ob ein Produkt funktioniert, ist die Cloud der richtige Ort. Keine Hardware-Investition, keine Verpflichtung. Wenn das Produkt funktioniert und die Last stabil wird, kann man migrieren.
Globale Verteilung. Wenn man Server in Singapur, São Paulo und Frankfurt braucht — in der nächsten Woche —, ist die Cloud die einzige Option. On-Premise braucht Zeit für Standortsuche, Hardware-Lieferung und Einrichtung.
Managed Services, die man selbst nicht betreiben will. Wenn man kein Elasticsearch-Expertise hat und nicht aufbauen will, dann ist AWS OpenSearch eine vernünftige Wahl. Wenn man kein Kafka-Cluster betreiben kann, dann ist Confluent Cloud eine Lösung. Der Schlüssel ist: Man wählt den Service bewusst, nicht als Default.
Kurzlebige Umgebungen. Test, Staging, CI/CD-Runner — Umgebungen, die man hochfährt, benutzt und wieder abschaltet. Die Cloud ist ideal für Ressourcen, die nicht 24/7 laufen müssen.
Wann On-Premise besser ist
On-Premise ist besser, wenn:
Dauerhafte Workloads. Workloads, die 24/7/365 laufen und deren Ressourcenbedarf vorhersehbar ist. Webserver, Datenbanken, Dateispeicher, interne Anwendungen — das ist das Kerngeschäft, und das gehört on-prem.
Große Datenmengen. Storage ist in der Cloud teuer. Bei 100+ TB wird die Rechnung absurd. On-Premise mit ZFS und großen Platten ist wirtschaftlich, und die Daten liegen dort, wo man sie kontrolliert.
Regulatorische Anforderungen. DSGVO, B3S, Kritis, Medizinprodukte-Verordnung — wenn der Gesetzgeber Datenhoheit verlangt, ist On-Premise keine Option, sondern eine Pflicht.
Langfristige Kosteneffizienz. Wenn man die Last für die nächsten 3–5 Jahre abschätzen kann, ist On-Premise günstiger. Deutlich günstiger.
Latenz-empfindliche Anwendungen. Die Netzwerk-Latenz zwischen Rechenzentrum und Nutzer ist on-prem minimiert. In der Cloud gibt es die Latenz zum nächsten Cloud-Region-Endpoint — und die ist für Echtzeit-Anwendungen nicht immer akzeptabel.
Daten, die nicht die Firma verlassen dürfen. Geheimnisse, Patente, Forschungsdaten, Kunden-Personas — es gibt Daten, die aus rechtlichen, ethischen oder strategischen Gründen nicht auf fremder Infrastruktur liegen dürfen.
Hybridmodelle — oft die beste Lösung
Die falsche Debatte ist „Cloud oder On-Premise“. Die richtige Debatte ist: „Was gehört wo hin?“
Das Prinzip der minimalen Cloud
Nutze die Cloud für das, was sie besser kann als On-Premise. Nutze On-Premise für alles andere. Das klingt banal, ist aber die Konsequenz einer ehrlichen Bewertung:
- Stabile Kern-Workloads → On-Premise. Datenbanken, Dateispeicher, interne Anwendungen, Identity Management.
- Burst- und Spitzenlast → Cloud. Zusätzliche Compute-Kapazität bei Lastspitzen, CI/CD-Runner, temporäre Testumgebungen.
- Datenhoheit-kritische Daten → On-Premise. Alles, was regulatorisch oder strategisch geschützt werden muss.
- Globale Services → Cloud. CDN, Edge-Computing, globale API-Endpunkte.
- Managed Spezial-Services → Cloud. ML-Training, spezialisierte Datenbanken, Services, die man selbst nicht betreiben kann oder will.
Praktisches Hybrid-Setup
Ein konkretes Beispiel für ein mittelständisches Unternehmen:
On-Premise:
- ZFS-Storage-Server mit 200 TB (Datenbanken, Dateispeicher, Backups)
- Proxmox- oder bhyve-Cluster für interne Anwendungen
- Git-Server (Gitea oder GitLab)
- Identity Management (FreeIPA, Keycloak)
- Monitoring (Prometheus, Grafana)
- E-Mail-Server
Cloud:
- CDN für die Website und statische Assets
- Cloud-Runner für CI/CD (nur bei Bedarf)
- Disaster Recovery: Replikation der kritischsten Daten in einen Cloud-Object-Store (verschlüsselt, mit eigenen Schlüsseln)
- Burst-Compute für Lastspitzen (z.B. Quartalsende-Reporting)
Die monatliche Cloud-Rechnung für dieses Setup: vielleicht 500–2.000 €. Nicht 20.000 €. Nicht 50.000 €. Weil das Kerngeschäft on-prem läuft, und die Cloud nur das macht, was sie gut kann.
Die Rückkehr-Strategie
Für Unternehmen, die bereits massiv in der Cloud sind und die Kostenstruktur hinterfragen:
1. Inventur. Welche Workloads laufen in der Cloud? Welche davon laufen dauerhaft? Welche kosten am meisten?
2. Klassifikation. Welche Workloads sind Cloud-native (Lambda, DynamoDB, SQS)? Welche sind portabel (Docker-Container, Standard-Datenbanken, Webserver)?
3. Identifikation der Migrationskandidaten. Portable, dauerhafte Workloads mit hohem Daten-Volumen sind die besten Kandidaten für eine Rückkehr on-prem.
4. Pilot-Migration. Eine Workload auswählen, migrieren, Kosten vergleichen. Nicht alles auf einmal — iterativ vorgehen.
5. Optimierung. Nach der Migration: Cloud-Kosten für die verbleibenden Workloads optimieren. Reserved Instances, Spot-Instances, Right-Sizing.
Digitale Souveränität — mehr als ein Buzzword
Digitale Souveränität bedeutet: Die Fähigkeit, über die eigenen Daten, Prozesse und Infrastruktur selbst zu bestimmen. Nicht abhängig zu sein von einem einzelnen Provider, einem einzelnen Land, einer einzelnen Rechtsordnung.
Das ist kein nationalistisches Konzept. Es ist ein pragmatisches. Wer seine Infrastruktur nicht kontrolliert, kontrolliert sein Geschäft nicht. Wer seine Daten nicht kontrolliert, kontrolliert seine Zukunft nicht.
Die Cloud hat die Illusion erzeugt, dass Infrastruktur kein Problem mehr ist — man mietet sie ja einfach. Aber Infrastruktur war nie das Problem. Das Problem ist die Abhängigkeit. Und die Abhängigkeit ist in den letzten zehn Jahren größer geworden, nicht kleiner.
On-Premise ist die Antwort auf diese Abhängigkeit. Nicht als Absolutum — „alles on-prem“ ist genauso dogmatisch wie „alles Cloud“ —, sondern als bewusste Entscheidung: Was muss ich selbst kontrollieren? Was kann ich auslagern? Und wie stelle ich sicher, dass ich das Ausgelagerte bei Bedarf zurückholen kann?
Fazit
Die Cloud hat die IT-Landschaft verändert. Sie hat den Einstieg erleichtert, die Skalierung beschleunigt und die Betriebsmodelle transformiert. Aber sie hat auch Abhängigkeiten geschaffen, Kosten getrieben und Datenhoheit aufgeweicht.
On-Premise ist die Rückbesinnung auf das, was wirklich zählt: Kontrolle über die eigenen Daten, Kosteneffizienz für dauerhafte Workloads und Unabhängigkeit von einzelnen Providern.
Die beste Lösung ist Hybrid: Cloud für das, was die Cloud besser kann. On-Premise für alles andere. Und eine Architektur, die beides verbindet, ohne die Souveränität aufzugeben.
Die Unternehmen, die das verstehen, werden die nächsten zehn Jahre dominieren. Die anderen werden weiter monatliche Cloud-Rechnungen bezahlen — und sich fragen, warum ihre IT so teuer ist.
