Azure Blob 存储的访问层 - 热、冷和存档Access tiers for Azure Blob Storage - hot, cool, and archive

Azure 存储提供了不同的访问层,允许你以最具成本效益的方式存储 Blob 对象数据。Azure storage offers different access tiers, allowing you to store blob object data in the most cost-effective manner. 可用的访问层包括:Available access tiers include:

  • :适用于存储经常访问的数据。Hot - Optimized for storing data that is accessed frequently.
  • :适用于存储不常访问且存储时间至少为 30 天的数据。Cool - Optimized for storing data that is infrequently accessed and stored for at least 30 days.
  • 存档:适用于存储极少访问、存储时间至少为 180 天且延迟要求(以小时计)不严格的数据。Archive - Optimized for storing data that is rarely accessed and stored for at least 180 days with flexible latency requirements, on the order of hours.

以下注意事项适用于不同的访问层:The following considerations apply to the different access tiers:

  • 可以在上传期间或之后在 blob 上设置访问层。The access tier can be set on a blob during or after upload.
  • 在帐户级别只能设置热和冷访问层。Only the hot and cool access tiers can be set at the account level. 存档访问层只能在 blob 级别设置。The archive access tier can only be set at the blob level.
  • 冷访问层中的数据具有略低的可用性,但仍具有类似于热数据的高持久性、检索延迟和吞吐量特征。Data in the cool access tier has slightly lower availability, but still has high durability, retrieval latency, and throughput characteristics similar to hot data. 与热数据相比,冷数据的可用性略低且访问成本略高,这是可以接受的,因为毕竟其总体存储成本较低。For cool data, slightly lower availability and higher access costs are acceptable trade-offs for lower overall storage costs compared to hot data. 有关详细信息,请参阅存储的 SLAFor more information, see SLA for storage.
  • 存档访问层中的数据是脱机存储的。Data in the archive access tier is stored offline. 存档层的存储成本最低,但访问成本和延迟最高。The archive tier offers the lowest storage costs but also the highest access costs and latency.
  • 数据存储限制在帐户级别设置,不按访问层设置。Data storage limits are set at the account level and not per access tier. 可以选择在一个层中用完所有存储配额,也可以分散用于三个层。You can choose to use all of your limit in one tier or across all three tiers.

存储在云中的数据以指数速度增长。Data stored in the cloud grows at an exponential pace. 若要针对不断增加的存储需求来管理成本,可以根据属性(如访问频率和计划保留期)整理数据以优化成本。To manage costs for your expanding storage needs, it's helpful to organize your data based on attributes like frequency-of-access and planned retention period to optimize costs. 存储在云中的数据可能根据其生成方式、处理方式以及在生存期内的访问方式而有所不同。Data stored in the cloud can be different based on how it's generated, processed, and accessed over its lifetime. 某些数据在其整个生存期中都会受到积极的访问和修改。Some data is actively accessed and modified throughout its lifetime. 某些数据则在生存期早期会受到频繁访问,随着数据变旧,访问会极大地减少。Some data is accessed frequently early in its lifetime, with access dropping drastically as the data ages. 某些数据在云中保持空闲状态,并且在存储后很少(如果有)被访问。Some data remains idle in the cloud and is rarely, if ever, accessed after it's stored.

这些数据访问方案的每一个都受益于针对特定访问模式进行了优化的差异化访问层。Each of these data access scenarios benefits from a different access tier that is optimized for a particular access pattern. Azure Blob 存储采用热、冷和存档访问层,通过单独的定价模型来满足对差异化访问层的这种需要。With hot, cool, and archive access tiers, Azure Blob Storage addresses this need for differentiated access tiers with separate pricing models.

以下工具和客户端库都支持 blob 级分层和存档存储。The following tools and client libraries all support blob-level tiering and archive storage.

  • Azure 门户Azure portal
  • PowerShellPowerShell
  • Azure CLI 工具Azure CLI tools
  • .NET 客户端库.NET client library
  • Java 客户端库Java client library
  • Python 客户端库Python client library
  • Node.js 客户端库Node.js client library

备注

本文中所述的功能现在可用于具有分层命名空间的帐户。The features described in this article are now available to accounts that have a hierarchical namespace. 若要查看限制,请参阅 Azure Data Lake Storage Gen2 中可用的 Blob 存储功能一文。To review limitations, see the Blob storage features available in Azure Data Lake Storage Gen2 article.

