Das Wichtigste in Kürze
- Storage Classes, Egress-Gebühren, API-Request-Kosten und Übergangsgebühren bilden jeweils eine eigene Abrechnungsebene — der Preis pro GB ist nur der Ausgangspunkt.
- AWS S3 Standard liegt bei rund 23 USD/TB pro Monat; Glacier Deep Archive sinkt auf etwa 1 USD/TB. Diese Spanne zahlt sich aber nur aus, wenn Lifecycle-Richtlinien die Daten korrekt lenken.
- Egress ist in Multi-Cloud-Umgebungen häufig der größte einzelne variable Kostenblock. Cross-Region-Replikation und Transfers zwischen Anbietern verursachen Gebühren, die sich rasch summieren.
- Intelligent Tiering (S3 Intelligent-Tiering, GCP Autoclass) lohnt sich bei unvorhersehbaren workloads. Bei vorhersehbaren workloads sparen manuelle Lifecycle-Regeln mehr.
- Echtzeit-Anomalieerkennung deckt entgleiste Jobs und falsch konfigurierte Richtlinien auf, bevor sie zum Budgetproblem werden. Die monatliche Rechnungsprüfung sieht sie erst danach.
Die meisten Teams haben eine grobe Vorstellung davon, was Cloud-Speicher kosten wird, wenn sie Daten bei mehreren Anbietern abzulegen beginnen. Die Preise pro Gigabyte bei AWS, Azure und Google Cloud lassen sich leicht finden und vergleichen – die tatsächliche Rechnung hängt aber von weit mehr ab als von den reinen Speicherpreisen. Egress-Gebühren, API-Request-Kosten, Storage-Class-Übergänge und Abrufgebühren summieren sich, oft auf eine Weise, die erst sichtbar wird, wenn die Rechnung im Haus ist. Ohne Echtzeit-Transparenz wachsen diese Kosten oft monatelang an, bevor jemand reagiert.
Dieser Beitrag analysiert die größten Kostentreiber im Multi-Cloud-Speicher, vergleicht das Pricing von AWS, Azure und Google Cloud im Detail und zeigt die Strategien, mit denen sich die Ausgaben tatsächlich in den Griff bekommen lassen.
Was treibt Cloud-Speicherkosten wirklich?
Die Speicherabrechnung hat vier klar getrennte Kostenebenen. Sie greifen so ineinander, dass sich die Gesamtsumme allein aus dem GB-Preis kaum vorhersagen lässt.
Storage Classes
Die meisten Teams zahlen zu viel, weil ihre Daten in der falschen Stufe landen. Jeder große Cloud-Anbieter bietet mehrere Storage Classes, deren Preise sich nach der Zugriffshäufigkeit richten: AWS S3 Standard für Hot Data, Glacier Deep Archive für die Archivierung – und mehrere Stufen dazwischen. Google Cloud Storage und Azure Blob Storage folgen demselben Modell.
Die Preisspanne zwischen den Stufen ist beträchtlich. Ein Terabyte in S3 Standard kostet rund 23 USD pro Monat. Dasselbe Terabyte in Glacier Deep Archive nur etwa 1 USD. Diese Einsparung entsteht aber nur, wenn die Daten tatsächlich in die richtige Stufe gelangen. In der Praxis liegen Backups monatelang im Premium-Speicher, ungenutzte Logdateien bleiben ein Jahr lang in Standard, und Disaster-Recovery-Kopien landen in derselben teuren Stufe wie die produktiven Daten.
Datentransfer- und Egress-Gebühren
Eingehender Datentransfer ist bei den Cloud-Anbietern kostenlos – Ingestion in großem Maßstab verursacht trotzdem reale Kosten in Form von Aufwand, Tooling und API-Write-Requests. Ausgehender Datentransfer wird dagegen abgerechnet. Egress-Gebühren fallen immer dann an, wenn Daten zwischen Regionen, zwischen Anbietern oder ins Internet übertragen werden.
In Multi-Cloud-Umgebungen summieren sich diese Gebühren rasch. Eine Disaster-Recovery-Konfiguration, die Daten von AWS nach Azure repliziert, verursacht laufende Transferkosten, die in der Planung regelmäßig unterschätzt werden. Analytics-workloads, die große Datenmengen aus dem Cloud-Speicher zur Verarbeitung an anderer Stelle ziehen, haben dasselbe Problem – ebenso wie Content-Delivery-Pipelines, die Dateien an Nutzer in mehreren Regionen ausliefern.
API- und Request-Kosten
Im großen Maßstab werden API-Request-Kosten zu einem realen Posten. Jeder Read-, Write-, List- oder Delete-Vorgang gegen einen Cloud-Storage-Bucket erzeugt einen abrechenbaren API-Call. Der Preis pro Request ist winzig – Bruchteile eines Cents – doch Migrationen, Batch-Jobs und Disaster-Recovery-Tests treiben das Request-Volumen innerhalb eines einzigen Abrechnungszeitraums schnell in die Millionen.
Ein schlecht optimierter Backup-Job, der unnötige LIST- oder GET-Requests abfeuert, kann hunderte oder tausende Dollar an Request-Gebühren verursachen, bevor jemand etwas merkt. Bei der einzelnen Anfrage wirkt der Betrag unauffällig. Erst aggregiert über den gesamten Job-Lauf wird das Ausmaß sichtbar.
Operativer Aufwand
Multi-Cloud-Speicher verursacht einen Verwaltungsaufwand, der auf keiner Anbieterrechnung auftaucht. Nutzungsüberwachung, Konfiguration von Lifecycle-Richtlinien, Rechnungsprüfung, Anomalieanalyse und Koordination zwischen Accounts kosten Engineering-Zeit – und dieser Aufwand vervielfacht sich mit jeder zusätzlichen Cloud.
Jeder Anbieter hat eigene Tools, dashboards und Abrechnungsformate. Diese Fragmentierung erschwert den Gesamtüberblick und begünstigt, dass sich Waste anhäuft. Für Teams ohne starke Automatisierung und klare FinOps-Praktiken wird der operative Aufwand häufig zu einem der größten versteckten Kostenfaktoren im Multi-Cloud-Speicher.
Wie schneiden AWS, Azure und Google Cloud beim Speicher-Pricing ab?
Auf den ersten Blick bepreisen alle drei Anbieter Object Storage ähnlich. Die Unterschiede bei Übergängen, Egress und Request-Pricing eröffnen aber reale Optimierungschancen für Teams, die workloads über mehrere Clouds hinweg betreiben.
Anbieter
Standard-Speicher
Archiv-Speicher
Egress (erste Stufe)
Mindestdauer Archiv
AWS S3
0,023 USD/GB
~0,004 USD/GB (Glacier Deep Archive)
~0,09 USD/GB
180 Tage
Azure Blob
0,018 USD/GB (Hot Tier)
~0,002 USD/GB (Archive Tier)
~0,087 USD/GB
180 Tage
Google Cloud
0,020 USD/GB (Standard)
~0,001 USD/GB (Archive)
~0,12 USD/GB
Keine
Die angegebenen Preise sind Listenpreise für US-Regionen, Stand März 2025. Aktuelle Preise vor der Budgetplanung auf den Preisseiten von AWS, Azure und Google Cloud prüfen.
Für häufig genutzten Speicher in US-Regionen: AWS S3 Standard startet bei 0,023 USD pro GB und Monat, der Hot Tier von Azure Blob liegt bei 0,018 USD pro GB, und Google Cloud Storage Standard bewegt sich bei rund 0,020 USD pro GB. Alle drei Preise sinken bei höheren Volumina.
Wie unterscheiden sich Storage-Class-Übergänge?
AWS rechnet pro 1.000 zwischen Storage Classes übertragenen Objekten ab. Das Verschieben von Millionen kleiner Dateien kann mehr kosten, als die Maßnahme an Speicherersparnis bringen sollte. Azure und Google Cloud erheben ähnliche Übergangsgebühren mit abweichenden Tarifstrukturen und Mindestspeicherdauern.
Lifecycle-Richtlinien, die Daten in kältere Stufen verschieben, ohne Übergangskosten einzukalkulieren, können unterm Strich teurer ausfallen. Vor jeder großflächigen Tier-Migration sollten Sie die Rechnung anhand der Objektzahl aufmachen.
Wo wird Egress-Pricing teuer?
Beim Egress wird Multi-Cloud-Betrieb teuer. Innerhalb eines einzelnen Anbieters sind Transfers zwischen Diensten in derselben Region kostenfrei. Cross-Region-Replikation und Transfers zwischen Diensten in unterschiedlichen Regionen sind es nie.
AWS und Azure berechnen ausgehende Daten mit volumenabhängig sinkenden Tarifen – die ersten Terabytes pro Monat tragen jedoch den höchsten GB-Preis. Google Cloud bietet historisch wettbewerbsfähigere Egress-Preise und großzügigere Free-Tier-Kontingente für bestimmte Transfertypen.
Für Teams, die Daten zur Disaster Recovery oder für Analysen zwischen Clouds bewegen, wird Egress regelmäßig zum größten variablen Kostenblock auf der Rechnung. Genau deshalb spielt Cloud Financial Planning in Multi-Cloud-Umgebungen eine so wichtige Rolle.
Wie unterscheidet sich das Request-Pricing zwischen den Anbietern?
API-Request-Kosten variieren je nach Anbieter und Storage Class. Ein GET-Request gegen S3 Standard kostet einen Bruchteil eines Cents. Derselbe Request gegen Glacier Flexible Retrieval ist deutlich teurer. Azure und Google Cloud haben jeweils eigene Preiskurven, und die Unterschiede zeigen sich am deutlichsten bei volumenstarken Ereignissen: Migrationen, Bulk-Datenverarbeitung oder Reporting-Läufen zum Quartalsende.
Die Cloud Intelligence Platform von DoiT führt die Speicherkosten aus AWS, Azure und Google Cloud in einer einheitlichen Ansicht zusammen. So lässt sich erkennen, wo die Ausgaben sich konzentrieren und wo Tier-Wechsel oder Anpassungen an workloads echte Einsparungen bringen würden – ohne sich an das Tooling eines einzelnen Anbieters zu binden.
Cloud-Speicherkosten kalkulieren und senken
Die Optimierung von Cloud-Speicher liefert dauerhafte Einsparungen, wenn sie als laufende Praxis verankert wird – nicht als einmalige Aufräumaktion. Beginnen Sie mit einer verlässlichen Baseline, automatisieren Sie, was sich automatisieren lässt, und planen Sie regelmäßige Reviews ein, damit veränderte Zugriffsmuster Ihre Erfolge nicht klammheimlich wieder zunichtemachen.
Mit einer klaren Baseline starten
Was man nicht sieht, kann man nicht optimieren. Bevor Sie etwas verändern, verschaffen Sie sich ein vollständiges Bild der Ausgaben nach Storage Class, Region und workload – nicht nur die monatliche Rechnungssumme.
Jeder Anbieter bringt eigene Cost-Tools mit: AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports. In einer Multi-Cloud-Umgebung führt das manuelle Zusammenfügen dieser Ansichten zu einem unvollständigen Bild und übersieht Cloud-übergreifende Muster. Die meisten Teams stellen fest, dass ihre tatsächlichen Nutzungsprofile deutlich von den ursprünglichen Architekturannahmen abweichen – vor allem bei workloads, die sich über die Zeit weiterentwickelt haben.
DoiT Cloud Analytics führt die Abrechnungsdaten aller drei Anbieter in einer Ansicht zusammen, sodass Cloud-übergreifende Speichervergleiche automatisch sichtbar werden. In Kombination mit FinOps-KPIs rund um Speichernutzung und Waste erhalten Teams einen belastbaren Weg, Fortschritt zu messen – statt Monat für Monat die Rechnung über den Daumen zu peilen.
Wie sollten Sie Lifecycle-Richtlinien umsetzen?
Lifecycle-Regeln verschieben Objekte automatisch in günstigere Storage Classes – basierend auf Alter oder Zugriffsmustern – und löschen sie nach Ablauf der Aufbewahrungsfrist. Alle drei großen Anbieter unterstützen das. Sie richtig zu setzen, erfordert ein hinreichend tiefes Verständnis der eigenen Daten, um Übergangszeitpunkte festzulegen, die der tatsächlichen Nutzung entsprechen.
Eine gut konfigurierte Lifecycle-Richtlinie für Logdaten könnte etwa so aussehen:
- Objekte nach 30 Tagen ohne Lesezugriff in Infrequent-Access-Speicher verschieben
- Nach 90 Tagen in den Archivspeicher übergehen lassen
- Abgelaufene Daten an der definierten Aufbewahrungsgrenze löschen
Der teuerste Lifecycle-Fehler ist nicht die fehlende Richtlinie – sondern ein falsch konfigurierter Filter, der eine vorhandene Richtlinie nicht greifen lässt. Objekte sammeln sich monatelang im Premium-Speicher an, bevor jemand die Rechnung auf die unbemerkt nicht greifende Regel zurückführt.
Verankern Sie eine quartalsweise Überprüfung der Lifecycle-Konfigurationen in Ihrem FinOps-Workflow. Zugriffsmuster verschieben sich mit den Anwendungen, und eine Richtlinie, die vor einem Jahr zu Ihren Daten passte, entspricht möglicherweise nicht mehr dem heutigen Nutzungsverhalten.
Wann ist Intelligent Tiering sinnvoll?
Intelligent Tiering rechnet sich bei workloads, deren Zugriffsmuster wirklich unvorhersehbar sind. AWS S3 Intelligent-Tiering verschiebt Objekte automatisch und nutzungsabhängig zwischen Zugriffsstufen – ohne Abrufgebühr, wenn Daten wieder in eine wärmere Stufe wandern. Google Clouds Autoclass arbeitet ähnlich und verschiebt Objekte ohne Strafgebühren bei früher Löschung. Azure hat mit Smart Tier denselben Ansatz eingeführt, der Stand Anfang 2026 jedoch noch in der Public Preview ist.
Diese Funktionen sind nicht kostenlos. S3 Intelligent-Tiering berechnet eine Monitoring-Gebühr pro Objekt, und Googles Autoclass erhebt eine Verwaltungsgebühr. Bei workloads mit vorhersehbaren Zugriffsmustern liefern manuell konfigurierte Lifecycle-Regeln bessere Einsparungen. Bei großen, gemischt genutzten Buckets, in denen einige Objekte regelmäßig abgerufen werden und andere monatelang unangetastet bleiben, nimmt Intelligent Tiering das Rätselraten ab und spielt seine Kosten in der Regel schnell wieder ein.
Komprimieren und deduplizieren
Kompression und Deduplizierung reduzieren das Datenvolumen, bevor das Cloud-Pricing überhaupt ins Spiel kommt. Die meisten Backup-Tools und Data-Pipeline-Frameworks unterstützen Kompression nativ – das Aktivieren erfordert oft nur eine einzige Konfigurationsänderung.
Die größten Gewinne durch Deduplizierung entstehen, wenn mehrere Systeme ähnliche Daten an unterschiedlichen Speicherorten ablegen. Werden diese redundanten Kopien identifiziert und konsolidiert, lässt sich das gespeicherte Volumen in Umgebungen mit überlappenden Backup- und Archivierungs-workflows um 30 % oder mehr reduzieren.
In Echtzeit überwachen statt im Nachhinein
Monatliche Rechnungs-Reviews lassen Probleme 30 Tage lang anwachsen, bevor jemand sie bemerkt. Ein außer Kontrolle geratener Migrations-Job, der Millionen unerwarteter API-Calls erzeugt, oder eine falsch konfigurierte Lifecycle-Richtlinie, die Daten in eine teure Stufe schiebt, kann wochenlang laufen, ohne in einer monatlichen Abrechnungsprüfung aufzufallen.
Die DoiT-Plattform liefert Echtzeit-Anomalieerkennung und automatisierte Optimierungsempfehlungen über alle drei großen Clouds hinweg. Diese kontinuierliche Sichtbarkeit ist der Unterschied zwischen Teams, die ihre Cloud-Kosten steuern, und Teams, die ihnen hinterherlaufen.
Welche versteckten Kosten übersehen CloudOps-Teams?
Selbst Teams mit etablierten FinOps-Routinen übersehen immer wieder dieselben drei Kostenkategorien. Alle drei stehen irgendwo in der Anbieterdokumentation, tauchen in Budgetgesprächen aber erst dann auf, wenn sie bereits eine spürbare Rechnung verursacht haben.
Cross-Region-Datentransfer
Cross-Region-Replikationsgebühren überraschen die meisten Teams, weil die Kosten pro Vorgang klein wirken, die Summe aber hoch ausfällt. Häufige Datensatz-Updates erzeugen bei jedem Replikationszyklus Egress-Gebühren – bei aktiven Daten können diese den eigentlichen Speicherkosten ebenbürtig werden.
Bei AWS verursacht Cross-Region-Replikation zwei Kostenposten: die Datentransfergebühr und die PUT-Requests, die die Replikate in der Zielregion schreiben. Viele Teams konfigurieren Cross-Region-Replikation beim ersten Deployment und vergessen sie dann – auch wenn die ursprüngliche Geschäftsbegründung längst überholt ist oder die Daten an Bedeutung verloren haben.
API-Kosten während Migrationen
Große Migrationen zwischen Storage Classes, Anbietern oder Regionen erzeugen API-Request-Volumina, die in den meisten Kostenprognosen unterschätzt werden. Eine Migration mit zig Millionen kleiner Objekte kann zusätzlich zu den Transfergebühren Request-Kosten in Höhe mehrerer tausend Dollar verursachen.
Stichproben-Hochrechnungen unterschätzen die realen Kosten meist, weil das API-Call-Volumen mit zunehmender Migrationsgröße schneller wächst als das Datenvolumen. Vor einer großen Migration sollten Sie eine vollständige Trockenlauf-Kostenschätzung anhand der tatsächlichen Objektzahl durchrechnen.
Storage-Class-Übergangsgebühren
Übergangsgebühren können einen kostensparenden Lifecycle-Schritt in eine Mehrausgabe verwandeln. Werden Daten in eine kalte Stufe verschoben und dann häufig abgerufen, kann die Kombination aus Übergangsgebühren und Abrufkosten teurer ausfallen, als ein Verbleib in der ursprünglichen Stufe gewesen wäre.
Strafgebühren bei früher Löschung sind ein zusätzliches Risiko. Glacier hat eine Mindestspeicherdauer von 90 Tagen, Azure Archive von 180 Tagen. Werden Daten vor diesen Mindestzeiten gelöscht, ist die volle Mindestperiode trotzdem zu zahlen. Diese Mindestzeiten gelten auch dann, wenn eine Lifecycle-Regel Daten vorzeitig in eine Löschstufe verschiebt.
Alle drei Kostenkategorien folgen demselben Muster: Sie wachsen schleichend über Dutzende kleiner Posten und bleiben in monatlichen Rechnungsprüfungen unsichtbar. Wenn sie als spürbarer Ausschlag auffallen, summieren sie sich bereits seit Wochen. Echtzeit-Monitoring fängt sie an der Quelle ab.
Cloud-Speicherausgaben in den Griff bekommen
Multi-Cloud-Speicherkosten bleiben beherrschbar, wenn drei Dinge parallel laufen: kontinuierliches Monitoring, das Anomalien in Echtzeit erkennt, automatisierte Lifecycle- und Tiering-Richtlinien, die Daten ohne manuellen Eingriff korrekt lenken, und eine klare Übersicht darüber, wie sich Architekturentscheidungen in der Abrechnung niederschlagen.
Die Cloud Intelligence Platform von DoiT bietet FinOps- und CloudOps-Teams eine einheitliche Sicht auf die Speicherkosten über AWS, Azure und Google Cloud hinweg – inklusive automatisierter Empfehlungen, die für alle drei Anbieter funktionieren. In Kombination mit einer disziplinierten Strategie für Cloud Financial Planning ist das ein praxistauglicher Weg, Multi-Cloud-Speicherkosten unter Kontrolle zu bringen – und dort zu halten.
Wenn Ihre Speicherrechnungen schneller wachsen als Ihre Daten, lohnt sich ein genauerer Blick. Sprechen Sie mit DoiT über Echtzeit-Sichtbarkeit und Kontrolle Ihrer Multi-Cloud-Speicherausgaben.