Azure storage account types: which one to create (and why v2 is the default)
The create-storage-account dialog asks for a "type" before you have stored a single byte — and, unlike most Azure settings, you cannot change your answer later. Here is what the choices mean and why one of them is almost always right.
A storage account is the container for a surprising amount of Azure: Microsoft describes it as holding "all of your Azure Storage data objects: blobs, files, queues, and tables," under "a unique namespace... accessible from anywhere in the world over HTTP or HTTPS." One account, four data services, one globally unique name. The "type" you pick decides which services and performance tier that account supports — and because you cannot change the type after creation (you would create a new account and copy the data), it is worth understanding before you click Create.
The one you almost always want: Standard general-purpose v2
Microsoft is unambiguous: standard general-purpose v2 (GPv2) is "recommended for most scenarios that use Azure Storage." It supports all four services — Blob, File, Queue, Table — on standard (HDD-backed) storage, with the full range of redundancy options (LRS through GZRS) and access tiers (hot/cool/cold/archive). If you are not sure, this is the answer. It is the flexible default that covers the vast majority of workloads, and every other type is a deliberate deviation for a specific reason.
The premium types: paying for low latency
Premium accounts use SSDs for consistently low latency and high throughput, and — this is the catch — each is specialized. Unlike GPv2, a premium account holds one kind of data:
- Premium block blobs — for blob workloads with high transaction rates, small objects, or a need for consistently low storage latency.
- Premium file shares — for Azure Files only, including SMB and NFS shares; the choice for enterprise or high-performance file workloads.
- Premium page blobs — for page blobs (the backing format for certain disk-style workloads).
You reach for premium when you have measured a latency or throughput need that standard cannot meet — not by default. Most apps never need it.
| Type | Holds | Performance | Reach for it when… |
|---|---|---|---|
| Standard GPv2 | Blob, File, Queue, Table | Standard (HDD) | Almost always — the default |
| Premium block blobs | Block/append blobs | Premium (SSD) | High transactions, low latency |
| Premium file shares | Azure Files | Premium (SSD) | High-performance SMB/NFS files |
| Premium page blobs | Page blobs | Premium (SSD) | Page-blob workloads |
You will still see general-purpose v1 and the old Blob Storage account in docs and old estates. Both are legacy — Microsoft recommends upgrading them to GPv2 (an in-place, no-downtime upgrade) to get modern features like access tiers and lifecycle management. The classic (ASM) storage account is fully retired. For anything new, GPv2 is the only sensible standard choice.
Pick the type once, deliberately — it is the one storage setting you cannot walk back without a migration.
The naming rule that trips people
One practical gotcha, since it will fail your first deploy if you miss it: a storage account name must be 3 to 24 characters, lowercase letters and numbers only, and globally unique across all of Azure. No hyphens, no capitals, and if storage01 is taken worldwide, you cannot have it. The global endpoint — <name>.blob.core.windows.net — is why: your name becomes a public DNS subdomain, so it has to be unique everywhere.
The takeaway
Nearly every real decision is: Standard general-purpose v2, then choose redundancy (from LRS to GZRS) and access tier (hot/cool/cold/archive) to match the data — those you can tune later. Premium types are a measured exception for latency-critical workloads, one data kind each. Legacy types are for recognising, not creating. Say "GPv2 by default, premium only when I have a measured latency need, and the type is fixed at creation" and you sound like someone who has provisioned storage in anger rather than clicked through a wizard once.