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.
New to cloud? CAMPUX is a free, build-first course. Start here →
Azure has four current storage account types: standard general-purpose v2, premium block blobs, premium file shares, and premium page blobs. Standard general-purpose v2 is the right answer for most workloads. You cannot change the type after creation — you would create a new account and copy the data.
That is the short version, and it is where most guides stop. The part they skip: two more account types still exist in real estates (general-purpose v1 and the legacy Blob Storage account), both are being retired, and half the settings people think are locked to the type — redundancy, access tier, hierarchical namespace — are separate decisions. This note sorts which is which.
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 |
GPv1 vs GPv2 vs Blob Storage: the legacy types, and what StorageV2 means
Search the portal, an ARM template, or an old runbook and you will meet three names the current list does not carry: general-purpose v1, the legacy Blob Storage account, and the classic (ASM) account. All three are retired or retiring. Here is what separates them.
| Account type | Holds | Access tiers | Lifecycle management | Status |
|---|---|---|---|---|
| Standard general-purpose v2 | Blob, File, Queue, Table | Yes — hot, cool, cold, archive | Yes | Current, recommended default |
| Premium block blobs | Block and append blobs | Cannot be tiered to hot, cool, cold, or archive | Yes, but no tiering action | Current |
| Premium file shares | Azure Files (SMB and NFS) | Not applicable | No | Current |
| Premium page blobs | Page blobs only | Not applicable | No | Current |
| General-purpose v1 | Blob, File, Queue, Table | No | No | Retiring — full retirement October 2026 |
| Blob Storage (legacy) | Block and append blobs | Yes — default set at creation | Yes | Legacy — upgrade to GPv2 |
| Classic (ASM) | Blob, File, Queue, Table | No | No | Retired 31 August 2024 |
StorageV2 is just the API name for GPv2
If you have read a template or an az storage account output and wondered what StorageV2 is: it is the resource kind Azure uses for a general-purpose v2 account. Storage means GPv1. BlobStorage means the legacy Blob Storage account. Nothing exotic — the portal shows one label, the API shows another.
GPv2 vs the legacy Blob Storage account
Both support access tiers and lifecycle management, so the difference is scope. A Blob Storage account holds block and append blobs only. A GPv2 account holds all four services, supports the full redundancy range including ZRS and GZRS, and is the one Microsoft recommends. Microsoft's guidance on legacy Blob Storage accounts is direct: upgrade them to GPv2.
Microsoft announced the GPv1 retirement in September 2025. Creation of new GPv1 accounts is disabled from September 2026, and full retirement lands in October 2026 — any GPv1 account still standing is auto-migrated to GPv2, which can raise the bill. The upgrade is in-place, needs no downtime, and is permanent. Set the default access tier during the upgrade so you do not inherit a charge you did not plan for. The same in-place upgrade path covers legacy Blob Storage accounts.
Pick the type once, deliberately — it is the one storage setting you cannot walk back without a migration.
Is an Azure storage account IaaS or PaaS?
A storage account is PaaS. Microsoft's own shared-responsibility guidance lists Azure Storage alongside App Service, Functions, and SQL Database as a platform-as-a-service example. You never see a server, an operating system, or a disk controller; you get an endpoint, a namespace, and a bill.
The confusion is worth naming, because it is a fair one. The same guidance puts Azure Disk Storage in the IaaS column — a managed disk attached to a virtual machine you patch and run. So "Azure storage" spans both models: the storage account is the PaaS half, managed disks are the IaaS half. In the PaaS split, Microsoft runs the operating system, the physical hosts, and the network underneath. You still own the data, the configuration, the identities, and the access controls on the account.
Azure storage account name rules: length, characters, and global uniqueness
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.
So a naming convention for storage accounts has to survive with no separators at all. Most teams settle on a squashed pattern — workload, environment, region, index, all lowercase, all run together — and accept that 24 characters goes fast. Put the parts that vary at the end so a collision costs you one character, not a rewrite.
How many storage accounts can you have per subscription?
By default, 250 storage accounts with standard endpoints per region per subscription, counting standard and premium accounts together. A quota increase takes that to 500. The limit is per region, not per subscription overall — so a subscription spread across five regions has five separate 250-account budgets.
A few other account-level ceilings that come up in the same breath: 5 PiB default capacity per account, 400 IP address rules, 400 virtual network rules, and 200 private endpoints per account. There is no limit on the number of containers, blobs, file shares, tables, or queues inside one account. Request rate and bandwidth caps vary by region and can be raised by support.
What you can still change after creation
The type is fixed. Almost everything else people assume is baked in is not, which is worth knowing before you provision a second account you do not need.
Replication and redundancy types
Redundancy is a separate setting from type: LRS, ZRS, GRS, RA-GRS, GZRS, and RA-GZRS, with the options varying by account type and by region. You can change it after creation, with two catches — archived blobs block a redundancy change until they are rehydrated, and archive itself is only supported on LRS, GRS, and RA-GRS. We walk the six options and their failure domains in LRS, ZRS, GRS: which storage redundancy to pick.
Access tiers
Hot, cool, cold, and archive are blob-level settings on a GPv2 or legacy Blob Storage account. The account carries a default access tier that new blobs inherit, and that default can be hot, cool, or cold — archive cannot be the account default. A new GPv2 account defaults to hot. Retention minimums differ (30 days cool, 90 cold, 180 archive) and early deletion is charged. The tier comparison lives in Blob storage access tiers: hot, cool, cold, archive.
Hierarchical namespace
Data Lake Storage is not an account type. It is a capability you turn on with the hierarchical namespace setting on a standard general-purpose v2 or premium block blob account. Enable it at creation on the Advanced tab, or upgrade an existing blob account to it afterwards.
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.
Questions people also ask
Can you change a storage account type after creation?
No, not directly. The type is fixed at creation. The exception is a one-time, in-place, no-downtime upgrade to general-purpose v2 from either a general-purpose v1 account or a legacy Blob Storage account. That upgrade is permanent. For any other change, you create a new account with the type you want and copy the data over.
What is the difference between general-purpose v1 and v2 storage accounts?
GPv1 has no access tiers and no lifecycle management, so every byte sits at one flat rate whether you read it constantly or never touch it again. GPv2 adds hot, cool, cold, and archive tiers, lifecycle management, immutable blob storage, and the wider redundancy range. GPv1 is being retired: new GPv1 accounts cannot be created from September 2026, and full retirement is October 2026.
What is StorageV2 in Azure?
StorageV2 is the resource kind that Azure Resource Manager uses for a standard general-purpose v2 storage account. It is the same thing the portal calls general-purpose v2. The kind Storage means a general-purpose v1 account, and BlobStorage means a legacy Blob Storage account.
What is the difference between StorageV2 and a Blob Storage account?
Both support access tiers and lifecycle management, so the difference is scope. A legacy Blob Storage account holds block and append blobs only. A StorageV2 account holds blobs, files, queues, and tables, and supports the full redundancy range including ZRS and GZRS. Microsoft recommends general-purpose v2 over Blob Storage accounts.
Is an Azure storage account IaaS or PaaS?
PaaS. Microsoft's shared-responsibility guidance lists Azure Storage as a platform-as-a-service example, next to App Service, Functions, and SQL Database. The same guidance puts Azure Disk Storage under IaaS, which is where the confusion comes from: a managed disk attached to a virtual machine is IaaS, a storage account is not.
What is a premium storage account used for?
A premium account trades flexibility for speed: it runs on SSDs for consistently low latency and high throughput. Each premium account holds one kind of data only, block blobs, file shares, or page blobs, unlike GPv2 which holds all four services. Reach for one only after you have measured a latency need standard cannot meet.
What do premium block blob storage accounts support?
Block blobs and append blobs, and nothing else. No page blobs, no file shares, no queues, no tables. Data in a premium block blob account cannot be moved to the hot, cool, cold, or archive tiers. It does support Data Lake Storage capabilities when the hierarchical namespace is enabled.
How many storage accounts can you have in one Azure subscription?
By default, up to 250 storage accounts with standard endpoints per region per subscription, counting standard and premium accounts together. A quota increase raises that to 500. The limit is per region, so a subscription that spans five regions has five separate budgets.
What are the naming rules for an Azure storage account?
3 to 24 characters, lowercase letters and numbers only, no hyphens or capitals, and globally unique across all of Azure, not just your subscription. The name becomes a public DNS subdomain at name.blob.core.windows.net, which is why it has to be unique everywhere, not just within your own account list.
Is the archive access tier set at the storage account or on the blob?
On the blob. Archive is an offline tier you apply per blob, and it cannot be the account default. A storage account carries a default access tier that new blobs inherit, and that default can only be hot, cool, or cold. Archive is also limited to LRS, GRS, and RA-GRS accounts.
Which storage accounts can you use lifecycle management with?
Lifecycle management policies are supported for block blobs and append blobs in general-purpose v2, premium block blob, and Blob Storage accounts. Tiering is not supported inside a premium block blob account, so there a policy can delete but not move data between tiers. Policies cannot rehydrate an archived blob.
What is required to provision Azure Data Lake Storage in an Azure storage account?
A storage account with the hierarchical namespace enabled. Two account types support it: standard general-purpose v2 and premium block blobs. You turn the setting on under the Advanced tab when you create the account, or upgrade an existing blob account to Data Lake Storage afterwards.
Which settings are enabled by default when you create a storage account in Azure?
Secure transfer required is on by default, so any request over plain HTTP is rejected. Encryption at rest is always on and cannot be turned off. A new general-purpose v2 account defaults to the hot access tier. In the portal, require encryption in transit is on by default for SMB and NFS file shares.
What are the Azure storage account replication types?
Six: locally redundant storage (LRS), zone-redundant storage (ZRS), geo-redundant storage (GRS), read-access geo-redundant storage (RA-GRS), geo zone-redundant storage (GZRS), and read-access geo zone-redundant storage (RA-GZRS). Which ones you can pick varies by account type and by region, and unlike the account type, redundancy can be changed later.