支持分层的存储帐户Storage accounts that support tiering

Blob 存储和常规用途 v2 (GPv2) 帐户支持在热层、冷层和存档层之间将对象存储数据分层。Object storage data tiering between hot, cool, and archive is supported in Blob Storage and General Purpose v2 (GPv2) accounts. 常规用途 v1 (GPv1) 帐户不支持分层。General Purpose v1 (GPv1) accounts don't support tiering. 你可以通过 Azure 门户轻松地将现有的 GPv1 或 Blob 存储帐户转换为 GPv2 帐户。You can easily convert your existing GPv1 or Blob Storage accounts to GPv2 accounts through the Azure portal. GPv2 为 Blob、文件和队列提供新的定价与功能。GPv2 provides new pricing and features for blobs, files, and queues. 某些功能和价格折扣仅在 GPv2 帐户中提供。Some features and price cuts are only offered in GPv2 accounts. 某些工作负荷的价格在 GPv2 中可能比在 GPv1 中更高。Some workloads can be more expensive on GPv2 than GPv1. 有关详细信息,请参阅 Azure 存储帐户概述For more information, see Azure storage account overview.

Blob 存储和 GPv2 帐户在帐户级别公开“访问层”属性。Blob Storage and GPv2 accounts expose the Access Tier attribute at the account level. 使用此属性可为未在对象级别显式设置默认访问层的任何 blob 指定默认访问层。This attribute allows you to specify the default access tier for any blob that doesn't have it explicitly set at the object level. 对于已显式设置了层级的对象,不会应用帐户层。For objects with the tier explicitly set, the account tier won't apply. 存档层仅适用于对象级别。The archive tier can be applied only at the object level. 可以随时在访问层之间进行切换。You can switch between access tiers at any time.

请使用 GPv2 帐户而非 Blob 存储帐户进行分层。Use GPv2 instead of Blob Storage accounts for tiering. GPv2 支持 Blob 存储帐户支持的所有功能,以及许多其他功能。GPv2 supports all the features that Blob Storage accounts support, plus a lot more. Blob 存储和 GPv2 的定价几乎相同,但某些新功能和价格折扣只提供给 GPv2 帐户。Pricing between Blob Storage and GPv2 is almost identical, but some new features and price cuts are only available on GPv2 accounts.

GPv1 和 GPv2 帐户的定价结构不同,客户在决定使用 GPv2 帐户之前,应仔细评估这二者。Pricing structure between GPv1 and GPv2 accounts is different and customers should carefully evaluate both before deciding to use GPv2 accounts. 只需单击一下,即可轻松地将现有的 Blob 存储或 GPv1 帐户转换为 GPv2 帐户。You can easily convert an existing Blob Storage or GPv1 account to GPv2 through a simple one-click process. 有关详细信息,请参阅 Azure 存储帐户概述For more information, see Azure storage account overview.

热访问层Hot access tier

热访问层的存储成本高于冷存储和存档层,但访问成本最低。The hot access tier has higher storage costs than cool and archive tiers, but the lowest access costs. 热访问层的示例使用方案包括:Example usage scenarios for the hot access tier include:

  • 处于活跃使用状态或预期会频繁读取和写入的数据。Data that's in active use or is expected to be read from and written to frequently
  • 分阶段进行处理并最终迁移至冷访问层的数据。Data that's staged for processing and eventual migration to the cool access tier

冷访问层Cool access tier

与热存储相比,冷访问层的存储成本较低,访问成本较高。The cool access tier has lower storage costs and higher access costs compared to hot storage. 此层适用于将要保留在冷层中至少 30 天的数据。This tier is intended for data that will remain in the cool tier for at least 30 days. 冷访问层的示例使用方案包括:Example usage scenarios for the cool access tier include:

  • 短期备份和灾难恢复Short-term backup and disaster recovery
  • 不经常使用但在被访问时应当立即可用的较旧数据Older data not used frequently but expected to be available immediately when accessed
  • 需要经济高效地进行存储且要收集更多数据在将来进行处理的大型数据集Large data sets that need to be stored cost effectively, while more data is being gathered for future processing

存档访问层Archive access tier

