Azure-Blob-Storage-Preise

Azure Blob Storage Kosten entstehen aus gespeicherten GB je Monat, Zugriffsstufe und Redundanz, aus Operationen je 10.000, aus abgerufenen GB in den kühleren Stufen, aus vorzeitigem Löschen vor der Mindestspeicherdauer und aus dem Datenverkehr, der die Region verlässt. In den meisten Konten dominiert die gespeicherte Menge in der Hot-Stufe, bei Pipelines mit vielen kleinen Objekten die Operationen, und bei Archiven, die jemand lesen will, der Abruf.

Preisdimensionen

Die Stufen unterscheiden sich in der Verfügbarkeit (99,9 % Hot, 99 % Cool, Cold und Archive) und in der Latenz: Hot, Cool und Cold liefern das erste Byte in Millisekunden, Archive ist offline und braucht für die Rehydrierung bis zu 15 Stunden bei Standardpriorität und unter einer Stunde bei hoher Priorität für Objekte unter 10 GB, mit höchstens 10 GiB je Stunde und Speicherkonto im Priority-Modus. Archive gibt es nur mit LRS, GRS oder RA-GRS, nicht mit ZRS, GZRS oder RA-GZRS. Die Smart-Stufe verschiebt Daten selbst zwischen Hot, Cool und Cold, berechnet dafür eine Überwachungsgebühr und verzichtet laut Microsoft auf Gebühren für Stufenwechsel, vorzeitiges Löschen und Rehydrierung. Was die Stufenmodelle der drei Anbieter gemeinsam haben, steht unter Speicherstufen und Lifecycle; der Vergleich mit Block- und Dateispeicher unter Block-, Objekt- und Dateispeicher.

So erscheint es in den Abrechnungsdaten

Im Kostenexport tragen alle Blob-Posten MeterCategory Storage und die Speicherkontoressource als ResourceId; ein Konto erzeugt je Stufe, Redundanz und Metertyp einen eigenen Posten je Tag. Die MeterSubCategory nennt das Produkt, für Block Blobs in General-Purpose-v2-Konten General Block Blob v2, und der MeterName kombiniert Stufe, Redundanz und Metertyp: Hot LRS Data Stored, Cool GRS Data Stored, Cold ZRS Data Stored, Archive LRS Data Stored für die Kapazität, Hot LRS Write Operations, Hot Read Operations, LRS List and Create Container Operations, All Other Operations, Cool LRS Write Operations, Cool Read Operations, Cold LRS Read Operations, Archive Read Operations und Archive Priority Read Operations für die Operationen, Cool Data Retrieval, Cold LRS Data Retrieval, Archive Data Retrieval und Archive Priority Data Retrieval für den Abruf, Cool LRS Early Delete, Cold LRS Early Delete und Archive LRS Early Delete für vorzeitiges Löschen sowie Index Tags für Blob-Index-Tags. Die UnitOfMeasure verrät den Metertyp: 1 GB/Month für Kapazität, 10K für Operationen, 1 GB für Abruf, Early Delete und Replikation.

Die Operationen eines Tages erscheinen als Bruchteile von 10.000, nicht als Anzahl; wer Anfragen zählen will, multipliziert Quantity mit 10.000. Konten mit hierarchischem Namespace, Legacy-Konten vom Typ Blob Storage und Premium-Block-Blob-Konten tragen jeweils ein eigenes Produkt in der MeterSubCategory, der hierarchische Namespace zusätzlich den Meter Index. Ausgehender Datenverkehr ins Internet liegt nicht unter Storage, sondern unter Bandwidth (Azure-Bandbreiten- und Netzwerkpreise); die Geo-Replikation bleibt unter Storage als Datentransfermeter des Kontos. Ein Export selbst, der in ein Speicherkonto schreibt, erzeugt wiederum Schreiboperationen und Kapazität in diesem Konto.

