Azure Blob storage: hot, cool, and archive access tiers
Here we are going to discuss all the Azure Blob storage and access tiers.
To begin, Azure storage offers a variety of access options. Additionally, these enable you to save blob object data in the most cost-effective manner possible. In addition, the following are the possible access tiers:
- Hot – Improving for storing data that is accessed frequently.
- Cool – Optimized for storing data that is infrequently accessed and stored for at least 30 days.
- 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 subsequent considerations apply to the various access tiers:
- First and foremost, the hot and cool access tiers can be arranged at the account level. However, the Archives access tier isn’t available at the account level.
- Secondly, hot, cool, and archive tiers can be arranged at the blob level during upload or after upload.
- Subsequently, data in the cool access tier can tolerate slightly lower availability. However, it still demands high durability, retrieval latency, and throughput characteristics similar to hot data.
- Lastly, the archive storage stores data offline and provide the lowest storage costs. And, also the highest data rehydrate and access costs.
Hot, Cool, and Archive access tiers for blob data
- Data stored in the cloud grows at an exponential pace. In order, to maintain costs for the expanding storage needs, it’s important to organize your data based on attributes like frequency of access and planned retention period to optimize costs.
- Moreover, data stored in the cloud can be modified based on how it’s generated, processed, and accessed over its lifetime. In most cases, the data is actively accessed and altered throughout its lifetime. On the other hand, some data is accessed frequently early in its life along with access dropping drastically as the data ages.
- Furthermore, in some cases, data remains vain in the cloud and is rarely if ever, accessed after storage.
Storage accounts that support tiering
Blob storage and GPv2 accounts provide data tiering between hot, cold, and archive in object storage. Tiering is not maintained in General Purpose v1 (GPv1) accounts. Customers should use the Azure interface to simply convert their current GPv1 or Blob storage accounts to GPv2 accounts.
- Here, GPv2 offers new pricing and features for blobs, files, and queues. Some features and prices cuts are only granted in GPv2 accounts. Also, some workloads can be more costly on GPv2 rather than GPv1.
- Blob storage and GPv2 accounts reveal the Access Tier attribute at the account level. Further, this attribute enables you to define the default access tier for any blob that doesn’t have it specific set at the object level.
1. Hot access tier
The hot access tier has higher storage costs than the cool and archive tiers. They also offer the most affordable access fees. The following are some examples of circumstances when the hot access tier is used:
- First of all, data that are in active use or expected to be accessed (read from and written to) frequently.
- Also, data that are staged for processing and eventual migration to the Cool access tier.
2. Cool access tier
In opposed to hot storage, the cool access tier has lower storage costs but higher access costs. Not to mention, this tier is intended for data that will be kept cold for at least 30 days. The following are some examples of cool access tier usage scenarios:
- On one hand, short-term backup and disaster recovery datasets.
- On the other hand, older media content not observed constantly anymore but is expected to be available quickly when accessed.
- Subsequently, large data sets that require to be stored cost-effectively while more data is being assembled for future processing.
3. Archive access tier
The lowest storage cost is found in the Archive access tier. However, as compared to the hot and cool tiers, it has greater data retrieval costs. Furthermore, the material must be kept in the archive tier for at least 180 days to avoid an early deletion fee.
A blob’s data is offline and cannot be read, replaced, or updated while it is in archive storage. You must first rehydrate a blob in the archive to an online tier before reading or downloading it. The following are some example usage cases for the Archive access tier:
- Firstly, long-term backup, secondary backup, and archival datasets
- Secondly, original (raw) data that must be preserved, even after it has been processed into the final usable form.
- Thirdly, compliance and archival data that needs to be stored for a long time and is hardly ever accessed.
Account-level tiering
- All three access tiers can coexist within the same account of the blob. Any blob that doesn’t have an explicitly assigned tier infers the tier from the account access tier setting.
- Secondly, 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.
- Subsequently, 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 doesn’t have an explicit tier set.
- Then, 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. Also, there’s no charge for this change in Blob storage accounts. Moreover, 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.
Tiering of Blob-level
- Understand that Blob-level tiering permits you to upload data to the access tier of your choice utilising the Put Blob or Put Block List operations. Further, it allows you to change the tier of your data at the object level using the Set Blob Tier operation or Lifecycle management feature.
- Not to mention, you can also 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. That too without having to move data between accounts.
- Moreover, all tier change requests happen quickly and tier changes among hot and cool are instantaneous. However, rehydrating a blob from the archive can take several hours.
Blob lifecycle management
Storage lifecycle management of blob gives a rich, rule-based policy. Additionally, this was utilized to move data to the best access tier and to expire data at the end of its existence.
1. Billing of Blob-level tiering
- If a blob is uploaded or moved to the hot, cool, or archive tier, it is charged at the corresponding rate instantly upon tier change.
- And, if 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 and data write charges of the destination tier apply.
2. Cool and archive early deletion
- Any blob that is pushed into the cool tier i.e.GPv2 accounts only is subject to a cool early deletion period of 30 days. Any blob that is migrated into the archive tier is subject to an archive early deletion period of 180 days.
- Not to mention, this charge is prorated. For instance, if a blob is moved to archive and then deleted or moved to the hot tier after 45 days, you’ll be priced an early deletion fee equivalent to 135 (180 minuses 45) days of storing that blob in the archive.
Comparing block blob storage options:
A comparison between premium performance block blob storage and the hot, cold, and archive access levels is shown in the table below.
| Premium performance | Hot tier | Cool tier | Archive tier | |
| Availability | 99.9% | 99.9% | 99% | Offline |
| Availability(RA-GRS reads) | N/A | 99.99% | 99.9% | Offline |
| 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 object size | N/A | N/A | N/A | N/A |
| Minimum storage duration | N/A | N/A | 30 days1 | 180 days |
| Latency(Time to first byte) | Single-digit milliseconds | milliseconds | milliseconds | hours2 |
Pricing and billing
For Block blob storage, each storage account uses a price scheme depending on the tier of each blob. As a result, keep the following billing issues in mind:
- Storage costs: In addition to the quantity of data stored, the price of storing data varies depending on the access tier. The per-gigabyte cost declines as the tier get cooler.
- Data access costs: Data access charges progress as the tier gets cooler.
- Transaction costs: There’s a per-transaction charge for all tiers that improves as the tier gets cooler.
- Geo-Replication data transfer costs: This charge only employs to accounts with geo-replication configured, including GRS and RA-GRS. Geo-replication data transfer incurs a per-gigabyte charge.
- Outbound data transfer costs: Outbound data transfers incur billing for bandwidth method on a per-gigabyte basis, consistent with general-purpose storage accounts.
- Changing the access tier: Changing the account access tier will result in tier change charges for access tier inferred blobs stored in the account that doesn’t have an explicit tier set.
Reference: Microsoft Documentation