与热层和冷层相比,存档访问层的存储成本最低,但数据检索成本较高。The archive access tier has the lowest storage cost but higher data retrieval costs compared to hot and cool tiers. 存档层中的数据必须至少保留 180 天,否则需要支付提前删除费。Data must remain in the archive tier for at least 180 days or be subject to an early deletion charge. 存档层中数据的检索可能需要几个小时,具体取决于指定的解除冻结优先级。Data in the archive tier can take several hours to retrieve depending on the specified rehydration priority. 对于小型对象,优先级高的解除冻结可能会在 1 小时内从存档中检索到对象。For small objects, a high priority rehydrate may retrieve the object from archive in under an hour. 若要了解详细信息,请参阅从存档层解冻 Blob 数据See Rehydrate blob data from the archive tier to learn more.

如果 blob 位于存档存储中,则 blob 数据处于脱机状态,不能读取或修改。While a blob is in archive storage, the blob data is offline and can't be read or modified. 若要在存档中读取或下载 Blob,必须首先将其解除冻结到联机层。To read or download a blob in archive, you must first rehydrate it to an online tier. 不能创建存档存储中 Blob 的快照。You can't take snapshots of a blob in archive storage. 但是,Blob 元数据会保持联机和可用状态,因而可列出 Blob、其属性以及元数据。However, the blob metadata remains online and available, allowing you to list the blob, its properties, and metadata. 不允许设置或修改存档中的 blob 元数据。Setting or modifying the blob metadata while in archive isn't allowed. 对于存档中的 Blob,仅以下操作有效:获取 Blob 属性获取 Blob 元数据列出 Blob设置 Blob 层复制 Blob删除 BlobFor blobs in archive, the only valid operations are Get Blob Properties, Get Blob Metadata, List Blobs, Set Blob Tier, Copy Blob, and Delete Blob.

存档访问层的示例使用方案包括:Example usage scenarios for the archive access tier include:

  • 长期备份、辅助备份和存档数据集Long-term backup, secondary backup, and archival datasets
  • 必须保留的原始数据,即使它已处理成最终可用的形式Original (raw) data that must be preserved, even after it has been processed into final usable form
  • 需要长时间存储并且几乎不访问的合规性和存档数据Compliance and archival data that needs to be stored for a long time and is hardly ever accessed

帐户级分层Account-level tiering

所有三个访问层中的 Blob 可以在同一帐户中共存。Blobs in all three access tiers can coexist within the same account. 如果 Blob 没有显式分配的层,则会从帐户访问层设置推断相应的层。Any blob that doesn't have an explicitly assigned tier infers the tier from the account access tier setting. 如果访问层来自帐户,则你可以看到“推断的访问层”Blob 属性已设置为“true”,而“访问层”Blob 属性与帐户层匹配。 If the access tier comes from the account, you see the Access Tier Inferred blob property set to "true", and the Access Tier blob property matches the account tier. 在 Azure 门户中,Blob 访问层的“推断访问层”属性显示为“热(推断)”或“冷(推断)”。 In the Azure portal, the access tier inferred property is displayed with the blob access tier as Hot (inferred) or Cool (inferred).

更改帐户访问层适用于帐户中存储的未设置显式层的所有“推断访问层”对象。Changing the account access tier applies to all access tier inferred objects stored in the account that don't have an explicit tier set. 如果将帐户层从热切换为冷,则只按 GPv2 帐户中没有设置层的所有 Blob 的写入操作次数(以 10,000 次为单位)收费。If you toggle the account tier from hot to cool, you'll be charged for write operations (per 10,000) for all blobs without a set tier in GPv2 accounts only. 不会在 Blob 存储帐户中对此更改收费。There's no charge for this change in Blob Storage accounts. 如果在 Blob 存储或 GPv2 帐户中从冷切换为热,则会按读取操作次数(以 10,000 次为单位)和数据检索量(以 GB 为单位)收费。You'll be charged for both read operations (per 10,000) and data retrieval (per GB) if you toggle from cool to hot in Blob Storage or GPv2 accounts.

只有热访问层和冷访问层可以设置为默认帐户访问层。Only hot and cool access tiers can be set as the default account access tier. 只能在对象级别设置存档层。Archive can only be set at the object level. 上传 blob 时,无论默认帐户层是哪个,都可以将所选访问层指定为热层、冷层或存档层。On blob upload, you can specify the access tier of your choice to be hot, cool, or archive regardless of the default account tier. 使用此功能可以将数据直接写入存档层,从而从在 Blob 存储中创建数据的那一刻起就实现了节省成本。This functionality allows you to write data directly into the archive tier to realize cost-savings from the moment you create data in blob storage.

Blob 级别分层Blob-level tiering

