Azure Storage Explained: Blobs, Files, Queues, and Tables

Every Azure application stores data somewhere, and Azure Storage is the service underneath most of it, from serving website images to queuing background work.

There are four storage types in a storage account, and knowing which to reach for is most of the skill. Think of the account as a warehouse: a vast file room for anything unstructured, a shared filing cabinet that behaves like a network drive, a ticket counter that hands work to whoever is free, and a very large spreadsheet for lookups. Most real applications use more than one.

The four types side by side

Prices differ between the four and change often enough that the useful thing to remember is the ordering rather than the numbers. Blob is the cheapest per gigabyte, Files costs more because you are paying for the file system semantics, and Tables and Queues bill largely on operations.

Blob storage

Blob stands for binary large object, and it holds anything unstructured: images, video, documents, database backups, logs, static site assets.

Reach for it when you are storing files that applications access over HTTP or process in bulk. It is the storage underneath media delivery, backup targets and machine learning pipelines.

There are three blob types. Block blobs are optimised for uploading large objects in parallel pieces and are what you want almost always. Append blobs only allow adding to the end, which suits logging. Page blobs support random reads and writes and are what VM disks are built on.

Create and manage a storage account is the place to start, because the account level settings you choose here constrain everything else.

Once the portal makes sense, do it again from the command line. Managing blob storage operations with the CLI is how you will actually work with storage day to day, and it makes scripting and automation obvious.

Azure Files

Azure Files gives you managed file shares reachable over SMB or NFS. If you have ever mapped a network drive, this behaves the same way, with the file server living in Azure.

Use it when an application expects a file system, or when you are moving existing file shares to the cloud. Shared configuration across several VMs, legacy applications that read from a disk path, and home directories all fit.

The question people ask is why not use Blob for everything. The difference is the access pattern. Blob is a REST API, so your code makes HTTP requests for objects. Files presents a file system, so your code uses ordinary open, read, write and close. If the application was written to read from a path, Files lets it keep working without being rewritten. That is the whole value, and it is a large one during a migration.

Azure File Sync extends this further by caching frequently used data on a Windows Server on premises, so local access stays fast while cold data tiers into Azure. It is a common way to move a file server gradually rather than in one weekend.

Queue storage

Queues decouple parts of an application. A producer puts a message on, a consumer takes it off and processes it, and if the consumer dies the message reappears after a timeout for someone else to handle.

Use it to separate a responsive front end from slow background work. A web app accepts an order and drops a message. A worker picks it up, takes the payment and sends the confirmation. The user gets an immediate response even though the work took a minute.

The comparison worth understanding is against Service Bus.

For straightforward work distribution, Queue Storage is enough and cheaper. Move to Service Bus when you need ordering guarantees, dead lettering, or transactional semantics. Choosing Service Bus first because it has more features is a common way to add operational complexity you do not need yet.

Introduction to Azure Storage Queues covers the produce and consume cycle including the visibility timeout, which is the part that surprises people.

Table storage

Table Storage is a NoSQL key value store that holds enormous numbers of rows cheaply. Each entity has a partition key, a row key and up to 252 other properties, and rows in the same table need not share a shape.

Use it for fast lookups over large datasets: telemetry, user profiles, session data. It is not a relational database substitute. There are no joins, no foreign keys and no complex queries. Within those constraints it is very hard to beat on price.

Cosmos DB offers a Table API that is wire compatible while adding global distribution, low latency guarantees and automatic indexing. Starting on Table Storage and moving later is possible with modest code change, so the decision is not permanent. For a new project likely to grow, starting on Cosmos DB is often worth the higher floor cost to avoid the migration.

Account types and replication

Two choices you make before storing anything.

General purpose v2 supports all four services and is the default for essentially everything. The specialised premium account types, BlockBlobStorage and FileStorage, exist for high transaction blob workloads and low latency file shares respectively. GPv1 is superseded and existing accounts should be upgraded.

Replication is the more consequential decision.

LRS is fine for development. ZRS is the sensible production default because it survives losing a datacentre. GRS and its variants exist for data that must outlive a regional failure. Each step up costs meaningfully more, and the durability figures are all high enough that the real question is not durability but availability during a failure.

Access tiers

Blob storage has four tiers, trading storage cost against retrieval cost and minimum retention.

The arithmetic is simple. If a file is read less than once a month, Cool is cheaper overall despite the higher read cost. Archive is dramatically cheaper to store and rehydrating a blob from it can take hours, which makes it correct for retention obligations and wrong for anything a user might request.

Minimum retention periods are the trap. Delete a blob from Cool after a week and you are still billed for the full thirty days.

Rather than moving data by hand, set a lifecycle policy: Cool after 30 days, Cold after 90, Archive after 180. For data that ages predictably this is the single largest storage saving available, and it requires no application change. Object replication and lifecycle management covers writing those rules.

Four mistakes worth avoiding

Leaving everything in Hot. Logs, backups and historical data usually sit untouched for months in the most expensive tier. Tiering them is free money and changes nothing about how the application works.

Using Blob where Files fits. If you find yourself rewriting an application to replace file reads with REST calls, stop and consider whether a file share would let it run unmodified.

Not enabling soft delete. It keeps deleted blobs recoverable for a retention window you choose. It costs very little and it is the difference between an incident and an inconvenience.

Leaving the account open to the internet. Storage accounts are publicly reachable by default. Firewall rules, service endpoints and private endpoints all exist to fix this, and private endpoints are the strongest option. Lock down storage and SQL with private endpoints covers the configuration and the DNS behaviour that comes with it.

For the exam

Storage is heavily represented on AZ-104. Replication options, access tiers, account types and storage security all appear regularly, and the questions tend to be scenario shaped: given these requirements, which replication option, which tier.

That style rewards understanding the trade offs rather than memorising the table, which is what building a few of these actually gives you.