您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

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.
  • "热" 和 "冷" 层支持所有冗余选项。The hot and cool tiers support all redundancy options. 存档层仅支持 LRS、GRS 和 GRS。The archive tier supports only LRS, GRS, and RA-GRS.
  • 数据存储限制是在帐户级别设置的,而不是按访问层设置的。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. 对于小对象,高优先级解除冻结可能会在一小时内从存档中检索对象。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 及其属性、元数据和 blob 索引标记。However, the blob metadata remains online and available, allowing you to list the blob, its properties, metadata, and blob index tags. 不允许在存档时设置或修改 blob 元数据。Setting or modifying the blob metadata while in archive isn't allowed. 但是,您可以设置和修改 blob 索引标记。However, you can set and modify the blob index tags. 对于存档中的 blob,唯一有效的操作是 获取 Blob 属性获取 blob 元数据设置 Blob 标记获取 Blob 标记按标记查找 blob列出 blob设置 Blob 层复制 blob删除 blobFor blobs in archive, the only valid operations are Get Blob Properties, Get Blob Metadata, Set Blob Tags, Get Blob Tags, Find Blobs by Tags, 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


ZRS、GZRS 或 GZRS 帐户不支持存档层。The archive tier is not supported for ZRS, GZRS, or RA-GZRS accounts.

帐户级分层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 级分层允许使用 "设置 Blob 层" 操作或生命周期管理功能,将数据上传到所选的访问层,使用 " Put Blob " 或 " put 块列表" 操作并在对象级别更改数据层。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 时,除非在创建时显式设置了新的 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 属性来计算早期的删除时间。Calculate the early deletion time by using the Last-Modified blob property, if there have been no access tier changes. 否则,请在访问层上次修改为冷或存档时使用,方法是查看 blob 属性: 访问层-更改时间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
(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
(距第一字节时间)(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 和 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.


选择区域中提供了不同的访问层和 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.