IT-Wissen · Azure Storage

Azure GPv1 und Legacy Blob Storage: Migration auf GPv2 ohne ungeplante Mehrkosten

Kurz zusammengefasst: Azure GPv1 und ältere Blob-Storage-Konten sollten aktiv auf GPv2 umgestellt werden. Der Wechsel erfolgt in der Regel ohne Datenkopie und ohne geplante Ausfallzeit, verändert aber die Abrechnung für Blob Storage. Wer vorab Transaktionen, Zugriffe, Datenverkehr, Redundanz und Aufbewahrung prüft, kann die Migration kontrolliert durchführen und unerwartete Mehrkosten vermeiden.

Nutzen und Einordnung

Azure Blob Storage speichert unstrukturierte Daten wie Dokumente, Sicherungen, Medien, Exporte und Archivdateien. General Purpose v1, kurz GPv1, ist ein älterer Kontotyp. General Purpose v2, kurz GPv2, ist das von Microsoft empfohlene Modell für aktuelle Azure-Storage-Szenarien.

GPv2 eröffnet Funktionen wie Blob-Zugriffsebenen und Lifecycle Management. Damit lassen sich Daten abhängig von Zugriffshäufigkeit und Aufbewahrungsdauer organisieren. Für kleine Unternehmen und den Mittelstand ist die Migration deshalb nicht nur eine technische Pflichtaufgabe, sondern eine Gelegenheit, Kosten, Aufbewahrung und Verantwortlichkeiten neu zu ordnen.

Der entscheidende Punkt: Ein Upgrade auf GPv2 bedeutet nicht automatisch eine niedrigere Rechnung. Die Speicherkosten können sinken, während Transaktions-, Zugriffs- oder Datenverkehrskosten bei bestimmten Workloads steigen. Die Wirtschaftlichkeit muss deshalb aus realen Nutzungsdaten abgeleitet werden.

Warum die Umstellung jetzt geplant werden sollte

Microsoft kündigt die Ablösung von GPv1 an. Bestehende GPv1-Konten sollen bis zum 13. Oktober 2026 auf GPv2 umgestellt werden. Wer nicht rechtzeitig selbst migriert, muss mit einer automatischen Umstellung durch Microsoft rechnen. Das nimmt dem Unternehmen die Möglichkeit, den Zeitpunkt, die Kostenprüfung und die anschließende Kontrolle selbst zu bestimmen.

Die Umstellung ist dauerhaft. Ein Upgrade von GPv1 auf GPv2 kann nicht zurückgenommen werden. Deshalb gehören die Prüfung der Anwendungen, die Kostenmodellierung und ein dokumentierter Änderungsplan vor die technische Aktion.

Auch ältere Blob-Storage-Konten können auf GPv2 aktualisiert werden. Das betrifft dabei die Blob-Storage-Abrechnung. Azure Files und Azure Disks haben jeweils eigene Preismodelle und werden durch die Änderung des Kontotyps nicht automatisch nach demselben Schema abgerechnet.

Alle Konten und Kontotypen mit Azure Resource Graph, Azure CLI, PowerShell oder dem Portal erfassen.
Konten nach produktiver Bedeutung, Datenart und verantwortlicher Anwendung priorisieren.
Ein Upgrade-Fenster, einen Rückfallplan für die Anwendung und einen Prüfplan für die erste Abrechnung festlegen.

Welche Kosten sich verändern können

GPv2 verwendet für Block Blobs eine stärker nach Zugriffsebene und Vorgang differenzierte Abrechnung. Neben der gespeicherten Kapazität können Lese-, Schreib- und Listenoperationen, Datenabrufe, ausgehender Datenverkehr sowie bei geo-redundanten Konten die Datenübertragung zur Replikation relevant sein.

Besonders kritisch sind Workloads mit sehr vielen kleinen Objekten oder häufigen Lese- und Schreibvorgängen. Eine geringere Kapazitätsgebühr kann dann durch höhere Transaktionskosten überkompensiert werden. Ebenso können Anwendungen, die Daten regelmäßig aus kühleren Ebenen abrufen, höhere Zugriffskosten verursachen.

