Azure Blob Storage Smart Tier: Automatisches Tiering ohne Lifecycle-Regeln

Azure Blob Storage Smart Tier: Automatisches Tiering ohne Lifecycle-Regeln
© Microsoft (Azure)

Seit Mitte April 2026 ist Smart Tier für Azure Blob Storage und Azure Data Lake Storage Gen2 offiziell General Available. Hinter dem Namen steckt ein Plattformdienst, der Objekte automatisch zwischen den Capacity-Tiers Hot, Cool und Cold verschiebt, anhand der tatsächlichen Zugriffsmuster und ohne dass dafür Lifecycle-Management-Policies geschrieben oder gepflegt werden müssen. [1][2]

Für Storage-Accounts, deren Zugriffsverhalten nicht stabil vorhersagbar ist oder sich über die Zeit verändert, ist das ein interessanter Hebel. Die alte Frage "Wie alt darf ein Objekt werden, bevor wir es nach Cool schieben?" entfällt, weil die Plattform sich an realen Get- und Put-Operationen orientiert.

Smart Tier: automatisches Tiering nach Zugriffsmustern

Funktionsweise des Tierings

Neu geschriebene Objekte landen zunächst im Hot Tier. Wird ein Objekt 30 Tage lang nicht angefasst, wandert es in den Cool Tier. Nach weiteren 60 Tagen ohne Zugriff, also insgesamt 90 Tagen Inaktivität, übersiedelt es in den Cold Tier. Wird das Objekt zu irgendeinem Zeitpunkt wieder gelesen oder neu geschrieben, springt es sofort zurück in den Hot Tier und der Timer beginnt von vorn. [2]

Was als Zugriff gewertet wird, ist klar definiert. Get Blob und Put Blob aktualisieren die Last-Access-Time und triggern damit den Rücksprung. Get Blob Properties, Get Blob Metadata und Get Blob Tags hingegen zählen ausdrücklich nicht als Access-Operation. Reine Metadaten-Abfragen, etwa aus Listings oder Inventory-Tools, verändern das Tiering also nicht.

Eine Sonderbehandlung gibt es für Kleinst-Objekte. Blobs unter 128 KiB bleiben dauerhaft im Hot Tier ("SmartHot-small") und tieren gar nicht erst nach unten. Hintergrund ist das Pricing-Modell der kühleren Tiers, in dem Mindestabrechnungs-Größen den Capacity-Vorteil bei sehr kleinen Objekten weitgehend aufzehren würden. [2]

Abrechnungsweise vom Smart Tier

Smart Tier hat keinen eigenen Capacity-Meter. Abgerechnet wird ein Objekt zu jedem Zeitpunkt mit dem Preis des Capacity-Tiers, in dem es gerade liegt, also zur Hot-, Cool- oder Cold-Rate. Innerhalb von Smart Tier entfallen dabei die klassischen Nebenkosten eines Tier-Wechsels. Es gibt keine Tier-Transition-Gebühr beim Wechsel zwischen den Capacity-Tiers, keine Early-Deletion-Fee und keine Data-Retrieval-Charge. [2]

Bezahlt wird hingegen eine Monitoring-Gebühr, berechnet pro 10.000 verwaltete Objekte über 128 KiB pro Monat. Objekte unter dieser Schwelle erzeugen weder Tiering-Bewegung noch Monitoring-Gebühr. Access-Operations gegen Smart-Tier-Objekte werden zu Hot-Tier-Konditionen verrechnet, einschließlich des Wieder-Aufstiegs aus Cool oder Cold. [2]

Beim Rollout-Plan ist die Richtung des Wechsels relevant. Das Verschieben bestehender Objekte in Smart Tier hinein erzeugt keine Transition-Transaktion. Das Verschieben hinaus, etwa wenn ein Account später wieder auf einen festen Default-Tier umgestellt wird, kostet pro Objekt eine Cool-Write-Transaktion. Einmal explizit auf einen festen Tier gesetzt, lässt sich ein Objekt nicht mehr unter Smart-Tier-Verwaltung holen.

Voraussetzungen und Einschränkungen

