Azure Blob Storage: blob types, access, tiers, and costs

With Azure Blob Storage, an application can keep its documents, media, and backups as individually named objects in Microsoft's cloud. The service handles unstructured data. If you maintain an application or manage its data, the important decisions are how objects are written, who can retrieve them, and how quickly they must be available. This guide explains blob types, access controls, storage tiers, pricing, and the checks to make before a migration.

What happened to Windows Azure Blob Storage?

“Windows Azure Blob Storage” is an older search term for the same service family. Microsoft renamed Windows Azure to Microsoft Azure in 2014. Current documentation uses Azure Blob Storage.

Unstructured data and other Azure storage services

Azure Blob Storage holds text data and binary data as objects, rather than supplying a traditional database or shared file system. Think of the distinction through an application: audio files or original images can live in object storage, while a database holds the searchable records describing them. Choose the storage service around the operations the application needs.

How Azure Blob Storage organizes data

Three resources define the basic structure: a storage account provides the service boundary, a container groups blobs, and each blob holds an object. The Blob Storage introduction describes this model and the supported interfaces. A useful planning example is one container for customer uploads and another for generated reports, with permissions reviewed separately.

Object names and directories

In a flat namespace, a name such as reports/2026/october.csv uses slashes to represent a path. Enabling the hierarchical namespace for Azure Data Lake Storage adds directory-oriented capabilities. That choice affects feature compatibility, so make it before deciding how recovery and access will work.

Do not assume a file-based application can use object storage unchanged. Check its expectations for renaming, locking, and updating files. Our guide to file systems in cloud computing explains the wider design choices. For a new application, give objects stable names and decide whether replacement or a new version represents an update.

Choose the account for the workload

A standard general-purpose v2 account is a common starting point. Premium block blob accounts target workloads with different performance needs and do not offer the same tiering options. Compare the supported account types before provisioning. “Premium” is a reason to test a specific requirement, not a substitute for measuring it.

Write down the intended region, expected growth, network path, and required recovery features. Also identify the person who owns the account settings. A technically valid configuration can still be difficult to operate if nobody is responsible for its permissions, spending, or restore procedure.

Block blobs, append blobs, and page blobs

Choose the blob type according to the application's write pattern. Microsoft's blob type reference distinguishes three models:

Type	Write behavior	Typical fit
Block blob	Upload blocks and commit the resulting object	Documents, media, backups, and datasets
Append blob	Add blocks to the end	Append-oriented logging
Page blob	Update aligned ranges within an object	Workloads needing random reads and writes

For a document upload service, block blobs are the natural first candidate. Append blobs warrant a closer look when the application continually adds records without revising earlier ones. Page blobs require an application designed for their operations; they are not a general upgrade for ordinary file uploads.

Check limits against the API version

Capacity is not unlimited. With service version 2019-12-12 or later, the documented maximum block blob is approximately 190.7 TiB; page blobs have an 8 TiB maximum. Older service versions have lower block blob limits. Use Microsoft's current scalability targets for the client and account you intend to use.

A maximum object size says little about how long a transfer will take. Test both the largest expected object and a representative collection of small objects. Those tests answer different questions: one exposes sustained transfer behavior, while the other helps reveal the cost of processing many separate requests.

Control who can read and write blob data

Prefer identity-based access

Microsoft recommends Microsoft Entra ID authorization, formerly Azure Active Directory, where supported. Use role-based access control (RBAC) and consider managed identities for applications running in Azure. Permission to manage the storage account is distinct from permission to read its contents. Account keys grant broad access and should not be embedded in application source code.

Define access around a task. A reporting service may need to read a dataset, while an ingestion service needs to write new objects. Review each identity separately instead of giving every service the same broad permissions. Test denied operations as well as successful ones, including an attempted write by a read-only identity.

Use shared access signatures for bounded delegation

A shared access signature (SAS) delegates access with specified permissions and an expiry. Microsoft recommends a user delegation SAS when possible for Blob Storage. Treat a SAS URL as a credential: anyone possessing it may exercise the permissions it grants while it remains valid.

