1. Redundancy as an Architecture Decision
Storage redundancy isn't a checkbox — it's a cost-vs-resilience trade-off that directly affects your RTO and RPO. Every option replicates data synchronously within its primary region unless noted.
🔑 Choosing Redundancy — Decision Framework
| Option | Survives | RPO | Cost (relative) | Use When |
|---|---|---|---|---|
| LRS | Disk/rack failure | 0 (sync) | 1× | Dev/test; data easily recreated; cost-sensitive non-critical |
| ZRS | AZ outage | 0 (sync) | ~1.25× | Production workloads needing HA without geo-replication |
| GRS | Full region loss | ~15 min (async) | ~2× | Business-critical data with regional DR requirement |
| GZRS | AZ outage + region loss | ~15 min (async to secondary) | ~2.5× | Maximum durability — regulated/mission-critical data |
⚠️ Key Nuance: GRS replicates asynchronously to the secondary region. A region failure before replication completes = data loss (RPO ~15 min). If you need RPO = 0, you must architect at the application layer (write to two regions yourself) — Azure storage alone cannot guarantee it.
2. RA-GRS/RA-GZRS: Read-Access Secondaries
Standard GRS keeps the secondary region offline until Microsoft initiates failover. RA-GRS (and RA-GZRS) adds a read-only endpoint you can use immediately — no failover needed.
🔑 Consistency Model
- Eventually consistent — secondary may lag primary by up to ~15 minutes
- Check
Last-Sync-Timeheader to know how stale the secondary is - Read from
accountname-secondary.blob.core.windows.net - Writes always go to primary — secondary is read-only
🔑 Architecture Patterns for RA-GRS
- Read offload: Route analytics/reporting reads to secondary, reducing primary load
- Circuit breaker: If primary returns errors, auto-switch reads to secondary (accept stale data)
- Static content DR: Serve static assets from secondary if primary region is down
⚠️ Failover Impact: Customer-initiated failover promotes the secondary to primary. After failover completes, the account becomes LRS in the new region. You must re-configure geo-replication after recovery.
3. Access Tiers & Lifecycle Management
Access tiers let you align storage cost with access frequency. The architecture decision: automate tier transitions to optimize cost without manual intervention.
🔑 Lifecycle Policy Architecture
- Rules run daily — tier transitions and deletions evaluated once per day
- Scope by prefix/blob index tags — different policies for different data classes (e.g.,
logs/vsmedia/) - Early deletion penalty: Cool = 30 days min, Cold = 90 days min, Archive = 180 days min — moving data back before minimum = charged full retention
- Rehydration from Archive: Standard (up to 15 hours) or High Priority (under 1 hour, 10× cost)
🔑 Cost Architecture Heuristic
If you access a blob less than once per 30 days, Cool saves money. Less than once per 90 days → Cold. Less than once per 180 days → Archive. Model your access pattern, then automate with lifecycle rules.
4. Immutable Storage — WORM Policies
Write Once Read Many (WORM) ensures data cannot be modified or deleted for a defined retention period — required for SEC 17a-4, HIPAA, GDPR right-to-deletion timelines, and financial audit trails.
🔑 Two Immutability Models
- Time-based retention: Data cannot be modified/deleted until the retention interval expires. Can be locked (irreversible) or unlocked (extendable but not shortenable).
- Legal hold: Indefinite immutability until the hold is explicitly cleared. No retention period — stays until legal/compliance team removes it. Multiple holds can stack (named tags).
🔑 Architecture Considerations
- Immutability is set at container level (or account-level with version-level WORM)
- Version-level WORM (preview → GA) allows per-blob policies — more flexible than container-level
- Locked policies cannot be shortened or removed — even by Owner or Microsoft support. Test thoroughly before locking.
- Combine with lifecycle management: immutable blobs can still be tiered to Archive (saves cost during retention period)
⚠️ Irreversibility: Once a time-based retention policy is locked, it cannot be deleted or shortened — only extended. A 7-year locked policy means that data physically cannot be removed for 7 years, even if the business requirement changes. Always start unlocked and lock only after legal sign-off.
5. File Storage Decisions
Three Azure services provide file-system semantics. Choosing the right one depends on protocol needs, performance tier, and migration source.
🔑 Comparison Grid
| Criteria | Azure Files | Azure NetApp Files | Blob NFS 3.0 |
|---|---|---|---|
| Protocols | SMB 3.x, NFS 4.1 | NFS 3/4.1, SMB 3.x | NFS 3.0 only |
| Performance | Standard (HDD) or Premium (SSD) Up to 100K IOPS | Ultra/Premium/Standard Up to 450K IOPS, sub-ms latency | Flat namespace blob Good throughput, higher latency |
| Max Size | 100 TiB per share | 100 TiB per volume 500 TiB per pool | Unlimited (blob storage) |
| Best For | Lift-and-shift file shares, home dirs, SMB apps | SAP, Oracle, HPC, latency-sensitive workloads, on-prem NetApp migration | Linux apps needing NFS over cheap blob storage (data lakes, ML datasets) |
| Cost Model | Pay per GiB provisioned (premium) or used (standard) | Pay per capacity pool provisioned (min 4 TiB) | Pay per GiB used (blob pricing) |
| Identity Integration | AD DS / Entra DS for SMB | AD DS for both protocols | No identity — POSIX UID/GID at container level |
| Snapshots/Backup | Share snapshots, Azure Backup | NetApp snapshots, cross-region replication | Blob snapshots/versioning |
🔑 Decision Flow
- Need SMB + AD integration? → Azure Files (or NetApp if you need sub-ms latency)
- Migrating from on-prem NetApp/ONTAP? → Azure NetApp Files (familiar snapshots, replication)
- Need NFS + cheap storage for analytics? → Blob NFS 3.0
- Sub-millisecond latency requirement? → Azure NetApp Files (only option)
- Budget-constrained lift-and-shift? → Azure Files Standard tier
6. Storage Networking — Zero-Trust Architecture
By default, storage accounts accept traffic from all networks. In a zero-trust design, you restrict to specific networks and access paths.
🔑 Three Network Isolation Mechanisms
| Mechanism | How It Works | Limitations | Use When |
|---|---|---|---|
| Storage Firewall (IP/VNet rules) |
Allow-list of public IPs or VNet subnets; deny all others | Public endpoint still exists; max 200 IP rules; max 200 VNet rules | Quick restriction for known IPs; hybrid scenarios with on-prem IPs |
| Service Endpoints | Optimal route from VNet subnet → storage public endpoint (stays on Azure backbone) | Traffic still hits public endpoint (just from allowed subnet); no on-prem access; source IP = private but destination = public IP | Cost-free network restriction; acceptable when you don't need private DNS or on-prem private access |
| Private Endpoints | NIC with private IP in your VNet; storage gets a private IP; public access can be fully disabled | Cost per endpoint (~$7.30/mo + data processing); requires Private DNS Zone for name resolution | Zero-trust production; on-prem access via VPN/ExpressRoute; fully eliminate public exposure |
🔑 Architect's Recommendation
- Production / regulated: Private Endpoints + disable public access. Use Azure Private DNS Zones (
privatelink.blob.core.windows.net) for resolution. - Multi-VNet access: Private Endpoints in each VNet (or use hub VNet with DNS forwarding).
- Cost-sensitive non-critical: Service Endpoints are free and good enough if you don't need on-prem private access.
- Combine layers: Private Endpoint + Storage Firewall (deny public) + Entra ID RBAC data-plane = defense in depth.
AZ-305 Exam Tip: If the question mentions "on-premises access to storage without traversing the public internet," the answer is Private Endpoint (accessed via VPN/ExpressRoute). Service Endpoints only work from within Azure VNets.
7. Data Lake Storage Gen2
ADLS Gen2 = Azure Blob Storage + Hierarchical Namespace (HNS). It's not a separate service — it's a storage account feature you enable at creation.
🔑 When to Enable Hierarchical Namespace
- Big data analytics — Databricks, Synapse, HDInsight perform atomic directory operations (rename/move thousands of files in O(1) instead of O(n))
- ACL-based security — POSIX-like ACLs at folder/file level (in addition to RBAC)
- Multi-protocol access — Blob API + DFS API + NFS 3.0 + SFTP (all on same account)
- Structured data lake zones — raw/curated/enriched folders with different ACLs per team
🔑 When NOT to Use HNS
- Pure object storage (CDN, static websites) — no benefit from hierarchy
- Need Blob features not yet supported on HNS (check current limitations — some features lag)
- Cannot be disabled after creation — plan ahead
⚠️ Irreversible: HNS cannot be disabled once enabled. If you enable it and later decide you don't need it, you must create a new account and migrate data. Always decide at account design time.
8. Real-World: Media Company Storage Architecture
📐 Scenario: Global Media Company — 50TB/day Ingest
A media company ingests 50 TB of video daily, processes it within 24 hours, and must retain raw footage for 7 years (SEC compliance). Processed derivatives are accessed frequently for 30 days, then rarely.
Architecture Decision Record
| Component | Decision | Rationale |
|---|---|---|
| Ingest Account | Hot tier, ZRS, HNS enabled | High write throughput; AZ resilience for active processing; HNS for efficient directory renames during pipeline stages |
| Redundancy | GZRS for raw footage; ZRS for derivatives | Raw footage is irreplaceable (geo-protection). Derivatives can be reprocessed (AZ protection sufficient) |
| Lifecycle — Derivatives | Hot 30d → Cool 90d → Archive 180d → Delete 2yr | Access drops sharply after 30 days. Archive is 1/20th the cost of Hot. 2-year retention per business policy |
| Lifecycle — Raw Footage | Hot 7d → Cool 30d → Cold 90d → Archive 180d | Processing completes within 24h; rare re-processing after 7 days; 7-year WORM for compliance |
| Compliance | Time-based retention (7yr, locked) on raw container | SEC requires immutable retention. Locked = even admins can't delete |
| Networking | Private Endpoints from processing VNet; public disabled | Zero-trust: only the processing pipeline accesses storage. CDN fronts delivery tier separately |
| Delivery Tier | Separate account, Hot, LRS, CDN-fronted | CDN handles resilience; LRS sufficient for cached/derivable content |
Monthly Cost Impact of Lifecycle Policies
Without lifecycle rules: ~$1M/mo at Hot tier for 1.5 PB cumulative.
With lifecycle automation: ~$180K/mo — 82% reduction by tiering aging data automatically.
AZ-305 Exam Tip — Storage Redundancy Questions: The exam loves scenarios where you must balance cost against data criticality. Key patterns:
- "Data can be recreated" → LRS (cheapest, recreate on failure)
- "Must survive AZ failure" → ZRS
- "Must survive regional disaster" → GRS/GZRS
- "Need read access during outage without failover" → RA-GRS/RA-GZRS
- "Lowest cost + regional protection" → GRS (not GZRS) — ZRS primary adds cost