有了 Blob 级别分层,就可以使用 Put BlobPut 块列表操作将数据上传到所选的访问层,并使用设置 Blob 层操作或生命周期管理功能在对象级别更改数据的层。Blob-level tiering allows you to upload data to the access tier of your choice using the Put Blob or Put Block List operations and change the tier of your data at the object level using the Set Blob Tier operation or lifecycle management feature. 可以将数据上传到所需的访问层,然后在使用模式更改时轻松地在热、冷或存档层之间更改 Blob 访问层,不需在帐户之间移动数据。You can upload data to your required access tier then easily change the blob access tier among the hot, cool, or archive tiers as usage patterns change, without having to move data between accounts. 所有层更改请求会立即发生,热和冷之间的层更改是即时的。All tier change requests happen immediately and tier changes between hot and cool are instantaneous. 从存档层中解除冻结 Blob 可能需要几个小时。Rehydrating a blob from the archive tier can take several hours.

上次 Blob 层更改的时间通过 Blob 属性“访问层更改时间”公开。The time of the last blob tier change is exposed via the Access Tier Change Time blob property. 访问层更改时间是 blob 级别属性,在默认帐户层更改时不会更新。Access Tier Change Time is a blob-level property and is not updated when the default account tier is changed. 帐户属性和 blob 属性是独立的。Account properties and blob properties are separate. 每当更改帐户的默认访问层时,对存储帐户中的每个 blob 更新访问层更改时间会耗费大量资源。It would be prohibitively expensive to update the Access Tier Change Time on every blob in a storage account whenever the account's default access tier is changed.

覆盖热层或冷层中的 blob 时,除非在创建时显式设置了新的 blob 访问层,否则新创建的 blob 将继承被覆盖的 blob 的层的属性。When overwriting a blob in the hot or cool tier, the newly created blob inherits the tier of the blob that was overwritten unless the new blob access tier is explicitly set on creation. 如果 Blob 位于存档层中,则无法被覆盖,因此在这种情况下,不允许上传相同的 Blob。If a blob is in the archive tier, it can't be overwritten, so uploading the same blob isn't permitted in this scenario.

备注

存档存储和 Blob 级别分层仅支持块 Blob。Archive storage and blob-level tiering only support block blobs.

Blob 生命周期管理Blob lifecycle management

Blob 存储生命周期管理提供丰富的基于规则的策略,这些策略可用于将数据转移到最适合的访问层,并在数据的生命周期结束时使数据过期。Blob storage lifecycle management offers a rich, rule-based policy that you can use to transition your data to the best access tier and to expire data at the end of its lifecycle. 请参阅通过自动执行 Azure Blob 存储访问层来优化成本来了解详细信息。See Optimize costs by automating Azure Blob Storage access tiers to learn more.

备注

存储在块 Blob 存储帐户(高级性能)中的数据目前无法使用设置 Blob 层或使用 Azure Blob 存储生命周期管理分层到热、冷或存档访问层。Data stored in a block blob storage account (Premium performance) cannot currently be tiered to hot, cool, or archive using Set Blob Tier or using Azure Blob Storage lifecycle management. 若要移动数据,必须使用通过 URL 放置块 API 或支持此 API 的 AzCopy 版本,将块 Blob 存储帐户中的 Blob 同步复制到其他帐户中的热访问层。To move data, you must synchronously copy blobs from the block blob storage account to the hot access tier in a different account using the Put Block From URL API or a version of AzCopy that supports this API. 通过 URL 放置块 API 同步复制服务器上的数据,这意味着只有在所有数据都从原服务器位置移动到目标位置后,调用才会完成。The Put Block From URL API synchronously copies data on the server, meaning the call completes only once all the data is moved from the original server location to the destination location.

Blob 级别分层计费Blob-level tiering billing

在各个层之间上传或移动 blob 时,系统会在上传时或层发生更改时立即按相应的费率收费。When a blob is uploaded or moved between tiers, it is charged at the corresponding rate immediately upon upload or tier change.

将 blob 移到更冷的层(热->冷、热->存档或冷->存档)时,操作按目标层写入操作计费,具体说来就是按目标层的写入操作次数(以 10,000 次为单位)和数据写入量(以 GB 为单位)收费。When a blob is moved to a cooler tier (hot->cool, hot->archive, or cool->archive), the operation is billed as a write operation to the destination tier, where the write operation (per 10,000) and data write (per GB) charges of the destination tier apply.

