Ein Berliner Startup migriert seine Anwendung zu AWS. Der CTO rechnet mit Kosten von etwa 2.000 Euro pro Monat, basierend auf dem AWS-Preiskalkulator. Die erste Rechnung nach drei Monaten: 14.000 Euro. Data Transfer, NAT Gateway Gebühren, CloudWatch Logs, Request-Kosten für S3. Niemand hatte diese Nebenkosten auf dem Schirm.
Dieses Szenario ist kein Einzelfall. Laut einer Studie von Flexera überschreiten Unternehmen ihre Cloud-Budgets im Durchschnitt um 23 Prozent. Die Marketing-Versprechen der Cloud (nur zahlen, was man nutzt, keine Vorabinvestitionen) sind nicht falsch, aber sie erzählen nicht die ganze Geschichte. Dieser Teil der Serie beleuchtet die Schattenseiten: versteckte Kosten, Sicherheitsrisiken, und Fallstricke, die auch erfahrene Teams treffen können.
Die wahren Kosten der Cloud
Cloud-Pricing ist komplex. AWS allein hat Tausende von Services mit jeweils eigenen Preisstrukturen. Die Grundidee (Pay-per-Use) klingt einfach, aber die Umsetzung ist es nicht. Mehrere Kostenkategorien werden regelmäßig unterschätzt.
Data Transfer: Der unterschätzte Kostentreiber
Cloud-Anbieter berechnen Gebühren für Daten, die das Rechenzentrum verlassen (Egress). Der Upload ist meist kostenlos, aber jedes Byte, das an Nutzer ausgeliefert wird, kostet. AWS berechnet etwa 0,09 Dollar pro Gigabyte für Traffic nach Europa. Das klingt nach wenig, summiert sich aber schnell.
Ein Beispiel: Eine Anwendung liefert täglich 500 GB an Nutzer aus. Das sind 15 TB pro Monat, also etwa 1.350 Dollar nur für Egress. Hinzu kommen Kosten für NAT Gateways (wenn private Subnetze ins Internet müssen), Load-Balancer-Gebühren, API-Gateway-Request-Kosten. Diese 'Nebenkosten' können die eigentlichen Compute-Kosten übersteigen.
Preisvolatilität und Komplexität
Laut dem Cloud-Cost-Benchmark 2025 ändert AWS seine Preise durchschnittlich 197 Mal pro Monat. Azure kommt auf etwa 0,76 Änderungen pro Monat, Google Cloud auf 0,35. Diese Volatilität macht langfristige Budgetplanung schwierig. Wer heute einen Preis kalkuliert, kann in drei Monaten eine andere Rechnung bekommen.
Die Preisstrukturen selbst sind komplex. Reserved Instances, Savings Plans, Spot Instances, Committed Use Discounts: Jede Option hat eigene Bedingungen und Einschränkungen. Unternehmen stellen dedizierte FinOps-Teams ab, um Cloud-Kosten zu optimieren. Für kleinere Organisationen fehlt diese Expertise oft.
Die Sparpotenziale sind erheblich: AWS Reserved Instances und Savings Plans bieten bis zu 72 Prozent Rabatt, Spot Instances sogar bis zu 90 Prozent (allerdings mit dem Risiko der Unterbrechung). Azure lockt mit dem Hybrid Benefit: 40 Prozent Ersparnis für Kunden mit bestehenden Microsoft-Lizenzen. Google Cloud bietet Committed Use Discounts mit bis zu 57 Prozent Rabatt sowie automatische Sustained Use Discounts bei kontinuierlicher Nutzung.
Der Vergleich: Cloud vs. Dedicated
Für Workloads mit konstantem Ressourcenbedarf ist die Cloud nicht immer wirtschaftlicher als dedizierte Server. Eine einfache Rechnung: Ein dedizierter Server bei Hetzner mit 64 GB RAM und 8 CPU-Kernen kostet etwa 50 Euro pro Monat. Eine vergleichbare EC2-Instanz (m5.2xlarge) kostet On-Demand etwa 280 Dollar. Selbst mit dreijährigen Reserved Instances bleibt ein erheblicher Preisunterschied.
Die Cloud rechtfertigt sich durch andere Faktoren: Elastizität, globale Verfügbarkeit, Managed Services, schnellere Time-to-Market. Wer diese Vorteile nicht braucht, zahlt für etwas, das er nicht nutzt. Die Rückwanderung zur dedizierten Infrastruktur (Cloud Repatriation) ist ein dokumentierter Trend: 42 Prozent der Unternehmen haben im letzten Jahr Workloads aus der Public Cloud zurückverlagert.
Sicherheitsrisiken: Die Statistiken sind alarmierend
Die Cloud hat Sicherheit nicht einfacher gemacht, sondern die Angriffsfläche verändert. Die Zahlen sind ernüchternd.
Die Bedrohungslage 2025
82 Prozent aller Datenbreaches betreffen Cloud-gespeicherte Daten. 80 Prozent der Organisationen hatten im letzten Jahr mindestens einen Cloud-Sicherheitsvorfall. Die durchschnittlichen Kosten eines Datenbreaches liegen bei 4,35 Millionen Dollar; in regulierten Branchen wie Healthcare oder Finance oft über 10 Millionen.
Die Hauptursache ist nicht mangelnde Technologie, sondern menschliches Versagen. Laut Gartner-Analysen sind 99 Prozent der Cloud-Sicherheitsfehler die Schuld des Kunden, nicht des Anbieters. Fehlkonfigurationen sind der Hauptschuldige: öffentlich zugängliche S3-Buckets, offene Sicherheitsgruppen, fehlende Verschlüsselung, überprivilegierte Service-Accounts.
Das Shared-Responsibility-Modell
Cloud-Anbieter arbeiten nach dem Shared-Responsibility-Modell: Der Anbieter sichert die Infrastruktur (physische Server, Netzwerk, Hypervisor), der Kunde ist für alles darüber verantwortlich (Betriebssystem, Anwendungen, Daten, Zugriffsrechte). Die Trennlinie variiert je nach Service: Bei IaaS liegt mehr Verantwortung beim Kunden, bei SaaS mehr beim Anbieter.
Viele Unternehmen unterschätzen ihren Anteil der Verantwortung. Sie nehmen an, dass 'in der Cloud' automatisch 'sicher' bedeutet. Das ist falsch. AWS sichert die Hardware gegen physischen Zugriff, aber nicht die Datenbank gegen SQL-Injection. Azure patcht den Hypervisor, aber nicht die WordPress-Installation des Kunden.
Die häufigsten Sicherheitsfehler
- Öffentliche Storage-Buckets: S3, Blob Storage mit 'Public' statt 'Private'
- Überprivilegierte IAM-Rollen: 'AdministratorAccess' für alle Entwickler
- Fehlende Verschlüsselung: Daten at rest und in transit unverschlüsselt
- Veraltete Software: Ungepatchte Container-Images, alte Bibliotheken
- Ungeschützte Secrets: API-Keys und Passwörter im Code oder in Umgebungsvariablen
- Fehlende Logs: Keine Auditierung, keine Erkennung von Anomalien
Die Lösung ist keine neue Technologie, sondern Prozesse und Disziplin. Infrastructure-as-Code ermöglicht wiederholbare, überprüfbare Konfigurationen. Automatisierte Security-Scans entdecken Fehlkonfigurationen vor dem Deployment. Das Prinzip des Least Privilege reduziert die Angriffsfläche. Regelmäßige Audits identifizieren Drift vom gewünschten Zustand.
Vendor Lock-in: Die goldenen Fesseln
Cloud-Anbieter bieten proprietäre Services, die Probleme elegant lösen. AWS Lambda für Serverless, DynamoDB für NoSQL, Aurora für relationale Datenbanken. Diese Services sind oft besser als Open-Source-Alternativen, besser integriert, einfacher zu betreiben. Aber sie schaffen Abhängigkeiten.
Der Mechanismus des Lock-in
Die Migration einer Lambda-Funktion zu Azure Functions oder Google Cloud Functions ist nicht trivial. Die Funktionssignaturen unterscheiden sich, die Trigger-Mechanismen sind unterschiedlich, die Integrationen mit anderen Services müssen neu gebaut werden. Eine Anwendung, die DynamoDB nutzt, lässt sich nicht einfach auf MongoDB umstellen; die Datenmodelle und Abfrage-APIs sind grundverschieden.
Dieser Lock-in hat reale Kosten. Wenn der Anbieter die Preise erhöht (was regelmäßig vorkommt), fehlt die Verhandlungsmacht. Wenn ein besseres Angebot am Markt erscheint, sind die Wechselkosten prohibitiv. Ein Anbieter-Wechsel wird zum Mehrjahresprojekt statt zu einer Operations-Aufgabe.
Strategien gegen Lock-in
Vollständige Anbieter-Unabhängigkeit ist illusorisch, zumindest wenn man die Vorteile der Cloud nutzen will. Aber der Grad der Abhängigkeit ist steuerbar.
- Container und Kubernetes: Standardisierte Laufzeitumgebung, portabel zwischen Clouds
- Datenbank-Abstraktionen: ORM-Layer, die Datenbank-Wechsel erleichtern
- Terraform/OpenTofu: Infrastructure-as-Code, das mehrere Anbieter unterstützt
- Multi-Cloud-Architektur: Kritische Komponenten auf mehrere Anbieter verteilen
- Exit-Planung: Regelmäßig prüfen, wie aufwändig ein Anbieterwechsel wäre
Der Trade-off: Portabilität kostet Performance und Entwicklungszeit. Wer Lambda vermeidet, verzichtet auf nahtlose Integration mit anderen AWS-Services. Wer Kubernetes nutzt, hat den Overhead eines komplexen Orchestrators. Die richtige Balance hängt vom Kontext ab.
DSGVO und Datensouveränität: Der transatlantische Konflikt
Die europäische Datenschutz-Grundverordnung (DSGVO) und der amerikanische CLOUD Act stehen in direktem Konflikt. Die DSGVO fordert Kontrolle über personenbezogene Daten; der CLOUD Act erlaubt US-Behörden Zugriff auf Daten amerikanischer Unternehmen, unabhängig davon, wo diese gespeichert sind.
Das Schrems-II-Problem
Das Urteil des Europäischen Gerichtshofs im Fall Schrems II (2020) hat den Privacy-Shield-Rahmen für EU-US-Datentransfers gekippt. Die Begründung: US-Überwachungsgesetze bieten keinen ausreichenden Schutz für EU-Bürger. Der neue Data Privacy Framework (2023) soll das Problem lösen, aber Kritiker warnen vor einem möglichen Schrems III.
Für Unternehmen bedeutet das: Die Nutzung amerikanischer Cloud-Anbieter für personenbezogene Daten ist rechtlich komplex. Theoretisch sind AWS, Azure und Google Cloud DSGVO-konform, wenn Standard Contractual Clauses verwendet werden und zusätzliche technische Maßnahmen (Verschlüsselung mit kundeneigenen Schlüsseln) implementiert sind. Praktisch bleibt ein Restrisiko.
Europäische Alternativen
97 Prozent des europäischen Cloud-Marktes werden von nicht-europäischen Anbietern dominiert. Aber es gibt Alternativen: OVHcloud und Scaleway aus Frankreich, Hetzner und STACKIT aus Deutschland, UpCloud aus Finnland. Diese Anbieter unterliegen ausschließlich europäischem Recht.
Der Trade-off: Das Service-Angebot ist kleiner. Es gibt kein europäisches Äquivalent zu AWS Lambda mit der gleichen Integration in Hunderte andere Services. Die Communities sind kleiner, die Dokumentation ist weniger umfangreich. Für viele Anwendungsfälle (insbesondere in regulierten Branchen) überwiegt jedoch die Rechtssicherheit.
Der EU Data Act (vollständig anwendbar ab 2025-2027) zielt darauf ab, die Abhängigkeit von nicht-europäischen Cloud-Anbietern zu reduzieren. Die Langzeitwirkung bleibt abzuwarten, aber die Tendenz ist klar: Europa will mehr Kontrolle über seine digitale Infrastruktur.
Häufige Fallstricke in der Praxis
Die Kostenbombe Auto-Scaling
Auto-Scaling klingt großartig: Die Infrastruktur wächst mit der Last. Aber ohne Limits kann Auto-Scaling zum Albtraum werden. Ein DDoS-Angriff oder ein fehlerhafter Client, der in einer Schleife Anfragen sendet, kann Tausende von Instanzen starten. Die Angreifer gehen, die Rechnung bleibt. Budget-Alerts und Scaling-Limits sind essentiell.
Die vergessene Dev/Test-Umgebung
Entwicklungs- und Testumgebungen werden aufgesetzt und dann vergessen. Sie laufen rund um die Uhr, obwohl niemand sie nutzt. GPU-Instanzen für ML-Experimente bleiben über das Wochenende aktiv. Alte Snapshots und AMIs sammeln sich an. Regelmäßige Audits und automatisiertes Herunterfahren außerhalb der Arbeitszeiten können erhebliche Kosten sparen.
Das Single-Point-of-Failure-Problem
Die Cloud bietet Hochverfügbarkeit, aber nur wenn man sie nutzt. Eine Anwendung, die in nur einer Availability Zone läuft, ist genauso anfällig wie ein einzelner Server. Die Datenbank ohne Replikation ist ein Single Point of Failure. Hochverfügbarkeit erfordert bewusste Architektur, nicht nur den Umzug in die Cloud.
Ausblick
Die Cloud ist kein Allheilmittel. Sie bietet enorme Vorteile für die richtigen Anwendungsfälle, aber sie bringt auch neue Risiken und Kostenfallen mit sich. Wer informiert entscheidet, kann die Vorteile nutzen und die Fallstricke vermeiden.
Der letzte Teil dieser Serie blickt nach vorne: Edge Computing, Serverless, Green Hosting, Hybrid und Multi-Cloud. Die Hosting-Landschaft entwickelt sich weiter, und einige der heutigen Probleme werden in fünf Jahren anders aussehen. Ein Blick auf die Trends und eine Einschätzung, wohin die Reise geht.
Die wichtigste Erkenntnis dieses Teils: Cloud-Kosten und Cloud-Sicherheit sind keine nachträglichen Überlegungen. Sie müssen von Anfang an mitgedacht werden. Wer erst nach der ersten überraschenden Rechnung oder dem ersten Sicherheitsvorfall reagiert, hat bereits Zeit und Geld verloren.
Weiter mit Teil 5: Ausblick: Die Zukunft des Hostings.
Quellenverzeichnis
[1] Flexera (2024): 'State of the Cloud Report.' Cloud-Budget-Überschreitungen und Kostenmanagement.
[2] CAST AI (2025): 'Kubernetes Cost Benchmark.' Preisvolatilität bei Cloud-Anbietern.
[3] Spacelift/Sprinto/Astra (2025): 'Cloud Security Statistics.' Sicherheitsvorfälle und Breach-Statistiken.
[4] Gartner (2025): 'Cloud Security Predictions.' Verantwortung für Cloud-Sicherheitsfehler.
[5] European Court of Justice (2020): 'Schrems II Decision.' EU-US-Datentransfers.
[6] European Commission (2025): 'EU Data Act.' Regulierung von Cloud-Diensten.
[7] Kyndryl (2025): 'Cloud Readiness Report.' Cloud Repatriation und Hybrid-Strategien.