Azure Storage

Azure Storage is Microsoft’s foundational cloud storage platform. Rather than a single service, it is a family of storage services grouped under a shared management boundary called a storage account. Each service targets a different data shape and access pattern.

The builder question is not “do I need storage?” but “which storage surface fits this workload?”

Storage Account

A storage account is the top-level management boundary for Azure Storage resources. It defines settings that apply across all services within it: redundancy, access control, encryption, networking rules, and billing.

General-purpose v2 (GPv2) is the default account type. It supports all storage services (Blob, Files, Queue, Table) and all access tiers. Unless you have a specific reason to use a specialized account type (BlockBlobStorage for premium blob performance, FileStorage for premium file shares), start with GPv2.

Key properties set at the account level:

• Performance tier: Standard (HDD-backed) or Premium (SSD-backed)
• Redundancy: how many copies and where (see below)
• Access tier default: Hot, Cool, or Cold for blobs
• Network rules: public access, firewall, private endpoints
• Encryption: always on, Microsoft-managed keys by default (customer-managed keys optional)

Blob Storage

Blob Storage holds unstructured data: documents, images, video, backups, exports, logs, data lake files. It is the most commonly used Azure Storage service.

Blobs live inside containers (flat namespaces within the account). There are three blob types:

• Block blobs: the default. Optimized for upload/download of large objects (up to 190.7 TiB).
• Append blobs: optimized for append operations (logs, audit trails).
• Page blobs: optimized for random read/write (backs Azure VM disks in classic deployments).

Access Tiers

Blob Storage offers tiered pricing that trades storage cost for access cost:

Tiers can be set per-blob or as a default on the account. Lifecycle management policies can automatically move blobs between tiers based on age or last access time.

Data Lake Storage Gen2

Data Lake Storage Gen2 is not a separate service. It is a capability built into Blob Storage, enabled by turning on hierarchical namespace on the storage account. This adds:

• True directory structure (not just virtual path prefixes)
• POSIX-like ACLs for fine-grained access control
• Optimized performance for analytics workloads (Spark, Synapse, Databricks)

If you are building a data lake on Azure, use Blob Storage with hierarchical namespace enabled.

Azure Files

Azure Files provides fully managed file shares accessible via SMB (Windows/Linux/macOS) and NFS (Linux) protocols.

Use Azure Files when:

• Workloads expect a mounted filesystem (legacy apps, batch tools, shared config)
• You need to replace or extend on-premises file servers
• Multiple VMs or containers need concurrent access to the same files
• Azure File Sync should tier on-premises files to the cloud

Azure Files supports snapshots, soft delete, and integration with Active Directory for identity-based access control over SMB.

Queue Storage

Queue Storage is a simple, durable message queue for asynchronous communication between application components. Each message can be up to 64 KB, and a queue can hold millions of messages.

It is the right choice when:

• You need basic producer/consumer decoupling
• Message volume is moderate
• You do not need advanced broker features
• Cost and simplicity matter more than delivery semantics

Queue Storage is not a replacement for Azure Service Bus. It lacks topics/subscriptions, sessions, message ordering guarantees, and rich dead-lettering. When delivery control and orchestration patterns matter, use Service Bus instead.

Table Storage

Table Storage is a key-value NoSQL store for structured data. Each entity (row) is identified by a PartitionKey and RowKey combination, and can hold up to 252 custom properties.

Good for:

• Simple lookup tables and configuration data
• Lightweight status tracking or checkpoint metadata
• Datasets where the access pattern is point reads and simple scans
• Workloads that do not justify Cosmos DB’s cost or complexity

Table Storage uses the same API surface as Azure Cosmos DB for Table, so you can migrate to Cosmos DB later if you need global distribution, richer querying, or guaranteed throughput.

Other Storage Services (Brief)

Azure offers additional storage services outside the GPv2 storage account:

• Managed Disks: block storage for Azure VMs. Handles replication and availability automatically. Available in Standard HDD, Standard SSD, Premium SSD, and Ultra Disk tiers.
• Azure Elastic SAN: centralized block storage that can serve multiple VMs or workloads, useful for consolidating SAN infrastructure in the cloud.
• Azure Container Storage: manages persistent volumes for Kubernetes (AKS) workloads, backed by Azure Disks, Ephemeral Disks, or Azure Elastic SAN.

Redundancy

Azure Storage replicates data automatically. The redundancy option you choose determines how many copies exist and where:

Choose based on durability requirements and whether you need read access during a regional outage. LRS is cheapest; RA-GZRS is most resilient.

Authorization

Azure Storage supports multiple authorization models:

• Entra ID (RBAC): recommended. Assign roles like Storage Blob Data Reader or Storage Blob Data Contributor. Works with managed identities for service-to-service access.
• Shared Key: account-level keys with full access. Simple but hard to rotate and overly broad. Avoid in production when possible.
• Shared Access Signatures (SAS): time-limited, scoped tokens for delegated access. Useful for granting external clients temporary access to specific resources.

All data is encrypted at rest automatically using 256-bit AES. Microsoft manages the keys by default; you can use customer-managed keys in Azure Key Vault for additional control.

When to Use Each Storage Type

Common Use Cases

• Application data: store uploads, generated reports, and processed outputs in Blob Storage.
• Data lake: enable hierarchical namespace for analytics with Spark, Synapse, or Databricks.
• Backup and archive: use Cool/Cold/Archive tiers with lifecycle policies for cost-effective retention.
• VM disks: Managed Disks provide the block storage layer for Azure Virtual Machines.
• File shares: replace or extend on-premises file servers with Azure Files.
• Static websites: serve HTML/CSS/JS directly from Blob Storage with a custom domain and CDN.

In Entra-Adjacent Systems

Azure Storage appears frequently alongside Entra-integrated architectures:

• Audit and export staging: Graph API bulk exports, sign-in logs, and provisioning reports often land in Blob Storage before downstream processing.
• Identity-based access: Entra ID RBAC on storage accounts lets managed identities access blobs, queues, and tables without shared keys.
• Diagnostic logs: Entra diagnostic settings can route sign-in and audit logs to a storage account for archival.
• Hybrid file shares: Azure Files joined to Active Directory provides identity-aware file access for hybrid environments.

Practical Guidance

Start with a GPv2 storage account, then pick the service that matches the data shape. Use Blob for objects, Files for filesystem contracts, Queue for simple buffering, Table for lightweight lookups. Set the right redundancy and access tier from the start, as changing them later can involve data movement or downtime. Use Entra ID authorization with managed identities over shared keys whenever possible.