Azure Storage explained: services, accounts, and costs

Azure Storage is Microsoft's family of cloud storage services for objects, shared files, messages, and structured nonrelational data. Azure also provides managed disk storage for virtual machines. The right choice depends on how an application reads and writes data, not just how much space it needs.

If you searched for Windows Azure Storage, you are using an older name. Microsoft renamed Windows Azure to Microsoft Azure in April 2014. The services work with Linux and other platforms as well as Windows.

This guide is for developers and IT teams choosing a storage service or reviewing an existing setup. Start with the access model, then assess location, resilience, permissions, performance, and the cost of getting data back out.

Which Azure storage service do you need?

A file share, an object container, and a virtual disk solve different problems. Moving the same bytes between them can require application changes. Use this table to narrow the choice before comparing configurations.

Service	Data model	Typical starting point
Azure Blob Storage	Objects in containers	Images, exports, media, and application files
Azure Files	Shared file system	Applications that need SMB or NFS access
Azure managed disks	Block storage for Azure virtual machines	Operating systems and VM data volumes
Azure Data Lake Storage	Analytics capabilities built on Blob Storage	Data pipelines using a hierarchical namespace
Azure Queue Storage	Messages	Work waiting for an application component
Azure Table Storage	Nonrelational entities	Structured records retrieved by key

Azure Blob Storage for unstructured data

Azure Blob Storage stores text and binary objects. A storage account contains containers, which contain blobs. Applications commonly access these through APIs or SDKs, with client libraries for languages including .NET, Java, Python, and JavaScript. Check your application's expected interface before assuming that an object container can replace a mounted folder.

Azure Files for shared folders

Azure Files provides managed shares over Server Message Block (SMB) or Network File System (NFS). Shares preserve a folder hierarchy. Confirm the protocol, client support, identity requirements, and SMB features or NFS behavior your application needs. Our guide to cloud file systems explains the wider choice between file, block, and object access.

Azure disk storage for virtual machines

Managed disks provide persistent block storage for Azure VMs. Options include Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, and Standard HDD. Select a type and size against the workload and VM limits. A VM's temporary disk has different persistence behavior; do not treat it as a safe place for the only copy of important files.

Azure Data Lake Storage for analytics

Azure Data Lake Storage Gen2 adds analytics capabilities to Blob Storage, including a hierarchical namespace for directories and files. It is not a separate general-purpose storage account type. Check feature compatibility before enabling the namespace for a data analysis or big data analytics pipeline.

Azure queues and tables for application data

Queue Storage supports asynchronous messaging between application components. It is separate from Service Bus queues, which offer different messaging features. Compare the two queue services when ordering or duplicate detection matters.

Table Storage stores entities with flexible properties, organized through partition and row keys. It can store flexible datasets, but design those keys around the queries you need. It is not a relational database with SQL joins. Azure Cosmos DB for Table is a distinct offering, so verify which service a tutorial or connection setting refers to.

A Storage Queue message has a maximum size of 64 KiB. A queue can hold millions of messages within account capacity limits. For larger payloads, design the message around a reference to separately stored data rather than putting the entire file in the queue.

Understand storage accounts before creating resources

A general-purpose v2 storage account supports Blob, Queue, Table, and classic Azure Files resources. Premium account types serve specific workloads rather than upgrading every service at once. Managed disks are separate resources. Account names use 3–24 lowercase letters and numbers and must be unique across Azure.

Azure Files also has a newer management model. The Microsoft.FileShares resource can create shares without a storage account. At the time of checking, this path supports NFS shares on SSD provisioned v2 storage. SMB and other configurations still require the appropriate supported model.

Write down the required interface before following a setup tutorial. A team building a website image library, for example, should test object upload and retrieval. A team moving a shared application folder should test permissions, locking, and client access. An account that is easy to create can still be the wrong foundation for the application.

Choose location and redundancy together

Region selection affects where a service runs and how it connects to users and other resources. Start with the application's location and any documented residency requirement. Our explanation of where cloud data is stored provides context for that discussion.

Azure Storage can replicate data using several redundancy configurations. Support varies by service, region, and account features.

Option	Copy placement
LRS	Within one physical data center in the primary region
ZRS	Across three or more availability zones in the primary region
GRS	Local redundancy plus replication to a secondary region
GZRS	Zone redundancy plus replication to a secondary region

Geographic replication is asynchronous, so the secondary region can lag behind recent writes. Read-access variants allow reads from the secondary endpoint; they do not provide general writes there. Review Microsoft's failover guidance and decide how the application should behave during an outage.

Multiple copies support resilience, but high availability and recovery to an earlier state need separate planning. Decide which previous state you need to recover, who can initiate recovery, and how long the process may take. Use a documented restoration test to check that the chosen protections deliver that result.

Protect Azure Storage data with scoped access

Prefer identities over embedded account keys

Microsoft recommends Microsoft Entra ID authorization for Blob, Queue, and Table access where possible, including managed identities for applications. Grant the required data permissions at the narrowest suitable scope. When delegated access is needed, review the supported shared access signature (SAS) options, permissions, and expiry. File-share authentication needs its own protocol-specific review.