Für eine belastbare Rechnung werden mindestens die aktuelle Kapazität, Objektanzahl, Vorgänge pro Monat, typische Objektgrößen, Lese- und Schreibmuster, ausgehender Datenverkehr, Region, Redundanz und Vertragskonditionen benötigt. Die Werte sollten aus Azure-Metriken, Kostenanalyse, Rechnungen und – sofern vorhanden – Storage-Logs stammen. Anschließend werden sie im Azure Pricing Calculator oder im Microsoft-Kostenkalkulator für GPv1 zu GPv2 modelliert.

Vertragsrabatte, Steuern und individuelle Konditionen können von öffentlichen Preisangaben abweichen. Eine Kalkulation mit Listenpreisen ist daher eine Entscheidungsgrundlage, aber keine verbindliche Rechnung.

Zugriffsebenen sachlich auswählen

Die Hot-Ebene ist für häufig gelesene oder geänderte Daten vorgesehen. Cool eignet sich für seltener genutzte Online-Daten, Cold für selten abgerufene Daten mit weiterhin schneller Verfügbarkeit. Archive ist eine Offline-Ebene für Daten, die nur sehr selten benötigt werden und bei denen eine Wiederherstellung mit deutlich längerer Latenz akzeptabel ist.

Kühlere Ebenen haben niedrigere Speicherkosten, aber höhere Zugriffs- und Transaktionskosten. Für GPv2 gelten bei Cool und Cold empfohlene Mindestaufbewahrungsdauern von 30 beziehungsweise 90 Tagen; für Archive sind mindestens 180 Tage vorgesehen. Wird ein Blob zu früh gelöscht oder wieder in eine wärmere Ebene verschoben, können Gebühren für vorzeitige Löschung entstehen.

Archive ist nicht unmittelbar lesbar. Ein Blob muss zunächst in eine Online-Ebene rehydriert werden; das kann bis zu 15 Stunden dauern. Für operative Dokumente, kurzfristig benötigte Sicherungen oder Dateien mit unklarer Zugriffshäufigkeit ist diese Ebene daher nur nach einer konkreten Prüfung geeignet.

Lifecycle Management mit Kontrolle einsetzen

Lifecycle Management kann Blobs abhängig von Alter, Präfixen, Index-Tags oder Versionen in andere Ebenen verschieben oder löschen. Das ist hilfreich, wenn Datenklassen und Aufbewahrungsfristen eindeutig definiert sind. Eine Regel sollte immer einen fachlichen Zweck, einen Verantwortlichen und eine überprüfbare Testmenge haben.

Die Lifecycle-Funktion selbst ist kostenlos. Die von ihr ausgelösten Vorgänge, insbesondere das Setzen einer Zugriffsebene, können jedoch normale Operationskosten verursachen. Bei kleinen Objekten kann der Kostenvorteil einer Umstufung durch Transaktionskosten geringer sein oder entfallen.

Versionierung, Snapshots und Soft Delete müssen in die Betrachtung einbezogen werden. Gelöschte oder alte Versionen können weiterhin Speicher belegen. Außerdem muss geprüft werden, ob die Backup-Software bereits eigene Aufbewahrungs- und Tiering-Regeln besitzt. Zwei voneinander unabhängige Automatismen können sonst widersprüchliche Fristen oder unerwartete Datenbewegungen erzeugen.

Kontrollierter Ablauf und Prüfung danach

Vor dem Upgrade wird das Konto vollständig dokumentiert: Region, Performance, Redundanz, Verschlüsselung, Netzwerkregeln, Private Endpoints, öffentliche Zugriffseinstellungen, Container, Datenmengen, Zugriffsebenen, Schutzfunktionen, Lifecycle-Regeln und abhängige Dienste.

