Zugriffsebenen für Blobdaten

  • Artikel

Die Speicherung von Daten in der Cloud nimmt immer mehr zu. Um die Kosten für die zunehmenden Speicheranforderungen im Blick zu behalten, kann es hilfreich sein, die Daten anhand ihrer Zugriffshäufigkeit und Aufbewahrungsdauer zu organisieren. Azure Storage weist verschiedene Zugriffsebenen auf, sodass Sie Blobdaten basierend auf ihrer Verwendung auf die kostengünstigste Weise speichern können. Folgende Azure Storage-Zugriffsebenen stehen zur Verfügung:

  • Heiße Zugriffsebene: Onlineebene, die für die Speicherung von Daten optimiert ist, auf die häufig zugegriffen wird oder die häufig geändert werden. Die heiße Ebene hat die höchsten Speicherkosten, aber auch die niedrigsten Zugriffskosten.
  • Kalte Zugriffsebene: Onlineebene, die für die Speicherung von Daten optimiert ist, auf die nicht häufig zugegriffen wird oder die nicht häufig geändert werden. Daten auf der kalten Ebene sollten für mindestens 30 Tage gespeichert werden. Für die kalte Ebene fallen im Vergleich zur heißen Ebene niedrigere Speicherkosten, aber höhere Zugriffskosten an.
  • Ebene „Cold“ – Eine Onlineebene, die für das Speichern von Daten optimiert ist, auf die nur selten zugegriffen wird oder die selten geändert werden, die jedoch schnell abrufbar sein müssen. Daten auf der Ebene „Cold“ sollten für mindestens 90 Tage gespeichert werden. Für die Ebene „Cold“ fallen im Vergleich zur kalten Ebene niedrigere Speicherkosten und höhere Zugriffskosten an.
  • Archivebene – Eine Offline-Dienstebene, welche für die Speicherung von Daten optimiert ist, auf die nur selten zugegriffen wird und die flexible Wartezeitanforderungen in der Größenordnung von Stunden aufweist. Daten auf Archivzugriffsebene müssen mindestens 180 Tage lang gespeichert werden.

Azure Storage-Kapazitätsgrenzen werden auf Kontoebene und nicht nach Zugriffsebene festgelegt. Sie können die Kapazitätsauslastung auf einer Ebene maximieren oder die Kapazität auf zwei oder mehr Ebenen verteilen.

Hinweis

Das Festlegen der Zugriffsebene ist nur für Blockblobs gestattet. Für Anfüge- und Seitenblobs wird dies nicht unterstützt.

Onlinezugriffsebenen

Wenn Ihre Daten in einer Onlinezugriffsebene („heiß“, „kalt“ oder „Cold“) gespeichert sind, können Benutzer sofort darauf zugreifen. Die heiße Ebene ist die beste Wahl für Daten, die aktiv verwendet werden. Die kalte Ebene oder die Ebene „Cold“ sind ideal für Daten, auf die seltener zugegriffen wird, die aber dennoch für Lese- und Schreibvorgänge verfügbar sein müssen.

Beispielszenarien für die Verwendung der heißen Zugriffsebene:

  • Daten, die aktiv verwendet werden, oder Daten, für die erwartungsgemäß häufig Lese- und Schreibvorgänge ausgeführt werden.
  • Daten, die zur Verarbeitung und späteren Migration zur kalten Zugriffsebene bereitgestellt werden.

Zu den Verwendungsszenarien für die Zugriffsebenen „kalt“ und „Cold“ gehören:

  • Kurzfristige Datensicherung und Notfallwiederherstellung
  • Ältere Datasets, die nicht häufig verwendet werden, aber für den sofortigen Zugriff verfügbar sein müssen.
  • Umfangreiche Datasets, die kostengünstig gespeichert werden müssen, während andere Daten zur Verarbeitung gesammelt werden

Informationen zum Verschieben eines Blobs auf die Ebene heiß, kalt oder „Cold“ finden Sie unter Festlegen der Zugriffsebene eines Blobs.