Check encryption and network access separately

Azure Storage encrypts data at rest using 256-bit AES, with Microsoft-managed keys by default and customer-managed key options subject to service support. Service-side encryption is not a promise that only the end user can decrypt the data.

For REST access, the secure transfer required setting rejects HTTP requests and requires HTTPS; it is enabled by default for new accounts. SMB and NFS connections have their own transport-security requirements. Review those settings alongside endpoint exposure and access permissions.

Before production, have someone other than the setup owner test both an allowed request and a denied request. Record who can change permissions or delete resources. These operational checks belong in the same review as your broader cloud security controls.

Match Blob Storage tiers to retrieval needs

For eligible block blobs, Hot, Cool, Cold, and Archive tiers balance storage and access costs. Cool, Cold, and Archive have minimum billable durations of 30, 90, and 180 days respectively. These are billing rules, not retention locks: deleting or moving data early can incur charges.

Archive is offline. You must rehydrate an archived blob before reading its contents, and retrieval can take hours. Do not place a needed recovery copy there without testing whether retrieval fits your recovery deadline.

Smart tier can automatically move eligible block blobs among Hot, Cool, and Cold based on access patterns. It does not move them into Archive. Check account and redundancy eligibility, object-size rules, and monitoring charges before enabling it.

Choose a tier using the next likely read, not just the last one. An old file may still be urgently needed during an investigation or restore. Record which data can wait, which must remain immediately accessible, and who approves a policy change.

Estimate the full operating cost

The Azure Blob Storage pricing page separates capacity, operations, retrieval, and relevant transfer charges. Region, redundancy, and access tier affect the estimate. Other services, including Files and managed disks, have their own pricing models.

Build three estimates with the same workload assumptions: an ordinary month, a busy month, and a recovery or migration month. Include the following inputs:

• Average stored capacity and expected growth.
• Object or file count, typical sizes, and read/write frequency.
• Data retrieved, transferred between regions, or moved out.
• Copies, versions, logs, and other retained data.
• Any minimum-duration or provisioned-capacity charges.

This makes the comparison useful even when unit prices change. A low capacity price alone does not tell you what a frequent-read workload or large export will cost. Keep the assumptions with the estimate so another person can reproduce it.

Test performance and configure monitoring

Capacity and performance are separate limits. Microsoft's standard account targets list a default capacity of 5 PiB, with higher limits available by request. Request rates and bandwidth depend on configuration and region; that capacity figure is not a throughput guarantee.

For workloads that require high throughput, test representative file sizes and concurrency from the actual client location. Measure latency, throughput, errors, and completed application work. For a batch job, the useful result may be total processing time; for interactive file access, delays on small reads may matter more than peak transfer speed.

Configure Azure monitoring and diagnostic settings deliberately. Resource logs need routing and collection settings before they are stored for later queries. Choose useful categories, retention, and alerts, and account for the cost of collecting them.

Start with a small, reversible deployment

You can manage Azure storage through the Azure portal, command-line tools, APIs, SDKs, and Storage Explorer. Microsoft's storage introduction links to the supported tools and service documentation. Use the interface your team can maintain consistently.

1. Define the workload. Record the access protocol, data size, read pattern, and acceptable downtime.
2. Select the resource. Check account model, region, redundancy, and feature compatibility together.
3. Set access controls. Assign identities and permissions, then test allowed and denied access.
4. Load a representative sample. Verify content integrity, metadata, and application behavior.
5. Test recovery and cost. Restore data, measure completion time, and compare observed usage with the estimate.

Keep the source copy until the migration's acceptance checks pass. A successful upload is one check; it does not prove that permissions, search, directory behavior, or recovery will work as expected.

Example: separating file storage from processing

Consider a team that accepts customer video uploads and produces smaller preview files. One possible design puts the original in Blob Storage, then sends a Queue Storage message identifying the object. A worker retrieves it, creates the preview, and records the outcome. The queue tells the worker what to do; the blob holds the large payload.

That design uses multiple types of Azure services without asking one service to do every job. Before handling large volumes, define what happens if a worker stops halfway through processing. Test retries without producing duplicate results, and decide when originals and previews should be removed. These are application decisions that storage capacity alone cannot resolve.

A shared folder application starts from a different requirement. Evaluate Azure Files and its file storage behavior before redesigning around objects. High performance means completing the intended task within its deadline, so compare the whole workflow, including client access and processing.

When to evaluate an alternative

Microsoft Azure is worth evaluating when the workload depends on its VM, identity, analytics, or messaging services. If you only need object storage, compare providers against that narrower requirement and include the work required to change APIs, permissions, and operations.

Hivenet Object Storage supports S3-compatible tools for workloads such as datasets, backups, media, and application objects. An application using Azure Blob APIs still needs a compatibility and migration review. Object storage is not a direct replacement for Azure Files, Queue Storage, or VM disks.

Run the same sample workload on any shortlisted service. Compare access behavior, regional availability, recovery, support, and the full estimate. Choose from the results your team can demonstrate, then document what would be needed to leave.