Storage

A storage account is the single Azure resource that holds blob containers, Azure Files shares, queues, and tables under one globally-unique namespace, and the account-level choices you make cascade to everything inside it: performance tier, redundancy, encryption, and the network firewall are all set once on the account and apply to every service it contains. That is why this domain reads in three layers and why the subtopics are ordered the way they are: first you decide who can reach the account at all (Storage Access: firewall plus authorization), then you create and shape the account itself (Storage Accounts: tier, redundancy, encryption, replication), and only then do you put data services on top (Files and Blob Storage: containers, shares, tiers, protection). When two workloads need different redundancy, encryption, or firewall rules, the answer is two accounts, because these settings are not per-container.

Every storage account keeps multiple synchronous copies of your data; the redundancy option only decides where, and it answers two independent questions. Within the primary region, locally redundant storage (LRS) keeps three copies in one datacenter, while zone-redundant storage (ZRS) writes synchronously across three availability zones. Layering an asynchronous copy in the paired secondary region on top of either gives geo-redundant storage (GRS, built on LRS in the primary) or geo-zone-redundant storage (GZRS, built on ZRS): so GRS and GZRS differ only in how the primary spreads its copies, and the secondary always uses LRS. Durability climbs with the blast radius each option survives: LRS reaches at least eleven 9s and survives drive/rack failure, ZRS at least twelve 9s and survives a zone (datacenter) outage, and both geo options at least sixteen 9s and survive a region-wide disaster, at progressively higher cost (redundancy options).

Every request to a storage account clears two checks that are evaluated separately: the network layer (the storage account firewall) decides whether the request is even allowed in from where it originates, and the authorization layer decides whether the caller has proven a right to the data. Both must pass, and passing one never substitutes for the other. The trap is that a brand-new account's public endpoint accepts connections from any network until you switch it to selected networks and add virtual-network or IP rules; the firewall is deny-only-after-you-restrict. On the authorization side you choose how the caller proves identity: the two 512-bit account access keys are a full-access master credential you rotate one at a time, a shared access signature (SAS) grants scoped, time-boxed delegated access, and Microsoft Entra ID is the preferred path because it never exposes a key (Configure access to storage).

Redundancy protects against hardware and regional failure, but it copies deletes and overwrites to every replica, so it does nothing against an accidental or malicious change: that is a separate set of features, and they do not overlap cleanly. Blob soft delete recovers an individual deleted or overwritten blob for 1–365 days but does NOT bring back a deleted container (that needs container soft delete enabled separately) and does NOT bring back a deleted account (only a resource lock prevents that). Snapshots are manual point-in-time read-only copies you take yourself; blob versioning is the automated equivalent that captures a new immutable version on every write with no application change. Microsoft recommends turning on blob soft delete, container soft delete, and versioning together, and using a lifecycle-management policy to auto-tier or expire blobs by age so cost optimization runs without manual moves.