Daten der kalten Ebene oder der Ebene „Cold“ weisen eine etwas geringere Verfügbarkeit auf, bieten aber Dauerhaftigkeit, Abrufwartezeit und Durchsatz auf dem gleichen hohen Niveau wie bei der heißen Ebene. Daher kann bei Daten der kalten Ebene oder der Ebene „Cold“ eine Kombination aus etwas geringerer Verfügbarkeit und höheren Zugriffskosten im Vergleich zur heißen Ebene in Kauf genommen werden, da im Gegenzug die Gesamtspeicherkosten geringer ausfallen. Weitere Informationen finden Sie unter SLA für Speicher.

Für Blobs fällt eine Gebühr für frühzeitiges Löschen an, wenn sie gelöscht, überschrieben oder auf eine andere Ebene verschoben werden, bevor die Mindestanzahl von Tagen, die für die Ebene erforderlich sind, vergangen ist. Für ein Blob auf der kalten Ebene in einem Konto vom Typ „Universell v2“ fällt beispielsweise eine Gebühr für frühzeitiges Löschen an, wenn es vor Ablauf von 30 Tagen gelöscht oder auf eine andere Ebene verschoben wird. Für ein Blob in der kalten Ebene oder der Ebene „Cold“ gilt die Löschstrafe, wenn es gelöscht oder auf eine andere Ebene verschoben wird, bevor 90 Tage verstrichen sind. Diese Gebühr fällt anteilig an. Wenn ein Blob beispielsweise auf die kalte Ebene verschoben und dann nach 21 Tagen gelöscht wird, fällt eine Gebühr für frühzeitiges Löschen an, die den 9 Tagen (30 – 21) der Speicherung dieses Blobs in der kalten Ebene entspricht. Gebühren für frühe Löschungen treten auch auf, wenn das gesamte Objekt über einen beliebigen Vorgang (d. h. Put Blob, Put Block List oder Copy Blob) innerhalb des angegebenen Zeitfensters neu geschrieben wird.

Hinweis

In einem Konto, für das vorläufiges Löschen aktiviert ist, wird ein Blob nach dem Löschen als gelöscht betrachtet, und der Aufbewahrungszeitraum läuft ab. Bis zum Ablauf dieses Zeitraums ist das Blob nur vorläufig gelöscht, und es fällt keine Gebühr für frühzeitiges Löschen an.

Die Ebenen „heiß“, „kalt“ oder „Cold“ unterstützten alle Redundanzkonfigurationen. Weitere Informationen zu Datenredundanzoptionen in Azure Storage finden Sie unter Azure Storage-Redundanz.

Zugriffsebene „Archiv“

Die Archivebene ist eine Offlineebene für die Speicherung von Daten, auf die nur selten zugegriffen wird. Die Zugriffsebene „Archiv“ weist die niedrigsten Speicherkosten auf. Diese Ebene verursacht jedoch höhere Kosten für den Datenabruf und eine höhere Wartezeit im Vergleich zu den Ebenen „heiß“, „kalt“ oder „Cold“. Beispielszenarien für die Verwendung der Archivzugriffsebene:

  • Langfristige Sicherung, sekundäre Sicherung und Archivierungsdatasets
  • Originaldaten (Rohdaten), die auch nach der Umwandlung in ein endgültiges verwendbares Format erhalten bleiben müssen
  • Compliance- und Archivdaten, die über einen langen Zeitraum gespeichert werden müssen und auf die selten zugegriffen wird

Informationen zum Verschieben eines Blobs in die Archivebene finden Sie unter Archivieren eines Blobs.

Die Daten müssen sich mindestens 180 Tage lang auf der Archivspeicherebene befinden, sonst unterliegen sie einer Gebühr für frühe Löschung. Wenn ein Blob beispielsweise auf die Archivebene verschoben und dann nach 45 Tagen gelöscht oder auf die heiße Ebene verschoben wird, wird Ihnen eine Gebühr für frühzeitiges Löschen berechnet, die den 135 Speichertagen (180–45) dieses Blobs auf der Archivebene entspricht.

Hinweis

In einem Konto, für das vorläufiges Löschen aktiviert ist, wird ein Blob nach dem Löschen als gelöscht betrachtet, und der Aufbewahrungszeitraum läuft ab. Bis zum Ablauf dieses Zeitraums ist das Blob nur vorläufig gelöscht, und es fällt keine Gebühr für frühzeitiges Löschen an.