将 Blob 移到更暖的层(存档->冷、存档->热或冷->热)时,操作按从源层读取计费,具体说来就是按源层的读取操作次数(以 10,000 次为单位)和数据检索量(以 GB 为单位)收费。When a blob is moved to a warmer tier (archive->cool, archive->hot, or cool->hot), the operation is billed as a read from the source tier, where the read operation (per 10,000) and data retrieval (per GB) charges of the source tier apply. 也可能还会收取从冷层或存档层移出的任何 Blob 的提前删除费用。Early deletion charges for any blob moved out of the cool or archive tier may apply as well. 将数据从存档层中解除冻结需要一段时间,而数据会按存档价格计费,直到将数据以联机方式还原并将 blob 层更改为热层或冷层为止。Rehydrating data from the archive tier takes time and data will be charged archive prices until the data is restored online and the blob tier changes to hot or cool.

下表总结了如何对层更改进行计费。The following table summarizes how tier changes are billed.

写入费用(操作 + 访问)Write charges (operation + access) 读取费用(操作 + 访问)Read charges (operation + access)
设置 Blob 层Set Blob Tier 热 -> 冷hot -> cool
热 -> 存档hot -> archive
冷 -> 存档cool -> archive
存档 -> 冷archive -> cool
存档 -> 热archive -> hot
冷 -> 热cool -> hot

“冷”层和“存档”层提前删除Cool and archive early deletion

移到冷层(仅限 GPv2 帐户)中的 Blob 会有一个 30 天的冷层提前删除期限。Any blob that is moved into the cool tier (GPv2 accounts only) is subject to a cool early deletion period of 30 days. 移到存档层中的 Blob 会有一个 180 天的存档提前删除期限。Any blob that is moved into the archive tier is subject to an archive early deletion period of 180 days. 此项费用按比例计算。This charge is prorated. 例如,如果将某个 Blob 移到存档层,然后在 45 天后将其删除或移到热层,则需支付相当于将该 Blob 存储在存档层中 135(180 减 45)天的提前删除费用。For example, if a blob is moved to archive and then deleted or moved to the hot tier after 45 days, you'll be charged an early deletion fee equivalent to 135 (180 minus 45) days of storing that blob in archive.

一些在冷层和存档层之间移动时的详细信息:There are some details when moving between the cool and archive tiers:

  1. 如果根据存储帐户的默认访问层将 Blob 推断为冷层,并将 Blob 移动到存档层,则不会收取提前删除费用。If a blob is inferred as cool based on the storage account's default access tier and the blob is moved to archive, there is no early deletion charge.
  2. 如果将 Blob 显式移动到冷层,然后将其移动到存档层,则将收取提前删除费用。If a blob is explicitly moved to the cool tier and then moved to archive, the early deletion charge applies.

如果未发生访问层更改,请使用 Blob 属性“Last-Modified”来计算提前删除时间。Calculate the early deletion time by using the Last-Modified blob property, if there have been no access tier changes. 否则,请通过查看 Blob 属性(即“access-tier-change-time”)来使用最后一次将访问层修改为“冷”或“存档”的时间。Otherwise, use when the access tier was last modified to cool or archive by viewing the blob property: access-tier-change-time. 有关 Blob 属性的详细信息,请参阅获取 Blob 属性For more information on blob properties, see Get Blob Properties.

比较块 Blob 存储选项Comparing block blob storage options

下表对高级性能块 blob 存储与热、冷、存档访问层进行了比较。The following table shows a comparison of premium performance block blob storage, and the hot, cool, and archive access tiers.

高级性能Premium performance 热存储层Hot tier 冷存储层Cool tier 存档存储层Archive tier
可用性Availability 99.9%99.9% 99.9%99.9% 99%99% OfflineOffline
可用性Availability
(RA-GRS 读取)(RA-GRS reads)
空值N/A 99.99%99.99% 99.9%99.9% OfflineOffline
使用费Usage charges 存储费用较高,访问和事务费用较低Higher storage costs, lower access, and transaction cost 存储费用较高,访问和事务费用较低Higher storage costs, lower access, and transaction costs 存储费用较低,访问和事务费用较高Lower storage costs, higher access, and transaction costs 存储费用最低,访问和事务费用最高Lowest storage costs, highest access, and transaction costs
最短存储持续时间Minimum storage duration 空值N/A 空值N/A 30 天130 days1 180 天180 days
延迟Latency
(距第一字节时间)(Time to first byte)
一位数的毫秒数Single-digit milliseconds 毫秒milliseconds 毫秒milliseconds 小时2hours2

