Azure Storage Account Types and Performance Tiers

A storage account is the one Azure resource almost everything else leans on. Virtual machine disks sit on it, App Service backups land in it, diagnostic logs drain into it, and any application needing to keep a file somewhere durable eventually points at it. That makes it worth understanding properly rather than accepting the defaults, because a handful of decisions made at creation time can't be undone without building a new account and copying the data across.

The five services inside one account

A storage account is a container for five distinct services, each with its own endpoint and its own access model.

Choosing between them is mostly a question of the access pattern rather than the data itself.

Massive unstructured data goes in Blob Storage. It's optimised for exactly that, objects are reachable from anywhere over HTTP or HTTPS, and it's the right answer for serving data directly to a browser, streaming, and backup and restore.

Shared file access goes in Azure Files, which supports highly available network file shares. On-premises apps that already use file shares migrate with minimal change, and multiple machines can mount the same share with read/write access.

Asynchronous work goes in Queue Storage. Typically to build a backlog of work to process later. I covered the messaging and event services, including where Queue Storage stops being the right answer and Service Bus takes over, in Azure Messaging and Events: Service Bus, Event Hubs, Event Grid.

Structured non-relational data goes in Table Storage, which provides throughput-optimised tables, global distribution, and automatic secondary indexes.

Microsoft's own training material describes Table Storage as "part of Azure Cosmos DB". That's loose enough to mislead. Table Storage is its own service inside the storage account, billed at storage-account rates; Cosmos DB separately offers a Table API that speaks the same protocol with Cosmos DB's throughput and distribution model behind it. Two products, one wire format — not one product.

Naming and the namespace

One of the benefits of a storage account is having a unique namespace in Azure for your data, and that's the reason for the naming constraint: every storage account name must be unique across all of Azure, not just within your subscription. The combination of the account name and the service endpoint forms the endpoints for the account — https://<account>.blob.core.windows.net, https://<account>.file.core.windows.net, and so on.

Two rules to keep in mind:

• Names must be between 3 and 24 characters, and may contain lowercase letters and numbers only.
• No two storage accounts anywhere in Azure can share a name.

Regions and performance tiers

Azure regions are geographic locations containing data centres. Choosing the right one affects latency, pricing, and compliance with data residency requirements.

Performance tiers are the decision that's hardest to walk back. Azure offers Standard and Premium tiers. Premium accounts are backed by SSDs and offer lower latency at a higher cost per gigabyte. Storage accounts can't be converted between Standard and Premium. Create a Standard account, later need Premium, and the answer is a new account and a data migration.

The four account kinds

The account kind is also fixed at creation. Like the performance tier, changing it means creating a new account and copying the data.

The three main services differ in namespace model, which is usually what decides between them for an analytics workload:

Routing preference

The routing preference setting controls how user traffic reaches the storage account — either across the Microsoft global network or over the public internet. To make inbound traffic enter Microsoft's network at the point of presence closest to the user, configure Microsoft network routing (also called the Microsoft edge network). Traffic then travels Microsoft's backbone to the storage account, which reduces latency. Internet routing is the alternative and is generally slower.

Capacity and limits

A storage account has a default maximum capacity of 5 PiB, and there's no limit on the number of containers, blobs, directories, file shares, tables, queues, entities, or messages inside it. A single container can grow to the account's full capacity.

What actually constrains a busy account is throughput rather than capacity, and those limits do vary by region:

All of these are defaults that can be raised on request. A subscription gets 250 storage accounts per region by default, or 500 with a quota increase.

Two smaller ceilings worth remembering because they come up in design questions:

• A container supports a maximum of 5 stored access policies.
• A container supports one time-based retention policy and one legal hold at a time — which is where the "maximum of 2 immutable policies per container" figure comes from. It isn't an arbitrary cap; it's one policy of each available type.

The account's redundancy setting is the other creation-time decision with long consequences, and it deserves its own treatment — I've covered the six options and what each survives separately, in the post on storage redundancy.

Sources

• Storage account overview — Azure Storage | Microsoft Learn
• Blob Storage scalability and performance targets — Azure Storage | Microsoft Learn
• Overview of immutable storage for blob data — Azure Storage | Microsoft Learn