The access pattern behind the optimization
We stored 980 TB on Azure for $140,000 per year, or approximately $11,667 per month. Within that scope, 95% of objects were no longer read after 30 days. This observation informed a review of data placement across storage tiers.
The percentage concerns objects in this environment. It must not be applied to another estate without measurement. On its own, it also does not establish what share of volume or spending those objects represent: their sizes and constraints need examination.
The analysis needs to connect observed access with future reading and restore requirements. A rarely accessed object may still be needed quickly. Compliance and retention rules may also restrict possible moves.
What online tiering covers
Azure Smart Tier is presented as a mechanism that automates movement between the online Hot, Cool and Cold tiers. It adapts placement to usage. These characteristics need confirmation in the Microsoft documentation applicable to your configuration.
Smart Tier does not automatically move objects to Archive. Archive is an offline tier, with a rehydration delay before data can be read again. That move needs separate control through a lifecycle rule or an explicit action.
Separate data that remains in online tiers from Archive candidates. An archiving decision requires agreement on the acceptable delay and retention rules. A lack of recent reads is insufficient to justify the choice.
The three components of our configuration
Our optimization combined Smart Tier to adapt Hot, Cool and Cold to usage, a lifecycle policy to move eligible data to Archive, and distinct rules according to restore and compliance constraints.
Selecting archivable data was therefore part of the work. The rules needed to distinguish data sets and their recovery requirements. Applying the same move to all storage would have overlooked those differences.
To follow this approach, start by documenting Archive eligibility criteria and who validates them. Then check that online and offline rules match that decision. These are methodological suggestions to adapt to your own environment.
Read the gains within their scope
The annual bill fell from $140,000 to $35,000. Monthly equivalents are approximately $11,667 before and $2,917 after. The monthly difference of $8,750 corresponds to $105,000 per year: 140,000 - 35,000 = 105,000.
This result comes from combining automatic tiering, lifecycle management and selection of archivable data. It does not quantify the saving contributed by each individual action. These figures describe this case and are not independently verified here.
Savings in another environment need recalculating using its volumes, access and retention rules. A configuration with more rereads or less Archive-eligible data may produce a different result.
Estimate access costs and test rehydration
Price per GB is insufficient to compare scenarios. Include access costs, applicable minimum durations and the rehydration delay. Check their compatibility with the planned data lifetime and restore requirements.
To prepare a pilot, measure access, identify objects inactive after 30 days and segment data sets by their constraints. Document Archive rules, then test recovery within the selected scope before wider rollout.
After implementation, compare the bill with observed usage and check rehydrated data. If rereads become recurring, examine the relevant rules. Tracking needs to support correcting placement rather than retaining an estimated saving that no longer matches actual access.
The post behind this insight
Expanded from the LinkedIn post. The links below come from the original post; listing them does not imply independent verification.
LinkedIn ↗