Solange sich ein Blob auf der Archivebene befindet, kann es nicht gelesen oder geändert werden. Um ein Blob, das sich auf der Archivebene befindet, lesen oder herunterladen zu können, müssen Sie es zunächst auf einer Onlineebene aktivieren, entweder „heiß“, „kalt“ oder „Cold“. Abhängig von der Priorität, die Sie für den Aktivierungsvorgang angeben, kann es bis zu 15 Stunden dauern, bis die Daten auf der Archivebene aktiviert sind. Weitere Informationen zur Blobaktivierung finden Sie unter Übersicht über die Aktivierung von Blobs aus der Archivebene.

Die Metadaten eines archivierten Blobs bleiben für den Lesezugriff verfügbar, sodass Sie das Blob und seine Eigenschaften, Metadaten und Indextags auflisten können. Die Metadaten von Blobs auf Archivebene sind schreibgeschützt, Blobindextags können dagegen gelesen oder geschrieben werden. Die Speicherkosten für Metadaten archivierter Blobs werden zu den Tarifen der kalten Ebene abgerechnet. Momentaufnahmen werden für archivierte Blobs nicht unterstützt.

Für Blobs auf der Archivebene werden folgende Vorgänge unterstützt:

Nur Speicherkonten, die für LRS, GRS oder RA-GRS konfiguriert sind, unterstützen das Verschieben von Blobs in die Archivebene. Die Archivebene wird für ZRS-, GZRS- oder RA-GZRS-Konten nicht unterstützt. Weitere Informationen zu Redundanzkonfigurationen in Azure Storage finden Sie unter Azure Storage-Redundanz.

Um die Redundanzkonfiguration für ein Speicherkonto zu ändern, das Blobs in der Archivebene enthält, müssen Sie zunächst alle archivierten Blobs in der Ebene „heiß“, „kalt“ oder „Cold“ aktivieren. Da Aktivierungsvorgänge kosten- und zeitaufwändig sein können, empfiehlt Microsoft, die Redundanzkonfiguration für ein Speicherkonto mit archivierten Blobs möglichst nicht zu ändern.

Die Migration eines Speicherkontos von LRS zu GRS wird unterstützt, solange keine Blobs in die Archivebene verschoben wurden, während das Konto für LRS konfiguriert war. Ein Konto kann zurück in GRS verschoben werden, wenn die Aktualisierung weniger als 30 Tage nach der Umstellung des Kontos auf LRS erfolgt und keine Blobs auf die Archivebene verschoben wurden, während das Konto auf LRS festgelegt war.

Einstellung für die Standardzugriffsebene eines Kontos

Speicherkonten verfügen über eine Einstellung für die Standardzugriffsebene, mit der die Onlineebene angegeben wird, auf der ein neues Blob erstellt wird. Die Einstellung für die Standardzugriffsebene kann auf die heiße oder die kalte Ebene festgelegt werden. Sie können die Standardeinstellung für ein einzelnes Blob überschreiben, wenn Sie das Blob hochladen oder die zugehörige Ebene ändern.

Die Standardzugriffsebene für ein neues universelles v2-Speicherkonto ist standardmäßig auf die Hot Tier eingestellt. Sie können die Einstellung für die Standardzugriffsebene beim oder nach dem Erstellen eines Speicherkontos ändern. Wenn Sie diese Einstellung im Speicherkonto nicht ändern oder die Ebene beim Hochladen eines Blobs nicht explizit festlegen, wird ein neues Blob standardmäßig auf die heiße Ebene hochgeladen.

Für ein Blob, dem keine explizite Ebene zugewiesen ist, wird die zugehörige Ebene von der Einstellung für die Standardzugriffsebene des Kontos abgeleitet. Wenn die Zugriffsebene eines Blobs von der Einstellung für die Standardzugriffsebene des Kontos abgeleitet ist, wird im Azure-Portal als Zugriffsebene Heiß (abgeleitet) oder Kalt (abgeleitet) angezeigt.