Im FOCUS-Export stehen dieselben Werte in x_SkuMeterCategory (Storage), x_SkuMeterSubcategory (General Block Blob v2) und SkuMeter (der Metername); ServiceName nennt den Dienst, ChargeCategory ist Usage für Verbrauch und Purchase für den Kauf reservierter Kapazität, deren Verbrauchsstunden CommitmentDiscountId tragen. Für Operationsmeter trägt x_PricingBlockSize die Blockgröße aus der Einheit, bei 10K also 10.000, sodass PricingQuantity die abgerechneten Blöcke und ConsumedQuantity die Anfragen zählt. Welche Kontoebene die Kosten trägt, sieht man in Cost Analysis mit dem Filter Service name auf Storage und der Gruppierung nach Ressource; Microsoft nennt den Export als empfohlenen Weg für jede weitere Analyse.

Stellhebel

Konfiguration. Die Zugriffsstufe je Blob ist der größte Hebel: Der Kapazitätspreis fällt von Hot über Cool und Cold zu Archive, während Operationen und Abruf steigen. Die Rechnung lohnt nur, wenn die Mindestdauer eingehalten wird, denn ein Wechsel vor 30, 90 oder 180 Tagen kostet die verbleibenden Tage zum Stufenpreis. Die Standardstufe des Kontos entscheidet, wohin neue Blobs ohne explizite Stufe fallen; ihre Änderung berechnet Schreib- oder Lese- und Abrufoperationen für jeden Blob mit abgeleiteter Stufe. Redundanz kostet Kapazität: GRS verdoppelt den LRS-Preis ungefähr und fügt Replikationstransfer hinzu, ZRS liegt dazwischen; ob Daten eine zweite Region brauchen, ist eine Entscheidung je Konto, weil die Redundanz für alle Dienste des Kontos gilt. Die Hebel über alle Anbieter hinweg beschreibt Speicheroptimierung.

Kaufoption. Reservierte Kapazität für ein oder drei Jahre senkt den Kapazitätspreis für Block Blobs und Data Lake Storage in Standardkonten, deckt aber weder Operationen noch Abruf noch Bandbreite; sie lohnt bei stabilem Volumen, das die Lifecycle-Regeln nicht gerade abbauen (reservierte Kapazität für verwaltete Dienste).

Architektur. Lifecycle-Regeln verschieben Blobs nach Erstellungs-, Änderungs- oder letztem Zugriffsdatum und löschen abgelaufene Versionen und Snapshots; die Richtlinie kostet nichts, bezahlt werden die Set-Blob-Tier-Operationen, und das Verfolgen des letzten Zugriffs berechnet je Objekt höchstens eine Operation in 24 Stunden. Große Objekte statt vieler kleiner senken Operationen und beschleunigen die Rehydrierung. Versionierung und Soft Delete sind Schutz, der Kapazität kostet: Jede Überschreibung erzeugt eine Version oder einen Snapshot, der weiter gespeichert wird. Downloads über ein CDN oder Verarbeitung in derselben Region halten den Verkehr von den Bandbreitenmetern fern (Datentransfer-Optimierung); vergessene Konten, Container und Diagnoseprotokolle ohne Aufbewahrungsfrist gehören zu den ungenutzten und verwaisten Ressourcen. Was Azure Files statt Blobs kostet, steht unter Azure-Files- und NetApp-Files-Preise, was Sicherungen in Blobs ablegen, unter Azure-Backup- und Site-Recovery-Preise.

Wo es schiefgeht