For a temporary upload, document which destination is allowed, whether existing objects can be overwritten, and how long access should last. Keep signed URLs out of analytics events, support screenshots, and ordinary application logs. The convenience of a link does not make its contents safe to circulate.

Private endpoints do not disable public access by themselves

An Azure private endpoint supplies a private network path. Creating it does not automatically block the storage account's public endpoint. Configure public network access and firewall rules separately, and verify DNS resolution from the intended clients. Network reachability and authorization remain separate checks.

Also verify transport and encryption settings. Azure Storage encrypts data at rest through Storage Service Encryption. For REST access, the secure transfer requirement rejects HTTP requests when enabled. Neither setting corrects excessive permissions. Our cloud security guide places these controls in a broader operational plan.

Choose Azure Blob Storage tiers around retrieval needs

For eligible standard block blobs, the principal access tiers are:

Tier	Access	Minimum billable duration in general-purpose v2
Hot	Online, for frequent use	None
Cool	Online, for less frequent use	30 days
Cold	Online, for infrequent use	90 days
Archive	Offline; rehydration required	180 days

Minimum billable durations are not retention locks. Deleting, overwriting, or moving data early can incur charges. Lower capacity prices also come with different access costs. These tiers do not apply to append and page blobs.

Keep urgent recovery data out of an untested archive plan

Archive rehydration is an asynchronous operation whose duration depends on factors including priority and demand. It can take hours. A higher-priority request does not justify promising a fixed recovery time for every workload.

Separate records kept for occasional investigation from the backup needed to restart tomorrow's operations. If a service must be restored within an hour, test the entire restore against that requirement before assigning its only usable copy to Archive. Include the time to find objects, obtain access, transfer data, and restart the application.

Consider Smart tier where it fits

Smart tier automatically moves eligible block blobs among Hot, Cool, and Cold based on use. It does not use Archive and has account, redundancy, and regional requirements, with monitoring charges to consider. Compare those conditions with the actual dataset rather than assuming automation always lowers the bill.

Estimate Azure Blob Storage pricing from activity

The Azure Blob Storage pricing page separates capacity, operations, retrieval, and other applicable charges. Region, redundancy, and tier affect the estimate. Data transfer and additional features may add costs. A per-GB storage rate alone is not a monthly budget.

Build a worksheet around a normal month and a recovery month. Record average stored volume, object counts, read and write requests, data retrieved, and data leaving the region. Add retained versions and copies to the capacity estimate. Then model a large restore or an export to another provider.

For example, an infrequently accessed dataset may look inexpensive in a cooler tier until a monthly processing job rereads all of it. Another dataset may remain untouched for years but need an urgent restore. Their average storage volumes could be identical, yet they need different cost and recovery assumptions. Use your own measured activity before choosing between them.

Use lifecycle management carefully

Lifecycle policies can move eligible data to cooler tiers or delete it when conditions are met. Rules can target prefixes or blob index tags. Execution is asynchronous, and lifecycle management does not rehydrate archived blobs. Policy changes can take up to 24 hours to begin taking effect.

Start with a narrow, noncritical dataset and a documented rule. For example, consider whether completed exports become eligible for a cooler tier after a chosen period, while active uploads stay outside that rule. Review deletion separately with the data owner. A cost-saving policy should not silently become the organization's retention policy.

Configure Blob Storage for disaster recovery

The Blob Storage data protection guide distinguishes controls for different failures. Container soft delete, blob soft delete, and blob versioning protect different resources or changes. An account resource lock addresses account deletion, not every blob operation. Feature support also depends on account configuration; blob versioning is not supported with a hierarchical namespace.

Redundancy needs a separate decision. Azure replication options span local, zonal, and geographic arrangements, with asynchronous replication between regions. Replication alone does not prove that you can recover a useful version after an application mistake. Choose the location policy deliberately; our explanation of where cloud data is stored provides context for that discussion.

Run a small recoverability test that includes an overwritten object, a deleted container, and an unavailable primary operator. Record what was recoverable, who performed the restore, and how long it took. Repeat when account features or application behavior change.

