Academmia

Azure Storage accounts: account types and storage services (Blob, Files, Queue, Table)

az-900•mixed•

Azure architecture and services

Azure Storage accounts: account types and storage services (Blob, Files, Queue, Table)

Short Summary

In this lesson, I explain what an Azure storage account is and why it’s the starting point for many Azure Storage services. I then map common needs (objects, file shares, messages, simple Not Only SQL (NoSQL) records) to the right storage service. Finally, I separate “which service do I need?” from “how do I configure the account?” so I don’t paint myself into a corner later.

Learning Objectives

By the end of this lesson, you will be able to:

  • Describe what an Azure storage account provides (namespace, endpoints, management boundary).
  • Explain why Standard General-purpose v2 (GPv2) is the default choice for many storage scenarios.
  • Match Azure Blob Storage, Azure Files, Azure Queue Storage, and Azure Table Storage to typical use cases.
  • Differentiate service decisions (what I store and how I access it) from account decisions (redundancy, performance options, networking).
  • Plan for changes by recognizing which decisions are easy to adjust later and which usually require migration.

Core Concepts

What an Azure storage account is

An Azure storage account is the top-level container for Azure Storage data objects: blobs, files, queues, and tables. It also provides a unique namespace and service endpoints (URLs) that my apps use to access data over Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS).

A storage account is also a practical management and billing boundary: settings like redundancy are chosen at the account level, and usage is billed under that account.

Storage services inside a storage account

Inside a storage account, I choose a storage service based on the data shape and access style:

  • Azure Blob Storage: object storage for unstructured data (images, documents, video, backups). I access it over HTTP/HTTPS and think in terms of containers + blobs.
  • Azure Files: managed file shares. I choose this when I need a share that clients can mount using Server Message Block (SMB) or Network File System (NFS) (plus a REST API option).
  • Azure Queue Storage: a simple message queue for passing work items between components so I can process them asynchronously.
  • Azure Table Storage: a schemaless key/attribute store for simple structured data (Not Only SQL (NoSQL) style). I use it when I want something lightweight, not when I need relational joins.

Storage account types (what “type” really means)

The storage account type matters because it affects features, performance, and which services are available.

For many AZ-900 scenarios, the default mental model is:

  • Standard General-purpose v2 (GPv2): the general “do most things” account type for blobs, file shares, queues, and tables. It’s usually where I start unless I have a specific performance or protocol requirement.

There are also specialized account types (often premium-focused) for specific workloads (for example, high-performance block blobs or premium file shares). For AZ-900, I just need to recognize that “type” can limit or enable features, so I don’t assume every account can do everything.

“Service choice” vs. “account configuration” choice

A clean two-bucket decision helps me avoid confusion:

  • Service choice = what I store and how I access it (Blob vs Files vs Queue vs Table)
  • Account configuration = how the account behaves (redundancy, performance options, networking, security)

Example: I decide “Blob Storage” because I need object access over HTTPS. Then I decide redundancy (LRS/ZRS/GRS/etc.) because I’m choosing how resilient I want the account to be.

Changing decisions later: what to expect

Some changes are easy (tuning settings that are designed to be updated). Some are not.

One important nuance: Microsoft supports certain upgrades for account types (for example, upgrading older account kinds to GPv2), but not every “type change” is a simple switch, and downgrades are typically not supported. When a change isn’t supported in-place, the usual path is: create a new account, copy/migrate data, then cut over.

Practical Understanding

Practical Situation 1: “I need one place for blobs, file shares, queues, and tables”

I’m designing a simple app and I want one storage account that can store user uploads, provide a file share for a legacy tool, queue background work, and store a small set of NoSQL records.

How to think about it: This is a “use multiple Azure Storage services” scenario. I start with Standard GPv2 because it’s the common default that supports the usual set.

Common misunderstanding: “I should create a Blob-only account because I mostly store files.” If I also need queues, tables, or file shares, that choice can block me later.

Practical Situation 2: “Images, videos, and backups for my app”

I need to store lots of pictures and videos, plus periodic backups. The app accesses them over HTTPS, not as a mounted drive.

How to think about it: That’s a strong match for Azure Blob Storage. I think “objects over HTTP/HTTPS,” not “network drive.”

Common misunderstanding: “Files are files, so I should use Azure Files.” Azure Files is for mountable file shares; Blob Storage is usually the right match for object access.

Practical Situation 3: “A shared drive that users can mount”

A team wants a shared folder that feels like a normal network drive and can be mounted by clients that speak SMB or NFS.

How to think about it: That’s Azure Files. “Mount a share” is the clue.

Common misunderstanding: “Blob Storage is cheaper, so it’s the same thing.” Blob Storage is object storage; it’s not a drop-in replacement for a mounted SMB/NFS share.

Practical Situation 4: “Decouple the web app from background processing”

My frontend needs to hand off work (like image resizing) to a backend worker and I don’t want the frontend to wait.

How to think about it: This is a messaging pattern. Azure Queue Storage fits “send work items now, process later.”

Common misunderstanding: “Let’s store work items in Table Storage.” Tables store records; queues represent a backlog of messages to process.

Common Pitfalls

  • Mistake: Treating a storage account as “Blob Storage only.” Correction: A storage account can contain blobs, files, queues, and tables (depending on account type and features).

  • Mistake: Assuming every account type supports every feature. Correction: Account type matters; GPv2 is the common default, and specialized account types exist for specific workloads.

  • Mistake: Mixing up storage services with account configuration. Correction: First choose the service (Blob/Files/Queue/Table), then choose account-level settings (redundancy, performance, networking).

  • Mistake: Choosing based only on storage price per GB. Correction: Protocol and access style (HTTPS object access vs SMB/NFS file share vs messaging) usually decide the service first.

  • Mistake: Assuming I can freely “switch account type” later with no work. Correction: Some upgrades are supported, but many changes require creating a new account and migrating data, so I plan early.

Check Your Understanding

  1. In one sentence, explain what a storage account provides beyond “a place to store data.”
  2. Pick a real example (photos, shared documents, tasks to process, simple profiles). Which storage service matches it, and why?
  3. Write a two-step decision rule: (1) choose the storage service, (2) choose account options. What questions do I ask at each step?
  4. Describe the difference between “access over HTTPS” and “mount as a drive,” and which services each idea points to.
  5. If I chose the wrong account type and now need features it doesn’t support, what kind of operational work might that force (at a high level)?

Further Reading