Learn

Azure Storage Basics

Use a GPv2 storage account as the baseline mental model for Azure Storage in this topic. It is the general-purpose account type builders usually start with when an Entra-adjacent system needs durable files, export payloads, simple queues, or lightweight structured records.

Azure Storage is not one thing. It is a family of storage services with different roles. The main builder question is not “do I need storage?” but “which storage surface matches the artifact or handoff I need to keep?”

Blob Storage

Blob storage is the default place for large objects and file-like payloads that do not need a mounted filesystem.

In Entra-adjacent systems, that often means:

  • exported reports,
  • staged payloads from Graph or downstream systems,
  • raw event captures,
  • audit snapshots,
  • large reconciliation artifacts,
  • temporary files that later processors consume.

Blob storage is a strong fit when objects are written once, read many times, or moved through processing stages. It is a weaker fit when the workload actually needs message semantics or low-latency transactional state.

Azure Files

Azure Files gives you SMB or NFS-style file shares when a workload needs a conventional filesystem boundary.

That matters less for cloud-native serverless handlers and more for:

  • legacy tools that expect a mounted share,
  • batch processes that write named files into a shared location,
  • VM-hosted or hybrid components that integrate through files rather than APIs.

Use it when the file-share contract is part of the system boundary. Do not add it just because the data happens to be file-shaped.

Queue Storage

Azure Queue Storage is the simplest message queue in the storage family. It can work for lightweight asynchronous handoff where you mainly need buffering between producers and consumers.

It is useful when:

  • the message rate is modest,
  • the workflow is simple,
  • advanced broker features are unnecessary,
  • cost and simplicity matter more than rich delivery control.

It is not interchangeable with Service Bus. Queue Storage does not give you the same workflow-oriented semantics such as topics and subscriptions, sessions for ordered coordination, or more advanced dead-lettering patterns. When delivery guarantees and orchestration behavior matter, use Service Bus for Workflows instead.

Table Storage

Table storage is a simple key-based NoSQL surface for structured records. In this topic, it is mostly relevant for small durable datasets where the access pattern is straightforward and the workload does not justify Cosmos DB.

Possible uses include:

  • small lookup tables,
  • simple status rows,
  • coarse checkpoint metadata,
  • lightweight integration configuration.

Once the system needs richer querying, stricter throughput planning, multi-region behavior, or more serious coordination patterns, Cosmos DB is usually the better fit.

Where Azure Storage Fits Around Entra

Azure Storage usually sits beside the main control-plane and workflow services rather than replacing them:

  • Graph provides identity state and administrative actions.
  • Functions or workers process the logic.
  • Storage holds large artifacts, raw payloads, and simple durable handoff data.
  • Cosmos DB keeps richer workflow state.
  • Service Bus handles durable workflow messaging.

That separation prevents an architecture from forcing every problem into a storage account because it is already present.

Practical Guidance

Start with GPv2, then pick the storage surface that matches the artifact:

  • Blob for large objects and exports.
  • Files for shared filesystem contracts.
  • Queue for simple buffering.
  • Table for lightweight structured records.

If the design starts asking for retries, ordered coordination, or subscriber fan-out, move from storage queues to Service Bus instead of stretching the simpler storage primitive past its role.