How to review an Azure hot-tier storage candidate
Blob data is a cooler-tier candidate when access patterns, retention needs, retrieval latency, minimum-duration rules, and total cost indicate Hot is no longer the right tier. Lower storage price alone is not the decision.
Pilot tiering on a bounded data prefixWho reviews this signal?
- Accountable owner
- Data / storage owner
- Review cadence
- Monthly
Check observation dates and read-only scope. Your team approves and implements changes outside Costframe.
How this finding happens
- →Archive, logs, or backups inherit the storage account’s default Hot tier.
- →Lifecycle rules are missing, overly cautious, or no longer match access patterns.
- →Teams optimize storage price without measuring retrieval and early-deletion costs.
Collected evidence and verification limits
Checked when available
- ✓Blob/account tier, size, age, last-access evidence where enabled, and operation history
- ✓Lifecycle policy, replication, encryption, immutability, and retention configuration
- ✓Read/retrieval frequency and acceptable rehydration latency
- ✓Storage, operation, retrieval, and early-deletion price inputs
Not always verifiable
- —Last-access tracking may not be enabled or may add operational considerations.
- —Archive rehydration time may be unacceptable for the workload.
- —Cool/cold/archive economics include access, retrieval, and minimum-duration charges.
Missing or stale evidence is a limitation, not a passed check.
Why this finding might be wrong
These conditions lower confidence or require manual owner review before action.
- Rare but urgent recovery data
- Data with imminent planned access
- Immutable or compliance-controlled data with specific tier policy
- Workload whose read transaction cost outweighs storage savings
Plan the change and recovery path.
- Classify data by access frequency, retrieval latency, retention, durability, and compliance.
- Model total cost across storage, transactions, retrieval, rehydration, and early deletion.
- Pilot lifecycle rules on a bounded prefix/container and monitor access.
- Expand gradually with exclusions and a documented rehydration procedure.
Rollback / recovery
Move data to a warmer tier or rehydrate archived blobs; account for delay and fees. Keep the retrieval runbook tested before broad tiering.
How savings are calculated
Estimated net saving = Hot storage cost − target storage cost − expected transaction/retrieval/early-deletion cost. Never compare storage-only rates in isolation.
Do not quote a quantified saving when the billing scope, pricing basis or required workload evidence is incomplete or stale. Treat a modeled amount as estimated until suitable billed outcomes support it.
Check the billed outcome
Total cost falls over a representative access cycle and retrieval SLOs remain achievable.
Pilot tiering on a bounded data prefix
Choose data with known retention and access needs. Compare storage savings with transactions, retrieval, early deletion and rehydration costs. Test retrieval latency on that prefix before expanding the lifecycle rule; recovery data may need a warmer tier despite infrequent reads.
Review retention before removing copiesIf the owner cannot resolve a dependency or recovery requirement, keep the candidate in review rather than treating it as approved.