2.9 Azure Storage Accounts and Services
Key Takeaways
- Azure Storage offers four data services in one account: Blob (objects), Files (SMB/NFS shares), Queue (messaging, 64 KB messages), and Table (NoSQL key-value).
- A storage account name is globally unique and forms the endpoint URL, e.g. https://accountname.blob.core.windows.net.
- Redundancy scales from LRS (3 copies, one datacenter) to ZRS (3 zones), GRS/GZRS (6 copies cross-region), with RA- variants adding secondary read access.
- Blob access tiers Hot, Cool (30-day min), Cold (90-day min), and Archive (180-day min, offline, needs rehydration) trade storage cost against access cost.
- Pick Standard general-purpose v2 for almost everything; choose offline transfer (Data Box) only when network bandwidth cannot move the data in time.
Quick Answer: One Azure Storage account holds four services: Blob (objects), Files (SMB/NFS shares), Queue (64 KB messages), and Table (NoSQL). Redundancy runs LRS (3 copies, one datacenter) to GZRS (6 copies, zones + paired region). Blob tiers are Hot, Cool, Cold, Archive. On AZ-900, match the keyword in the question to the service: "shared drive" = Files, "objects/backups" = Blob, "region failure" = GRS/GZRS, "zone failure" = ZRS/GZRS.
What a Storage Account Is
A storage account is a top-level container that gives your data a globally unique namespace. The account name (3-24 lowercase letters and numbers) must be unique across all of Azure because it becomes part of a public endpoint URL. Each service gets its own endpoint built from that name:
| Service | Endpoint format |
|---|---|
| Blob | https://accountname.blob.core.windows.net |
| Files | https://accountname.file.core.windows.net |
| Queue | https://accountname.queue.core.windows.net |
| Table | https://accountname.table.core.windows.net |
A single account can host all four services at once. Data is always reachable over HTTPS (HTTP can be disabled for security), and access is controlled by account keys, shared access signatures (SAS), or Microsoft Entra ID (formerly Azure AD) identities.
Account Types
| Type | Services | Performance |
|---|---|---|
| Standard general-purpose v2 | Blob, Files, Queue, Table | Standard (HDD-backed) |
| Premium block blobs | Blob only | Premium (SSD), high transaction rate |
| Premium file shares | Files only | Premium (SSD) |
| Premium page blobs | Page blobs only | Premium (SSD) |
On the Exam: Standard general-purpose v2 is the default answer for "which account type should I use." It supports every service and every redundancy option. Premium tiers buy lower latency for one specialized workload only.
The Four Data Services
Blob Storage (objects)
Blob (Binary Large Object) Storage holds unstructured data: images, video, backups, logs, documents. There are three blob types: block blobs for general files up to 190.7 TiB, append blobs optimized for logging, and page blobs (up to 8 TiB) that back virtual hard disks for VMs.
Access Tiers
| Tier | Best for | Storage cost | Access cost | Minimum stay |
|---|---|---|---|---|
| Hot | Frequent access | Highest | Lowest | None |
| Cool | Infrequent | Lower | Higher | 30 days |
| Cold | Rare | Lower still | Higher still | 90 days |
| Archive | Offline/long-term | Lowest | Highest | 180 days |
A worked example: you store 10 TB of monthly compliance logs that are written once and almost never read. Keeping them in Hot wastes money on storage you barely touch; Archive is the right tier because the rarely-paid retrieval cost is dwarfed by the storage savings. The trap: Archive data is offline and must be rehydrated to Hot or Cool first, which can take hours — so it is wrong for anything needing instant reads.
Azure Files (shared drives)
Azure Files provides fully managed file shares reachable over SMB (Server Message Block) and NFS (Network File System). Multiple machines mount the same share like a network drive. Azure File Sync caches a cloud share on on-premises Windows servers for hybrid access. Reach for Files whenever a question says "replace a file server," "shared drive," or "lift-and-shift an app that expects SMB."
Queue and Table Storage
- Queue Storage holds messages (up to 64 KB each) for asynchronous, decoupled communication between app components — a web tier drops work; a worker tier picks it up later, so each scales independently.
- Table Storage is a schemaless NoSQL key-value store for large volumes of structured-but-non-relational data. For new projects Microsoft now steers you toward the Cosmos DB Table API instead.
Redundancy Options
| Option | Copies | Protects against |
|---|---|---|
| LRS Locally Redundant Storage | 3, one datacenter | Disk/rack failure (cheapest) |
| ZRS Zone-Redundant Storage | 3 across 3 availability zones | Whole-datacenter (zone) failure |
| GRS Geo-Redundant Storage | 6 = LRS local + LRS in paired region | Entire-region failure |
| GZRS Geo-Zone-Redundant Storage | 6 = ZRS local + LRS in paired region | Zone and region failure |
RA-GRS and RA-GZRS add the ability to read from the secondary region at any time; standard GRS/GZRS only exposes the secondary during a Microsoft-initiated failover. Memory hooks for the exam: "zone" in the question -> ZRS or GZRS; "region"/"disaster recovery" -> GRS or GZRS; "maximum durability" -> RA-GZRS; "lowest cost" -> LRS.
Migration and Movement Tools
| Tool | What it does | Use when |
|---|---|---|
| Azure Migrate | Discover, assess, migrate workloads | Planning a full datacenter move |
| Azure Data Box | Shipped physical appliance (~80 TB usable) | Network is too slow for the volume |
| Azure Data Box Heavy | Larger appliance (~1 PB) | Petabyte-scale offline transfer |
| AzCopy | Scriptable command-line copy | Automated/CI transfers over the wire |
| Storage Explorer | GUI for browsing/managing storage | Interactive ad-hoc management |
The classic AZ-900 scenario names a fixed data size and "limited bandwidth" — that combination signals an offline Data Box, not AzCopy.
A company must move 60 TB to Azure but their internet link would take months to transfer it. Which option fits best?
Which blob access tier stores data most cheaply but keeps it offline so it must be rehydrated before reading?
An application needs a shared drive that several Windows and Linux VMs can mount and read/write simultaneously. Which service fits?
A solution must survive the loss of an entire Azure region with the highest possible durability and allow reads from the secondary at any time. Which redundancy option is correct?