Upload, migrate, and verify your data

Start with a small Azure Storage Explorer upload

For a first trial, create an Azure storage account through the Azure portal, Azure CLI, or Azure PowerShell. In Azure Storage Explorer, sign in, choose the correct subscription, and expand the account. Under Blob Containers, create a container, then use Upload to select a file and its blob type. Inspect the transfer result and download the object to verify it.

Use a non-sensitive sample and confirm the storage account name before uploading. This is particularly useful when several storage accounts look similar. Keep the container private for the trial and check access with the identity the application will actually use. An administrator's successful upload does not establish that a production service has the right permissions.

Follow the rules for naming containers: 3–63 characters, lowercase letters, numbers, and permitted hyphens. Blob names are case-sensitive. Establish one naming convention before moving existing data so imports do not create unexpected duplicates or unreadable references.

Choose a transfer tool and a controlled starting point

AzCopy is Microsoft's command-line transfer utility and supports authorization through Entra ID or a SAS token. Azure Storage Explorer provides a graphical interface; application integrations can use the REST API or supported client libraries. Microsoft cautions that AzCopy does not support transfers where the source or destination is actively changing.

Plan an application-consistent handover, with a defined point after which the source stops changing. Avoid treating a successful copy command as proof that the application is ready. A migration can transfer every byte and still omit permissions, naming assumptions, or metadata the application expects.

For code integration, the Azure Storage client library quickstart for Python demonstrates creating, listing, uploading, and downloading blobs with identity-based authorization. Keep credentials out of source code, including connection strings containing account keys. Choose an Azure SDK version deliberately and test its behavior against the blob types and access tiers you use.

A migration acceptance checklist

1. Inventory the source. Count objects and bytes, identify large objects, and record required metadata and retention rules.
2. Prepare the destination. Confirm the account, namespace, region, blob type, tier, and permitted identities.
3. Copy a representative sample. Include small files, large files, unusual names, and realistic directory depth.
4. Validate the result. Compare counts and sizes, verify content integrity with suitable checksums, and test metadata and application reads.
5. Test failure and recovery. Check interrupted transfers, expired access, denied writes, and the restore procedure.
6. Approve the cutover. Reconcile the final changes and document rollback conditions before removing the source copy.

Measure from the application's normal location using its real request pattern. Record throughput, latency, failures, and cost together. A benchmark against large sequential objects does not establish performance for thousands of tiny interactive reads. Keep the test dataset and method so results can be compared later.

Monitor Azure Blob Storage after the migration

Azure Monitor provides metrics and logging for Blob Storage. Resource logs require diagnostic settings to route them to a destination; do not assume a historical request log is available just because metrics appear in the portal. Configure useful alerts and decide who responds to them.

Review failed data access, request volume, latency, and growth alongside spending. A sudden rise in downloads might be legitimate data analysis, an application retry loop, or an access problem. Investigate with application context rather than interpreting a chart alone. Also monitor the transfer jobs that populate your containers: healthy storage does not prove that last night's files arrived.

Keep an operating record for each production workload: its owner, authorized identities, storage accounts, lifecycle rules, recovery target, and last successful restore. Review it after application changes. The work of storing data continues after the initial upload, especially when several teams share the account.

Two decisions to make before production

Is static website hosting appropriate?

Blob Storage's static website feature serves files from the $web container through a dedicated endpoint. It uses anonymous read access, and changing the container's anonymous access level does not secure that website endpoint. Network rules can restrict reachability, but the feature does not provide user authentication. Use a suitable authenticated application service for private user-specific pages.

Do you need Azure-specific integration or an S3-compatible service?

If the application depends on Azure identities, APIs, or data services, assess those dependencies before comparing providers. Object Storage with Hivenet is an S3-compatible option to evaluate for compatible workloads. An Azure Blob API integration still needs a compatibility and migration review; changing an endpoint alone is not a migration plan.

Choose after testing the operations you use and estimating the full cost of keeping, retrieving, and moving the data. The result should be a configuration your team can explain, operate, and restore when something goes wrong.