Implement and manage storage
Choose the account type before you create it
Most storage questions are decided at creation time. Standard general-purpose v2 covers blobs, files, queues, and tables. Premium accounts are specialized for block blobs, file shares, or page blobs, each with its own redundancy options. Redundancy: LRS keeps three copies in one datacenter; ZRS spreads three copies across availability zones in one region; GRS copies LRS data asynchronously to a paired region; RA-GRS adds read access to that secondary; GZRS and RA-GZRS combine zones with region pairing. After a failover, the account becomes locally redundant in the former secondary region.
Blobs, tiers, and lifecycle
Blob access tiers are hot, cool, cold, and archive, set as an account default or per blob. Archive is offline: reads fail until rehydration completes, which can take hours (high priority is faster and costs more). Lifecycle management rules automate tiering and deletion using filters on base blobs, snapshots, and versions. Container access levels are private, blob, and container; many subscriptions now disable anonymous access entirely.
Securing and sharing data
Every account has shared key access; prefer Entra ID authorization with a user delegation SAS where possible. Service and account SAS tokens can be revoked only when tied to a stored access policy. Soft delete, versioning, and immutable (WORM) policies protect against deletion and tampering. Azure Files offers SMB and NFS shares with share snapshots.
Worked rule of thumb
Map requirements to redundancy first: read access during an outage means RA-GRS or RA-GZRS; zone-failure tolerance means ZRS or GZRS. Then choose tiers, because later replication conversion is restricted. Traps: assuming archive blobs are readable, assuming a SAS can be revoked without a stored access policy, and assuming the secondary endpoint is current.