Die Änderung der Einstellung für die Standardzugriffsebene eines Speicherkontos gilt für alle Blobs im Konto, für die keine explizite Zugriffsebene festgelegt ist. Wenn Sie bei einem Konto vom Typ „Universell V2“ die Standardeinstellung für die Zugriffsebene auf eine kühlere Ebene umschalten, werden Ihnen die Schreibvorgänge (pro 10 000) für alle Blobs berechnet, für welche die Zugriffsebene abgeleitet wird. Wenn Sie bei einem Konto vom Typ „Universell V2“ in eine wärmere Ebene umschalten, werden Ihnen sowohl Lesevorgänge (pro 10 000) als auch Datenabrufe (pro GB) berechnet.

Wenn Sie ein Legacy-Blob-Storage-Konto erstellen, müssen Sie bei der Erstellung die Standard-Zugriffsebene als Hot oder Cool festlegen. Das Ändern der Standardzugriffsebene in einem Legacy-Blob-Storage-Konto in eine kühlere Ebene ist kostenlos. Wenn Sie bei einem Blob Storage-Konto in eine wärmere Ebene umschalten, werden Ihnen sowohl Lesevorgänge (pro 10 000) als auch Datenabrufe (pro GB) in Rechnung gestellt. Microsoft empfiehlt, wenn möglich allgemeine v2-Speicherkonten anstelle von Blob-Storage-Konten zu verwenden.

Hinweis

Die Ebene „Cold“ Archivebene werden nicht als Standardzugriffsebene für ein Speicherkonto unterstützt.

Festlegen oder Ändern der Ebene eines Blobs

Um die Ebene eines Blobs beim Erstellen explizit festzulegen, geben Sie sie beim Hochladen des Blobs an.

Nach dem Erstellen eines Blobs können Sie die zugehörige Ebene mit einer der folgenden Methoden ändern:

  • Durch Aufrufen des Vorgangs Set Blob Tier, entweder direkt oder über eine Richtlinie zur Lebenszyklusverwaltung. Der Aufruf von Blobebene festlegen ist in der Regel die beste Option, um die Ebene eines Blobs von einer wärmeren in eine kältere Ebene zu ändern.

    Hinweis

    Sie können ein archiviertes Blob nicht mithilfe von Richtlinien für die Lebenszyklusverwaltung auf eine Onlineebene aktivieren.

  • Durch Aufrufen des Vorgangs Copy Blob zum Kopieren eines Blobs zwischen Ebenen. Der Aufruf von Blob kopieren wird für die meisten Szenarien empfohlen, bei denen Sie ein Blob aus der Archivebene auf einer Onlineebene aktivieren oder von der Ebene „kalt“ oder „Cold“ auf die heiße Ebene verschieben. Durch Kopieren eines Blobs können Sie die Gebühr für frühzeitiges Löschen vermeiden, wenn das erforderliche Speicherintervall für das Quellblob noch nicht verstrichen ist. Das Kopieren eines Blobs führt jedoch zu Kapazitätsgebühren für zwei Blobs: das Quellblob und das Zielblob.

Der Wechsel der Ebene eines Blobs von einer wärmeren zu einer kühleren Ebene erfolgt sofort, ebenso wie der Wechsel von „kalt“ oder „Cold“ zu „heiß“. Die Aktivierung eines Blobs aus der Archivebene in eine Onlineebene wie z. B. „heiß“, „kalt“ oder „Cold“ kann bis zu 15 Stunden dauern.

Beachten Sie bei der Änderung der Ebene eines Blobs die folgenden Aspekte:

  • Für ein Blob, das einen Verschlüsselungsbereich verwendet, kann Set Blob Tier nicht aufgerufen werden. Weitere Informationen zu Verschlüsselungsbereichen finden Sie unter Verschlüsselungsbereiche für Blobspeicher.
  • Wird ein Blob explizit in die kalte Ebene oder die Ebene „Cold“ und dann in die Archivebene verschoben, fällt die Gebühr für frühzeitiges Löschen an.

Lebenszyklusverwaltung für Blobs

Die Blob Storage-Lebenszyklusverwaltung umfasst eine regelbasierte Richtlinie, mit der Sie Daten zur gewünschten Zugriffsebene verschieben können, wenn die angegebenen Bedingungen erfüllt sind. Über die Lebenszyklusverwaltung können Sie auch festlegen, dass Daten am Ende ihrer Lebensdauer ablaufen. Weitere Informationen finden Sie unter Optimieren der Kosten durch Automatisieren der Azure Blob Storage-Zugriffsebenen.

Hinweis

