Azure Blob Storage

About Azure Blob Storage

Azure Blob Storage is Microsoft Azure's object storage service for large volumes of unstructured data such as files, images, video, backups, archives, logs, analytics data and application assets. It scales independently from compute and can be accessed through Azure APIs, SDKs, command-line tools and the Azure portal. Buyers should evaluate access frequency, redundancy, retrieval latency, transaction volume, data transfer, security requirements and retention because Blob Storage cost and behavior depend heavily on those choices.

What is Azure Blob Storage used for?

Azure Blob Storage is used when an application or organization needs durable object storage rather than a traditional file system or block device. Microsoft positions Blob Storage for cloud-native application data, media, documents, backup and archival content, analytics datasets, data lakes, high-performance computing and machine learning scenarios. Block blobs are the most common object type for text and binary content such as files, images and video.

A key design point is that Blob Storage is independent from a specific virtual machine or application host. An application on Azure App Service, Azure Functions, AKS, Virtual Machines or another platform can store and retrieve objects from the same storage account. This separation can improve scalability and durability, but teams still need to design authentication, network access, naming, lifecycle rules and data ownership deliberately.

How do Hot, Cool, Cold and Archive tiers differ?

Microsoft currently documents Hot, Cool, Cold and Archive access tiers for block blob data. Hot is designed for frequently accessed or modified data. Cool is intended for infrequently accessed data and has a recommended minimum retention period of 30 days. Cold is for rarely accessed data that still needs online retrieval and has a recommended minimum of 90 days. Archive is an offline tier for rarely accessed data with retrieval latency measured in hours and a minimum retention period of 180 days.

Early deletion charges can apply when data is deleted, overwritten or moved before a tier's minimum period is met. Archive data must be rehydrated before normal online use, and Microsoft states rehydration can take up to 15 hours. Archive is also restricted to LRS, GRS and RA-GRS storage accounts rather than ZRS, GZRS or RA-GZRS. Buyers should therefore choose a tier using measured access patterns, retrieval requirements and redundancy needs instead of selecting the lowest capacity price alone.

What is Azure Blob Storage Smart Tier?

Microsoft's Smart Tier automatically manages eligible block blobs across the Hot, Cool and Cold capacity tiers according to access behavior. Objects enter the Hot capacity tier first. Eligible objects that remain inactive can move to Cool after 30 days, then to Cold after a further period of inactivity, while subsequent access can move them back to Hot automatically.

Smart Tier is generally available in supported public-cloud regions for Standard general-purpose v2 accounts using ZRS, GZRS or RA-GZRS redundancy. It does not support legacy GPv1 accounts, premium storage accounts, page blobs, append blobs or Archive. Objects smaller than 128 KiB stay in Hot for efficiency. Microsoft also charges a monthly monitoring operation for eligible managed objects, so buyers should compare that monitoring cost with the savings from automatic tier movement.

What scale limits should teams plan around?

Microsoft's current Blob Storage scalability targets list up to 50,000 blocks in a block blob, a maximum block size of 4,000 MiB for service version 2019-12-12 and later, and an approximate maximum block blob size of 190.7 TiB. A single Put Blob operation can write up to 5,000 MiB with those current service versions.

For request planning, Microsoft lists a target of up to 3,000 requests per second for a single block blob. Actual throughput still depends on concurrency, request size, storage tier, source and destination performance, and the storage account's ingress or egress limits. Microsoft recommends exponential backoff when applications receive 503 Server Busy or 500 Operation Timeout responses. These are service targets rather than a guarantee that every workload will sustain the headline numbers.

How does Blob Storage pricing work?

Azure Blob Storage does not have one fixed monthly price. Microsoft's pricing page, checked September 4, 2026, states that total cost depends on stored data volume, operations, data transfer and the redundancy option selected. Standard general-purpose v2 storage is Microsoft's recommended pricing model for block blobs and append blobs that need current Azure Storage features, while Premium block blob storage is positioned for high transaction rates and low, consistent latency.

