In one sentence. A storage account is a rented drive with a web address that serves files four ways, and the redundancy setting decides how many copies Azure keeps and whether some live in a second city. A storage account is a very large, rented hard drive with a web address. It can serve files four ways: as individual objects over HTTPS (Blob), as a network share you map as a drive letter (Files), as message queues, and as simple tables. Azure always keeps at least three copies of everything; you choose whether some copies live in a second city.
You, the admin: create the account for invoices
- Storage accounts › + Create. Basics: resource group RG-Data, name
contosoinvoices01(3 to 24 lowercase letters and digits, unique in all of Azure), region Australia East, Performance Standard, Redundancy LRS (change later if needed). - Advanced tab: leave "Require secure transfer" on; leave anonymous blob access off; minimum TLS 1.2.
- Networking tab: Public access from all networks for now (you lock it down in the access lesson).
- Data protection tab: tick soft delete for blobs and containers (7 days).
- Review + create. In about 30 seconds the account exists with endpoints like
https://contosoinvoices01.blob.core.windows.net.
Script: az storage account create -n contosoinvoices01 -g RG-Data -l australiaeast --sku Standard_LRS --kind StorageV2
How a storage account is set up
- Create the accountUnique lowercase name, region, Standard or Premium, redundancy.
- Create containers or shares inside itA container for blobs (invoices), a file share for mapped drives (finance).
- Decide who gets inFirewall for networks, Entra roles for people, SAS for temporary outsiders, keys locked away.
- Protect and age the dataSoft delete and versioning for undo; lifecycle rules to move old files to cheaper tiers.
Kinds of account
| Kind (wizard: Performance) | Disks | Redundancy allowed | Pick when |
|---|---|---|---|
| Standard general-purpose v2 | HDD | All six | Almost always. All services, all blob tiers. |
| Premium: block blobs | SSD | LRS, ZRS | Many small files, low latency. No cool/archive. |
| Premium: file shares | SSD | LRS, ZRS | Databases on a share; the only kind with NFS. |
| Premium: page blobs | SSD | LRS | Legacy unmanaged VM disks. |
Redundancy: how many copies, how far apart
| Setting | Copies | Survives | Can you read the far copies? |
|---|---|---|---|
| LRS | 3 in one building | A disk or rack failing | — |
| ZRS | 3 in three buildings in the city | One building going dark | — |
| GRS | 3 here + 3 in the paired city | The whole region (after a failover) | No |
| GZRS | ZRS here + 3 in the paired city | Building and region | No |
| RA-GRS / RA-GZRS | Same | Same | Yes, any time, at the -secondary address |
Change it later under Storage account › Redundancy. Some changes (into or out of ZRS) are a conversion request rather than a click. Premium never offers geo. The paired city is fixed by Microsoft (Australia East ↔ Australia Southeast). The far copy lags by minutes; the lag is shown as Last Sync Time.
Trap wording. "Minimise cost" and no mention of a regional outage = LRS. "Applications must keep reading during a regional outage" = RA-GRS or RA-GZRS. "Premium" + "geo-redundant" together is impossible.