In einem Premium-Blockblob-Speicherkonto gespeicherte Daten können weder mithilfe von Blockebene festlegen noch unter Verwendung der Azure Blob Storage-Lebenszyklusverwaltung auf die Ebene „heiß“, „kalt“, „Cold“ oder „Archiv“ verschoben werden. Um Daten zu verschieben, müssen Sie Blobs synchron vom Blockblob-Speicherkonto auf die heiße Ebene in einem anderen Konto kopieren. Verwenden Sie dazu die API Put Block From URL oder eine AzCopy-Version, die diese API unterstützt. Die Put Block From URL-API kopiert Daten synchron auf den Server, was heißt, dass der Aufruf erst abgeschlossen wird, nachdem alle Daten vom ursprünglichen Serverspeicherort an den Zielspeicherort verschoben wurden.

Zusammenfassung der Zugriffsebenenoptionen

In der folgenden Tabelle sind die Funktionen der Zugriffsebenen „heiß“, „kalt“, „Cold“ und „Archiv“ zusammengefasst.

Zugriffsebene „Heiß“ Zugriffsebene „Kalt“ Ebene „Cold“ Zugriffsebene „Archiv“
Verfügbarkeit 99,9 % 99 % 99 % 99 %
Verfügbarkeit
(RA-GRS-Lesevorgänge)		 99,99 % 99,9 % 99,9 % 99,9 %
Nutzungsgebühren Höhere Speicherkosten, jedoch geringere Zugriffs- und Transaktionskosten Geringere Speicherkosten, jedoch höhere Zugriffs- und Transaktionskosten Geringere Speicherkosten, jedoch höhere Zugriffs- und Transaktionskosten Geringste Speicherkosten, jedoch höchste Zugriffs- und Transaktionskosten
Empfohlene Mindestaufbewahrungsdauer für Daten – 30 Tage1 90 Tage1 180 Tage
Latenz
(Zeit bis zum ersten Byte)		 Millisekunden Millisekunden Millisekunden Stunden2
Unterstützte Redundanzkonfigurationen Alle Alle Alle Nur LRS, GRS und RA-GRS3

1 Bei Konten vom Typ „Universell v2“ beträgt die Aufbewahrungsdauer für Objekte der kalten Ebene mindestens 30 Tage. Bei Konten vom Typ „Universell v2“ beträgt die Aufbewahrungsdauer für Objekte der Ebene „Cold“ mindestens 90 Tage. Für Blob Storage-Konten gibt es keine Mindestaufbewahrungsdauer für die Ebenen „kalt“ oder „Cool“.

2 Beim Aktivieren eines Blobs aus der Archivebene haben Sie die Wahl zwischen der Aktivierungspriorität „Hoch“ und „Standard“. Die Optionen unterscheiden sich in Bezug auf Abrufwartezeiten und Kosten. Weitere Informationen finden Sie unter Übersicht über die Aktivierung von Blobs aus der Archivebene.

3 Weitere Informationen zu Redundanzkonfigurationen in Azure Storage finden Sie unter Azure Storage-Redundanz.

Preise und Abrechnung

Für alle Speicherkonten wird ein Blockblobspeicher-Preismodell angewandt, das auf der Ebene des jeweiligen Blobs basiert. Beachten Sie die in den folgenden Abschnitten beschriebenen Aspekte der Abrechnung.

Weitere Informationen zu den Preisen für Blockblobs finden Sie unter Preise für Blockblobs.

Kosten für die Speicherkapazität

Die Kosten für die Datenspeicherung hängen nicht nur von der gespeicherten Datenmenge ab, sondern auch von der Zugriffsebene. Je „kälter“ die Ebene, desto geringer die Kosten für die Kapazität pro GB.

Kosten für den Datenzugriff

Je „kälter“ die Ebene, desto höher die Gebühren für den Datenzugriff. Für Daten in den Zugriffsebenen „kalt“, „Cold“ und „Archiv“ wird eine Gebühr pro Gigabyte für den Lesezugriff erhoben.

Transaktionskosten

Für alle Ebenen fällt eine Gebühr pro Transaktion an, die steigt, je „kälter“ die Ebene ist.

Datenübertragungskosten bei Georeplikation