• Early-Delete-Posten nach einem Aufräumen. Eine Lifecycle-Regel oder ein Skript hat Blobs aus Cool, Cold oder Archive gelöscht oder verschoben, bevor 30, 90 oder 180 Tage vergangen waren; auch ein Überschreiben per Put Blob oder Copy Blob zählt. MeterName mit Early Delete prüfen und die Regelfristen an die Mindestdauer anpassen.
• Der Archiv-Abruf kostet mehr als ein Jahr Speicher. Eine Wiederherstellung lief mit hoher Priorität, oder viele kleine Blobs wurden rehydriert, sodass die Leseoperationen je 10.000 den Abruf je GB überstiegen. Archive Priority Read Operations und Archive Read Operations getrennt lesen; Standardpriorität und Copy Blob statt Set Blob Tier verwenden, wenn die 180 Tage noch nicht um sind.
• Die Stufenänderung des Kontos hat einen Tagesposten erzeugt. Die Standardstufe wurde von Hot auf Cool oder zurück gestellt, und jeder Blob mit abgeleiteter Stufe wurde als Schreib- oder Lese- und Abrufoperation berechnet. Stufen künftig je Blob oder je Lifecycle-Regel setzen.
• Operationen übersteigen die Kapazität. Eine Anwendung schreibt Streams in kleinen Blöcken, listet Container in Schleifen oder fragt Metadaten je Datei ab; bei Cold oder Archive wiegt jede Operation ein Vielfaches von Hot. Die Operationsmeter je Konto gegen das Zugriffsmuster stellen und Objekte vor dem Verschieben zusammenfassen.
• Versionen und Snapshots wachsen schneller als die Daten. Versionierung oder Soft Delete ist aktiv, und ein Workload überschreibt dieselben Blobs ständig; jede Überschreibung speichert eine weitere Version. Aufbewahrung kürzen oder häufig überschriebene Daten in ein Konto ohne Versionierung legen.
• Der Archiv-Blob kehrt zurück ins Archiv. Nach einer Rehydrierung per Set Blob Tier blieb das Änderungsdatum alt, und die Lifecycle-Regel hat den Blob wieder archiviert. Der Regel die Bedingung daysAfterLastTierChangeGreaterThan geben oder per Copy Blob rehydrieren.
• Ein Log-Container füllt das Konto. Klassische Storage-Analytics-Protokolle oder Diagnoseexporte laufen ohne Aufbewahrungsfrist weiter. Aufbewahrung setzen und den Container in eine Lifecycle-Regel aufnehmen.

Beispiel

Listenpreise der Azure Retail Prices API in EUR für Germany West Central, Produkt General Block Blob v2 (flacher Namespace), gelesen am 2026-10-21: Gespeicherte Daten kosten je GB und Monat mit LRS 0,0172 EUR in Hot für die ersten 51.200 GB (0,0165 EUR bis 512.000 GB, 0,0158 EUR darüber), 0,0088 EUR in Cool, 0,004 EUR in Cold und 0,0016 EUR in Archive; mit ZRS 0,0198 EUR in Hot, 0,0115 EUR in Cool und 0,0044 EUR in Cold, mit GRS 0,0345 EUR in Hot, 0,0176 EUR in Cool, 0,0071 EUR in Cold und 0,0025 EUR in Archive, mit RA-GRS 0,0431 EUR in Hot und 0,022 EUR in Cool (die Hot-Preise jeweils für die ersten 51.200 GB). Je 10.000 Operationen kosten mit LRS Schreibvorgänge 0,0475 EUR in Hot, 0,088 EUR in Cool, 0,1584 EUR in Cold und 0,1056 EUR in Archive; Lesevorgänge 0,0038 EUR in Hot, 0,0088 EUR in Cool, 0,088 EUR in Cold und 4,7298 EUR in Archive, als Priority-Abruf 57,1982 EUR; Listen und Container anlegen 0,0475 EUR und alle übrigen Operationen 0,0038 EUR in Hot. Der Datenabruf kostet je GB 0,0088 EUR aus Cool, 0,0264 EUR aus Cold, 0,0211 EUR aus Archive und 0,1144 EUR als Priority-Abruf; vorzeitiges Löschen je GB und verbleibendem Monatsanteil 0,0088 EUR in Cool, 0,004 EUR in Cold und 0,0016 EUR in Archive. Ein GB liegt in Archive für ein Jahr bei 0,0192 EUR, ein einziger Standardabruf desselben GB kostet 0,0211 EUR und ein Priority-Abruf 0,1144 EUR: Archive lohnt sich für Daten, die fast nie gelesen werden, und die Lesevorgänge je 10.000 machen viele kleine Objekte dort teurer als wenige große.

Quellen

Gelesen am 2026-10-21. Microsoft Learn: Zugriffsstufen für Blob-Daten, Rehydrierung aus der Archivstufe, Lifecycle-Management, Redundanz in Azure Storage, Kosten für Azure Blob Storage planen und verwalten, Felder der Kostendetails, FOCUS-Schema des Kostenexports. Preise: Azure Retail Prices API in EUR, General Block Blob v2 in Germany West Central.