Danach werden Anwendungen und Automatisierungen geprüft. Dazu gehören SDKs, Verbindungszeichenfolgen, Kontoschlüssel, Shared Access Signatures, Infrastructure-as-Code, Deployment-Pipelines, Backup-Jobs, Skripte und Monitoring. Die meisten Anwendungen benötigen keine Codeänderung, feste Annahmen über den Kontotyp oder die Kostenlogik müssen aber erkannt werden.

Das Upgrade kann über Portal, Azure CLI oder PowerShell ausgelöst werden. Nach der Umstellung werden Upload, Download, Listenoperationen, Löschung, Backup, Wiederherstellung und Berechtigungen mit einem repräsentativen Test geprüft. Anschließend werden Metriken, Logs, Kostenanalyse und die nächste Rechnung mit den vorher festgelegten Erwartungen verglichen.

Lifecycle-Regeln und neue Zugriffsebenen sollten erst nach dieser Basiskontrolle aktiviert oder erweitert werden. So bleibt nachvollziehbar, ob eine Kostenänderung aus dem Kontotyp-Upgrade, aus Tiering, aus einem Anwendungslauf oder aus verändertem Datenverkehr stammt.

Beispiel aus der Praxis

Beispiel: Ein mittelständischer Betrieb nutzt ein GPv1-Konto für tägliche ERP-Exporte, Projektunterlagen und Sicherungsdateien. Zuerst werden Container, Objektmengen, Zugriffshäufigkeit, Datenwachstum, Redundanz, Backup-Aufbewahrung und ausgehender Datenverkehr erfasst. Die täglich benötigten ERP-Exporte bleiben in Hot. Ältere Projektunterlagen werden nur dann nach Cool verschoben, wenn die Abrufhäufigkeit und Aufbewahrungsdauer die zusätzlichen Zugriffsbedingungen rechtfertigen. Für Sicherungen wird eine getrennte Regel definiert, damit die Azure-Lifecycle-Logik nicht mit der Retention der Backup-Software kollidiert. Nach dem dauerhaften GPv1-zu-GPv2-Upgrade werden die ERP-Anbindung, geplante Jobs, Berechtigungen, ein Wiederherstellungstest und die Kostenentwicklung kontrolliert. Das ist ein realistischer Prüf- und Umsetzungsweg, keine Kundenreferenz.

Chancen für Unternehmen

GPv2 ermöglicht aktuelle Funktionen wie Zugriffsebenen und Lifecycle Management.
Gemessene Transaktions-, Abruf- und Datenverkehrswerte schaffen eine belastbarere Kostenbasis.
Alte Kontotypen können in ein einheitlicheres Azure-Betriebsmodell überführt werden.
Aufbewahrung, Wiederherstellung und Kostenverantwortung lassen sich zwischen IT, Fachbereich und Management klarer zuordnen.
Die Migration kann mit einer Prüfung von Netzwerkzugriff, Identitäten, Schlüsselverwaltung und Monitoring verbunden werden.

Grenzen und Prüfpunkte

Das Upgrade allein garantiert keine Kostensenkung. Bei vielen Lese-, Schreib- oder Listenoperationen können die Transaktionskosten steigen.
Die konkrete Rechnung hängt unter anderem von Region, Redundanz, Workload, Vertrag, Rabatten und gewählten Optionen ab.
Cool, Cold und Archive sind nicht für jedes Zugriffsmuster geeignet. Abrufkosten und mögliche Gebühren bei vorzeitiger Umstufung oder Löschung müssen berücksichtigt werden.
Archive bringt eine Wiederherstellungslatenz von bis zu 15 Stunden mit sich und ist daher nicht für kurzfristig benötigte Daten geeignet.
Lifecycle Management kann durch ausgelöste Vorgänge Kosten verursachen; kleine Objekte sind nicht automatisch wirtschaftlich umzustufen.
Versionierung, Snapshots, Soft Delete und parallele Backup-Regeln können zusätzliche Datenbestände oder widersprüchliche Aufbewahrungen erzeugen.
Das Upgrade ersetzt keine Anwendungs-, Sicherheits-, Backup- oder Wiederherstellungsprüfung.