Azure Storage Explained: Blob, Files, Queues, Tables and Redundancy

Last reviewed: September 2026

Azure Storage provides managed services for objects, files, messages and key-value data. A good design begins by choosing the correct service, account type, redundancy option, access controls and lifecycle policy for the workload.

Azure Storage services#

Storage account design#

General-purpose v2 accounts support the broadest set of modern storage capabilities. Separate accounts when workloads require different security boundaries, networking, ownership, performance, redundancy or lifecycle settings.

• Choose globally unique account names.
• Select the region and redundancy before deployment.
• Disable anonymous public access unless explicitly required.
• Prefer secure transfer and modern TLS settings.
• Use private endpoints or restricted public networks for sensitive workloads.
• Design naming, tags, diagnostics and cost ownership consistently.

Blob Storage#

Blob Storage stores unstructured objects in containers. Block blobs are common for files and streaming data, append blobs suit append-oriented logging, and page blobs support random-access patterns such as virtual hard disks.

• Use containers to organize access and lifecycle rules.
• Set appropriate content types and metadata.
• Choose access tiers based on access frequency and recovery requirements.
• Use versioning, soft delete or immutability when the protection requirement calls for them.
• Avoid exposing storage account keys to applications.

Azure Files#

Azure Files provides managed file shares accessible through supported SMB or NFS configurations. It can replace or extend traditional file servers, but protocol, identity, networking, performance tier and client compatibility must be evaluated.

Queue Storage#

Queue Storage supports asynchronous communication between components. Messages should be small, idempotent where possible and designed for retries, visibility timeouts and poison-message handling.

Table Storage#

Table Storage is a schemaless key-value service organized by partition and row keys. Partition-key design affects scalability and query efficiency, so choose keys from real access patterns rather than visual grouping.

Redundancy options#

Geo-replication is asynchronous, so the recovery-point objective is not zero. Verify current regional support, service compatibility, access-tier limitations and failover behavior before selecting a redundancy option.

Blob access tiers#

• Hot: optimized for data accessed frequently.
• Cool: lower storage cost with higher access and minimum-retention considerations.
• Cold: optimized for data accessed infrequently with longer minimum-retention considerations.
• Archive: offline tier with rehydration delay and specific redundancy support limitations.

Lifecycle management rules can move blobs between supported tiers or delete versions and snapshots after defined periods. Test rules carefully and exclude data that must remain immediately available.

Authentication and authorization#

• Use Microsoft Entra ID and Azure role-based access control where supported.
• Use managed identities for Azure-hosted applications.
• Use user-delegation SAS for bounded delegated access when appropriate.
• Protect account keys, rotate them and avoid distributing them to applications.
• Scope roles and SAS permissions, resources, protocols and expiry as narrowly as possible.

Network security#

• Disable unrestricted public network access for sensitive accounts.
• Use private endpoints when private network access is required.
• Configure storage firewalls and selected networks deliberately.
• Secure DNS resolution for private endpoints.
• Understand trusted-service exceptions before enabling them.
• Test application access from every intended network path.

Data protection#

• Enable soft delete for relevant blob, container and file-share scenarios.
• Use blob versioning where previous object states must be recoverable.
• Use immutable storage for regulated write-once retention requirements.
• Replicate or back up data according to the recovery objective.
• Test restore and account-failover procedures instead of assuming replication is a backup.

Monitoring and cost control#

• Enable diagnostic settings for required logs and metrics.
• Alert on availability, latency, capacity, authorization failures and unusual traffic.
• Track transaction, retrieval, replication and data-transfer charges.
• Review old versions, snapshots and uncommitted blocks.
• Apply lifecycle policies and retention rules with cost estimates.
• Use inventory and cost tags to identify owners and environments.

Common mistakes#

• Choosing redundancy without validating workload recovery requirements.
• Treating geo-replication as a complete backup strategy.
• Embedding account keys in source code or configuration.
• Making containers public unintentionally.
• Using undersized partitions or poor keys in Table Storage.
• Applying lifecycle deletion rules without recovery testing.
• Ignoring private-endpoint DNS and network dependencies.

Official references#

Introduction to Azure Storage

Azure Storage redundancy

Blob access tiers