What Azure Storage actually stores, how it prices your data based on how often you touch it, and how many copies it keeps — and where.
You have log files nobody has touched in 8 months. Compliance requires you keep them for 3 years, and if needed, you can tolerate waiting a few hours to retrieve one. Which access tier fits — and what makes it clearly cheaper than the alternatives for this exact pattern?
A storage account is a unique, globally-namespaced container for your data, accessible over HTTP/HTTPS from anywhere. The account type you pick determines which services and redundancy options are available — Standard general-purpose v2 covers most scenarios (blobs, files, queues, tables); the Premium types trade flexibility for higher performance on one specific service.
| Service | What it stores |
|---|---|
| Blobs | Unstructured object data — images, video, logs, backups, analytics datasets |
| Files | Fully managed file shares (SMB/NFS) — a cloud replacement for a file server |
| Queues | Messages for async processing between app components (often paired with Functions) |
| Disks | Block-level storage volumes attached to VMs |
| Tables | NoSQL store for large volumes of structured, non-relational data |
The same data costs different amounts depending on how often you touch it. Access tiers trade storage cost against retrieval cost and speed:
| Tier | Built for | Minimum retention |
|---|---|---|
| Hot | Frequently accessed data (e.g. images on a live website) | — |
| Cool | Infrequently accessed data | 30 days |
| Cold | Infrequently accessed data, held longer | 90 days |
| Archive | Rarely accessed, flexible latency | 180 days |
Cost moves in one direction as you go down this table: storage cost drops, but access cost and retrieval latency rise. Archive has the lowest storage cost and highest rehydration latency — data isn't instantly available, which is exactly why "tolerate waiting a few hours" was the tell in the calibration scenario. (One structural note: Hot/Cool/Cold can be set at the account level, but Archive can only be set at the individual blob level.)
Calibration answer: Archive. Untouched for 8 months, kept for years, and retrieval delay is acceptable — that's precisely the pattern Archive is priced for.
Azure Storage always keeps three copies of your data in the primary region, no matter which redundancy option you pick. What varies is where those three copies live, and whether a second region is involved.
| Option | Primary region | Secondary region |
|---|---|---|
| LRS (Locally redundant) | 3 copies in one datacenter | None |
| ZRS (Zone-redundant) | 3 copies across 3 availability zones | None |
| GRS (Geo-redundant) | LRS (3 copies, one datacenter) | + LRS copy, replicated asynchronously |
| GZRS (Geo-zone-redundant) | ZRS (3 copies across zones) | + LRS copy, replicated asynchronously |
Read the name left to right and it tells you the design: Z means the primary copies are spread across availability zones instead of one datacenter; G means there's also an async copy in a paired secondary region. Durability climbs accordingly — LRS offers at least 11 nines, ZRS at least 12, and GRS/GZRS at least 16 nines of durability per year.
By default, that secondary-region copy (in GRS/GZRS) isn't readable — it only becomes active if you fail over. Add a read-access prefix — RA-GRS or RA-GZRS — to read it directly, before any failover. Just remember it can lag behind the primary by a few minutes (the recovery point objective, typically under 15 minutes).