Diese Gebühr gilt nur für Konten mit konfigurierter Georeplikation (einschließlich GRS, RA-GRS und GZRS). Die Datenübertragung für die Georeplikation wird pro Gigabyte abgerechnet.

Übertragungskosten für ausgehende Daten

Ausgehende Datenübertragungen (Daten, die aus einer Azure-Region übertragen werden) werden nach Bandbreitennutzung pro GB abgerechnet. Weitere Informationen zu den Kosten für ausgehende Datenübertragungen finden Sie auf der Seite Bandbreite: Preisübersicht.

Ändern der Standardzugriffsebene eines Kontos

Bei einer Änderung der Kontozugriffsebene fallen Gebühren für die Ebenenänderung für alle Blobs an, für die noch keine explizite Ebene festgelegt ist. Weitere Informationen finden Sie im folgenden Abschnitt Ändern der Zugriffsebene eines Blobs.

Ändern der Zugriffsebene eines Blobs

Beachten Sie die folgenden Auswirkungen auf die Abrechnung bei der Änderung der Ebene eines Blobs:

  • Wenn ein Blob hochgeladen oder zwischen Ebenen verschoben wird, wird dies sofort nach dem Hochladen oder einer Ebenenänderung zur entsprechenden Gebühr in Rechnung gestellt.
  • Wenn ein Blob in eine kältere Ebene verschoben wird, wird der Vorgang als Schreibvorgang auf die Zielebene berechnet, und es gelten die Zielebenengebühren für Schreibvorgänge (pro 10.000) und das Schreiben von Daten (pro GB).
  • Wenn ein Blob in eine wärmere Ebene verschoben wird, wird der Vorgang als Lesevorgang aus der Quellebene berechnet, und es gelten die Quellebenengebühren für Lesevorgänge (pro 10.000) und Datenabruf (pro GB). Bei Blobs, die aus der Ebene „kalt“, „Cold“ oder „Archiv“ verschoben werden, können auch Gebühren für das frühzeitige Löschen anfallen.
  • Wenn ein Blob aus der Archivebene aktiviert wird, werden die Daten dieses Blobs als archivierte Daten abgerechnet, bis die Daten wiederhergestellt sind und sich die Ebene des Blobs in „heiß“, „kalt“ oder „Cold“ ändert.

Die folgende Tabelle gibt Aufschluss darüber, wie Ebenenänderungen abgerechnet werden.

Schreibgebühren (Vorgang + Zugriff) Lesegebühren (Vorgang + Zugriff)
Von „Heiß“ in „Kalt“
Von der heißen Ebene zur Ebene „Cold“
Von „Heiß“ in „Archiv“
Von der kalten Ebene zur Ebene „Cold“
Von „Kalt“ in „Archiv“
Von der Ebene „Cold“ zur Ebene „Archiv“		 Von der Ebene „Archiv“ zur Ebene „Cold“
Von „Archiv“ in „Kalt“
Von „Archiv“ in „Heiß“
Von der Ebene „Cold“ zur kalten Ebene
Von der Ebene „Cold“ zur heißen Ebene
Von „Kalt“ in „Heiß“

Das Ändern der Zugriffsebene für ein Blob bei aktivierter Versionierung, oder wenn das Blob über Momentaufnahmen verfügt, kann zu weiteren Kosten führen. Informationen zu Blobs mit aktivierter Versionsverwaltung finden Sie in der Dokumentation zur Blobversionsverwaltung unter Preise und Abrechnung. Informationen zu Blobs mit Momentaufnahmen finden Sie in der Dokumentation zu Blobmomentaufnahmen unter Preise und Abrechnung.

Ebene „Cold“

Einschränkungen und bekannte Probleme

  • Die Einstellung für die Standardzugriffsebene des Kontos kann nicht auf die Ebene „Cold“ festgelegt werden.

Erforderliche Versionen von REST, SDKs und Tools

Umgebung Mindestversion
REST-API 2021-21-02
.NET 12.15.0
Java 12.21.0
Python 12.15.0
JavaScript 12.13.0
PowerShell (Az.Storage) 5.8.0
Azure-Befehlszeilenschnittstelle 2.50.0
AzCopy 10.18.1
Azure Storage-Explorer 1.29.0

Featureunterstützung

Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.

Nächste Schritte