6.3 Storage Tier & Cost-Performance Trade-off Design

Why Tier and Redundancy Decisions Matter on AZ-305

Every unstructured-data scenario on the exam eventually asks the same underlying question: how do we pay the least for the durability and access latency this workload actually needs? Two independent knobs answer that question: the blob's access tier (how often is it read?) and the storage account's redundancy configuration (how much regional or zone failure can we tolerate?). AZ-305 scenarios routinely combine both in a single question, so treat them as one design decision, not two.

Access Tiers: Hot, Cool, Cold, Archive

Moving or deleting a blob before its minimum retention period has elapsed triggers a prorated early deletion fee. For example, a blob moved to the Cool tier and then deleted after 21 days is billed for the remaining 9 days (30 minus 21) of Cool-tier storage. An Archive-tier blob deleted after 45 days is billed for the remaining 135 days (180 minus 45) of Archive-tier storage — the fee always covers the gap between when the object was deleted and when the minimum retention period would have naturally elapsed.

Archive blobs are offline: they cannot be read or modified until rehydrated to Hot, Cool, or Cold. Rehydration can take up to 15 hours, with a choice between Standard and High rehydration priority (High costs more but completes faster). Lifecycle management policies automate these tier transitions with rules such as "move to Cool 30 days after last modification, move to Archive after 90 days" — this is the standard answer whenever a scenario wants automatic tiering without ongoing operational overhead.

Trap: the Archive tier is supported only on LRS, GRS, and RA-GRS accounts — not on ZRS, GZRS, or RA-GZRS. A scenario asking for zone-redundant archival storage in the same sentence is testing whether you catch this incompatibility; the correct response is to choose LRS or GRS for that workload, or to keep the data in Cold rather than Archive if zone redundancy is a hard requirement.

Redundancy: How Many Copies, and Where?

Two design rules the exam leans on hard:

1. Data-residency requirements override "more redundancy is always better." GRS and GZRS replicate to a Microsoft-paired region that can sit in a different jurisdiction. If regulation requires data to stay in-country, the correct answer is LRS or ZRS, not GRS "for extra safety" — defaulting to geo-redundant options for compliance-sensitive data is a classic AZ-305 trap answer.
2. A regional outage always requires an account failover to restore write access, even with GRS/GZRS. Only RA-GRS and RA-GZRS give you continuous read access without a failover, and even then writes remain unavailable in the primary region until the failover completes.

Changing Redundancy After the Fact

Redundancy is not always a one-time decision. Converting LRS to GRS is a self-service change in the Azure portal. Converting to or from ZRS, however, is a more involved migration (historically requiring a support request or a copy-based migration) because it changes how data is physically laid out across availability zones rather than simply adding an asynchronous replica. If a storage account already has blobs in the Archive tier, Microsoft recommends against changing its redundancy configuration at all, because every archived blob would first need to be rehydrated — a costly and slow operation — before the conversion could proceed. A newer smart tier capability can automatically move data between Hot, Cool, and Cold based on observed access patterns, which is a reasonable answer whenever a scenario wants tiering cost savings without hand-authoring lifecycle management rules, though it does not extend to the offline Archive tier.

Scenario Walkthrough

A hospital system stores 10 years of diagnostic imaging that is essentially never re-read after the first 6 months, but by law must never leave the country and must survive a full regional Azure outage.

Design: this is a deliberately trap-heavy combination. "Survive a full regional outage" argues for GRS or GZRS, but "must never leave the country" rules both out — the correct answer is ZRS (survives a datacenter/zone failure and satisfies the data-residency constraint) combined with a lifecycle management policy that tiers data to Cool at 30 days and Cold at 90 days — not Archive, since 6-month-old imaging may still need occasional retrieval at millisecond, not multi-hour, latency.

Key Takeaways Recap

Tier decisions trade storage cost against access cost and latency; redundancy decisions trade cost against blast-radius protection. The two most commonly tested traps in this pairing are the Archive-tier redundancy restriction (LRS/GRS/RA-GRS only) and the conflict between geo-replication and data-residency requirements, where LRS or ZRS is the correct answer despite GRS sounding "safer."