Cost optimization depends on the full access pattern. Cooler tiers reduce capacity cost but increase read, transaction or retrieval charges. Frequent movement between tiers can create additional operations and, in some cases, early deletion fees. Geo-redundant configurations also add replication-related transfer charges. Smart Tier adds a monitoring charge for managed objects while billing those objects against the underlying Hot, Cool or Cold capacity tier. Teams should estimate capacity growth, read and write frequency, object count, redundancy, egress and retention together.

What changed for Blob Storage TLS in 2026?

Microsoft stopped supporting TLS 1.0 and TLS 1.1 for Azure Blob Storage on February 3, 2026. TLS 1.2 is now the minimum supported Transport Layer Security version for Blob Storage connections. Applications, libraries, appliances or integration tools that still depend on TLS 1.0 or 1.1 can fail to connect until they are upgraded.

The minimum TLS version is enforced at the storage account level. If the same storage account also hosts Azure Files, Queue Storage or Table Storage, those services are subject to the same storage-account TLS requirement. Buyers migrating older applications should test client libraries, operating systems, proxy devices and integration runtimes before cutover rather than treating the change as a Blob Storage setting only.

What redundancy options should organizations evaluate?

Azure Storage supports several redundancy models for Blob Storage. Locally redundant storage keeps copies within one primary-region datacenter. Zone-redundant storage synchronously replicates data across multiple availability zones in the primary region. Geo-redundant and geo-zone-redundant options also replicate data to a secondary region, while read-access variants can expose the secondary copy for reads.

The right choice depends on availability, disaster recovery, data residency and cost. Redundancy protects against infrastructure failure but not against every accidental delete or overwrite because data-modifying operations are replicated across copies. Microsoft recommends combining the right redundancy model with recovery controls such as soft delete or versioning where appropriate. Archive also narrows redundancy choices, while Smart Tier requires zone-redundant configurations.

How can teams manage retention and lifecycle automatically?

Blob lifecycle management lets organizations define rule-based policies that move eligible data to cooler access tiers or delete it when conditions are met. Rules can apply to whole accounts, selected containers or subsets of blobs using prefixes and blob index tags. This suits logs, backup data, media archives and datasets whose access frequency changes over time.

Lifecycle management and Smart Tier solve related but different problems. Lifecycle policies apply explicit rules that an administrator defines. Smart Tier changes eligible objects between Hot, Cool and Cold automatically from observed access behavior. Lifecycle policies cannot rehydrate archived blobs back to an online tier, and Premium block blob accounts do not support the standard Hot, Cool, Cold or Archive tiering model through Set Blob Tier or lifecycle management. Teams should choose the mechanism that matches their governance requirements rather than enabling both without understanding how objects will move.

What security and recovery controls matter?

Organizations should treat Blob Storage as an application data service, not just a capacity bucket. Access should be controlled with Microsoft Entra identities, role-based access, managed identities or other supported authorization methods rather than broadly exposing storage keys. Network controls, encryption, private access and logging should be chosen according to workload sensitivity and architecture.

Microsoft also documents blob soft delete and versioning for recovery scenarios. Soft delete can retain deleted data for a configured period, while versioning can preserve previous object states in supported account configurations. These features can increase storage consumption, so teams should set retention deliberately and monitor the resulting storage cost.

Who should choose something else?

Blob Storage is not the right choice when an application needs a shared file system with file-share semantics, a relational database, low-level block storage for a virtual machine, or a database query engine. Azure Files may fit workloads that need managed file shares, Azure Managed Disks are designed for VM block storage, and Azure SQL or Cosmos DB are more appropriate when applications need database semantics rather than object storage.

Azure Blob Storage is strongest when the requirement is durable, scalable object storage for unstructured data and the application can work with object APIs. Buyers should choose it when storage scale, tiering, cloud-native access and integration with Azure services matter more than POSIX-style file operations or relational querying.