1 GPv2 帐户冷层中的对象的最短保留期为 30 天。1 Objects in the cool tier on GPv2 accounts have a minimum retention duration of 30 days. Blob 存储帐户的冷层没有最短保留期。Blob Storage accounts don't have a minimum retention duration for the cool tier.

2 存档存储目前支持两种解除冻结优先级:“高”和“标准”,它们带来不同的检索延迟和成本。2 Archive Storage currently supports two rehydration priorities, high and standard, offering different retrieval latencies and costs. 有关详细信息,请参阅从存档层解冻 Blob 数据For more information, see Rehydrate blob data from the archive tier.

备注

Blob 存储帐户支持与常规用途 v2 存储帐户相同的性能和可伸缩性目标。Blob Storage accounts support the same performance and scalability targets as general-purpose v2 storage accounts. 有关详细信息,请参阅 Blob 存储可伸缩性和性能目标For more information, see Scalability and performance targets for Blob Storage.

定价和计费Pricing and billing

所有存储帐户使用的定价模型都适用于块 Blob 存储,具体取决于每个 Blob 的层。All storage accounts use a pricing model for block blob storage based on the tier of each blob. 请记住以下计费注意事项:Keep in mind the following billing considerations:

  • 存储成本:除了存储的数据量,存储数据的成本将因访问层而异。Storage costs: In addition to the amount of data stored, the cost of storing data varies depending on the access tier. 层越冷,单 GB 成本越低。The per-gigabyte cost decreases as the tier gets cooler.

  • 数据访问成本:层越冷,数据访问费用越高。Data access costs: Data access charges increase as the tier gets cooler. 对于冷访问层和存档访问层中的数据,需要按 GB 支付读取方面的数据访问费用。For data in the cool and archive access tier, you're charged a per-gigabyte data access charge for reads.

  • 事务成本:层越冷,每个层的按事务收费越高。Transaction costs: There's a per-transaction charge for all tiers that increases as the tier gets cooler.

  • 异地复制数据传输成本:此费用仅适用于配置了异地复制的帐户,包括 GRS 和 RA-GRS。Geo-replication data transfer costs: This charge only applies to accounts with geo-replication configured, including GRS and RA-GRS. 异地复制数据传输会产生每 GB 费用。Geo-replication data transfer incurs a per-gigabyte charge.

  • 出站数据传输成本:出站数据传输(传出 Azure 区域的数据)会按每 GB 产生带宽使用费,与通用存储帐户一致。Outbound data transfer costs: Outbound data transfers (data that is transferred out of an Azure region) incur billing for bandwidth usage on a per-gigabyte basis, consistent with general-purpose storage accounts.

  • 更改访问层:更改帐户访问层会导致未设置显式层的所有 Blob 产生层更改费。Changing the access tier: Changing the account access tier will result in tier change charges for all blobs that don't have an explicit tier set. 有关更改单个 Blob 的访问层的信息,请参阅 Blob 级分层计费For information on changing the access tier for a single blob, see Blob-level tiering billing.

    当版本控制已启用或 Blob 包含快照时,更改 Blob 的访问层可能会产生额外费用。Changing the access tier for a blob when versioning is enabled, or if the blob has snapshots, may result in additional charges. 有关启用了版本控制的 blob 的信息,请参阅 blob 版本控制文档中的定价和计费For information about blobs with versioning enabled, see Pricing and billing in the blob versioning documentation. 有关包含快照的 Blob 的信息,请参阅 Blob 快照文档中的定价和计费For information about blobs with snapshots, see Pricing and billing in the blob snapshots documentation.

备注

有关块 Blob 定价的详细信息,请参阅块 Blob 定价For more information about pricing for Block blobs, see Block blob pricing. 有关出站数据传输费用的详细信息,请参阅带宽定价详细信息页。For more information on outbound data transfer charges, see Bandwidth Pricing Details page.

可用性Availability

所选区域中提供了不同的访问层以及 Blob 级分层。Different access tiers, along with blob-level tiering, are available in select regions. 如需完整列表,请参阅 Azure 产品(按区域)For a complete list, see Azure products available by region.

后续步骤Next steps

了解如何跨访问层管理 Blob 和帐户。Learn how to manage blobs and accounts across access tiers.