Smart Tier funktioniert nur auf Standard general-purpose-v2-Accounts und nur in Verbindung mit zone-redundanter Replikation, also ZRS, GZRS oder RA-GZRS. LRS- und GRS-Accounts sind außen vor, ältere GPv1- oder Premium-Accounts ebenfalls. Unterstützt sind ausschließlich Block Blobs. Page Blobs und Append Blobs bleiben außerhalb. [2]

In Public Preview verbleibt Smart Tier in Israel Central, Qatar Central und UAE North sowie in den Azure-Government-Regionen und in Azure operated by 21Vianet. In allen übrigen zonalen Public-Cloud-Regionen ist das Feature regulär verfügbar.

Im Zusammenspiel mit den bestehenden Tiering-Mechanismen verhält sich Smart Tier eigenständig. Lifecycle-Management-Regeln greifen für Smart-Tier-Objekte nicht mehr an die Tiering-Bewegung, wirken aber weiterhin für Delete-Aktionen. Storage Actions können das Tiering von Smart-Tier-Objekten gar nicht steuern. Wer bisher Lifecycle-Policies parallel pflegt, sollte deren Verhalten gegenüber dem Smart-Tier-Bestand vor der Aktivierung einmal explizit prüfen. [2]

Den Archive Tier steuert Smart Tier nicht an. Wer regelmäßig Daten ins Archiv ablegen möchte, braucht dafür weiterhin eine eigene Lifecycle-Policy oder Storage-Action, mit Smart Tier zusammen lässt sich das nicht abbilden.

Aktivierung und Migration

Der Schalter sitzt auf Account-Ebene. Wird der Default-Account-Access-Tier auf "Smart" gesetzt, übernehmen alle Blobs ohne explizit gesetzten Tier automatisch Smart-Tier-Verwaltung. Blobs mit einem manuell gesetzten Tier bleiben unangetastet. Im Portal findet sich die Einstellung beim Anlegen unter "Advanced", für bestehende Accounts unter Configuration als "Blob access tier (default)". [2]

Per PowerShell oder Azure CLI führt der Weg derzeit über einen direkten REST-API-Call gegen die Storage-Resource-Provider-API in Version 2025-08-01. Microsoft dokumentiert die Patch-Operation auf das Feld accessTier mit dem Wert "Smart" auf der zugehörigen Learn-Seite.

Wann ist Smart Tier zu verwenden und wann nicht?

Smart Tier zielt auf Workloads, deren Zugriffsmuster nicht stabil vorhersagbar sind oder deren Lifecycle-Pflege bisher mehr Aufwand verursacht hat, als die Einsparung wert war. Klassische Kandidaten sind generische Datentöpfe, Backups mit gemischtem Zugriffsverhalten oder Data-Lake-Bereiche, in denen Daten phasenweise heiß und phasenweise still sind.

Weniger sinnvoll ist Smart Tier dort, wo das Tiering-Verhalten ohnehin klar ist und sich präzise per Lifecycle-Policy abbilden lässt, etwa bei Logs mit fixer Aufbewahrungsfrist und planbarem Cold-Wechsel. Genauso wenig passt es zu Szenarien, die zwingend Archive Tier brauchen, oder zu Storage-Accounts mit überwiegend kleinen Objekten unter 128 KiB, die in Smart Tier ohnehin im Hot Tier liegen bleiben.

Quellenangaben

Weiterlesen

Azure Red Hat OpenShift in Austria East: Container-Plattform jetzt direkt in Wien

Azure Red Hat OpenShift in Austria East: Container-Plattform jetzt direkt in Wien

Im April 2026 ist Azure Red Hat OpenShift offiziell in der Microsoft-Cloud-Region Austria East verfügbar geworden. Damit lässt sich eine der ausgereiftesten Enterprise-Container-Plattformen am Markt jetzt direkt aus der österreichischen Azure-Region heraus betreiben, mit lokaler Datenhaltung, drei Verfügbarkeitszonen und einem von Microsoft und Red Hat gemeinsam betriebenen Managed Service. [1]

Von Indeno GmbH