Azure Storage accounts: services, account types, redundancy, endpoints, and network access

radio_button_uncheckedshort_text1. Design storage for a high-traffic commerce workload

Imagine an e-commerce company that must retain and serve a very large catalog of product images. Traffic can surge, the objects must remain durable, and recovery after an outage must be fast. Azure Storage supplies scalable cloud data services, but the administrator still has to select the right service, account type, redundancy, endpoint, and access boundary.

This chapter prepares an Azure administrator to identify storage-account capabilities and use cases, create the appropriate account, select a replication strategy, and secure network access to its data endpoints.

• Classify virtual-machine, unstructured, and structured data.
• Choose among Blob Storage, Azure Files, Queue Storage, and Table Storage.
• Compare Standard and Premium account types and recognize legacy accounts.
• Match LRS, ZRS, GRS, RA-GRS, GZRS, or RA-GZRS to a failure model.
• Construct service URLs, map a custom domain, and choose public, service-endpoint, or private-endpoint access.

Prerequisites are experience with the Azure portal and familiarity with managing different forms of data storage.

radio_button_uncheckedshort_text2. Azure Storage is a managed platform for several data patterns

Azure Storage is Microsoft’s cloud-storage platform for modern workloads. One storage account can expose a massively scalable object store, managed file shares, durable application messaging, and a schemaless NoSQL key/attribute store. It supports working data for websites, mobile and desktop apps, IaaS virtual machines, PaaS services, analytics, and AI-ready data pipelines.

The platform is designed around durability and availability, encryption, large-scale capacity and throughput, Microsoft-managed hardware and updates, and worldwide access over HTTP or HTTPS. Those properties do not remove design choices: the account, service, protocol, access tier, redundancy, and network rules still determine behavior and cost.

radio_button_uncheckedshort_text3. Start by classifying the data

radio_button_uncheckedshort_text4. Access and protocol choices affect manageability and security

Applications can use the Azure Storage REST API or client libraries for languages including .NET, Java, Node.js, Python, PHP, Ruby, and Go. Administrators can automate with Azure PowerShell and Azure CLI or work visually in the Azure portal and Microsoft Azure Storage Explorer.

Blob Storage can expose SFTP over port 22 for existing transfer tools when hierarchical namespace (HNS) is enabled. HNS can be selected on the Advanced tab during creation or enabled later through the account configuration workflow when the account is eligible. NFS 3.0 can let Linux clients mount a blob container like an NFS share and ease migration of Linux file workloads. Feature compatibility varies when HNS, NFS, or SFTP is enabled, so validate the current account matrix before deployment.

For authorization, prefer Microsoft Entra ID and least-privilege Azure RBAC where the protocol supports it. The portal can default data access to Microsoft Entra authorization instead of Shared Key. Disabling Shared Key is stronger than changing the portal default, but first verify application, Azure Files, SAS, and tooling compatibility.

radio_button_uncheckedshort_text5. Four core services share the storage-account boundary

radio_button_uncheckedshort_text6. Blob Storage handles massive unstructured object data

Azure Blob Storage is optimized for text and binary objects at very large scale. It is a natural choice for images or documents delivered to a browser, distributed files, audio and video streaming, logs, backup and restore, disaster recovery, archiving, and data analyzed by an on-premises or Azure-hosted service.

Clients reach blobs anywhere through HTTP or HTTPS using URLs, the Azure Storage REST API, Azure PowerShell, Azure CLI, or a supported client library. Blob Storage also underpins Azure Data Lake Storage Gen2 when HNS is enabled.

radio_button_uncheckedshort_text7. Azure Files supplies managed network file shares

Azure Files exposes highly available shares through Server Message Block (SMB) and, for supported premium configurations, Network File System (NFS). Multiple VMs can read and write the same files, while REST and client libraries provide another access path.

• Mount a share using the same drive letter expected by an on-premises application to reduce migration changes.
• Centralize configuration files, development tools, and utilities so multiple VMs or developers use the same version.
• Collect diagnostic logs, metrics, and crash dumps for later processing or analysis.

The supplied module describes account credentials granting mounted users read/write access. Modern designs should instead evaluate Microsoft Entra-based identity, Kerberos for SMB, share and file permissions, and least privilege rather than distributing storage-account keys.

radio_button_uncheckedshort_text8. Queue Storage decouples asynchronous processing

Azure Queue Storage retains messages for later processing. A message can be as large as 64 KB, and one queue can contain millions of messages. Producers and consumers can scale independently, which is useful for smoothing bursts and building reliable work backlogs.

In the module scenario, a customer uploads a picture and receives a quick response. The application adds a message to a queue; an Azure Function consumes it and creates a thumbnail later. Upload and image-processing capacity can then be tuned separately.

radio_button_uncheckedshort_text9. Table Storage provides a schemaless key/attribute store

Azure Table Storage stores structured, nonrelational data as entities and properties without enforcing one shared schema. The service scales with demand, the design adapts easily as an application evolves, and it can be faster and less expensive than relational SQL for appropriate key-oriented volumes.

Azure Cosmos DB for Table is the related alternative when the workload needs throughput-optimized tables, global distribution, automatic secondary indexes, or other Cosmos DB capabilities. Neither choice replaces Azure SQL Database when joins, relational constraints, or a SQL engine are fundamental.

radio_button_uncheckedshort_text10. Choose the service from the workload’s dominant operation

radio_button_uncheckedshort_text11. Standard and Premium describe performance and workload intent

Standard is the default, cost-oriented performance option for general-purpose v2 accounts and most scenarios. The training module characterizes it as the choice for bulk or infrequently accessed data. Premium uses SSD-backed infrastructure for consistently low latency and high throughput and is divided by the optimized data service.

An existing storage account cannot be converted to another account type simply by switching Standard and Premium. Create a new account of the target type and copy the data. Regardless of type, Azure Storage automatically applies service-side encryption to data at rest.

radio_button_uncheckedshort_text12. The account-type matrix limits services and redundancy

The exact redundancy options vary by account type and Azure region. Treat the portal and current documentation as the deployment-time source of truth rather than memorizing every combination as globally available.

radio_button_uncheckedshort_text13. Legacy accounts should move toward general-purpose v2

Existing subscriptions can still expose general-purpose v1 and legacy BlobStorage accounts. They lack modern features or cost-management options and are not recommended for new deployment. Microsoft supports in-place upgrade to general-purpose v2 through the Azure portal, Azure CLI, or PowerShell; review costs and feature compatibility first because the upgrade cannot be reversed.

Classic Azure Service Management storage accounts were retired on August 31, 2024. Do not confuse an in-place GPv1-to-GPv2 upgrade with changing an account between Standard and Premium, which requires a new destination account and data copy.

radio_button_uncheckedshort_text14. Redundancy is a failure-model and access decision

Azure Storage always keeps multiple copies to withstand planned and unplanned hardware, network, power, datacenter, zone, and regional events. The options trade cost against the failure boundary, replication latency, and whether clients can read a secondary region before failover.

One redundancy setting applies to the storage services in an account. Separate resources into different accounts when their durability, residency, or read-access requirements differ. Redundancy is not backup: deletions and overwrites can replicate to every copy, so use soft delete, versioning, snapshots, or backup where recovery from logical error matters.

radio_button_uncheckedshort_text15. LRS keeps copies inside one physical datacenter

Locally redundant storage (LRS) synchronously maintains three copies within one datacenter in the primary region. It is the lowest-cost option and protects against disk, server, and rack failures, but a datacenter-wide fire, flood, or prolonged outage can make every replica unavailable or unrecoverable.

• Use it when the data can be reconstructed after loss.
• Consider it for rapidly changing feed data whose retention is not essential.
• Use it when governance requires replication to remain within one location and the lower resilience is accepted.

radio_button_uncheckedshort_text16. ZRS survives an availability-zone failure in one region

Zone-redundant storage (ZRS) synchronously copies data across three or more availability zones in the primary region. Each zone has separate power, cooling, and networking. Reads and writes can continue if one zone becomes unavailable, with strong performance and low latency.

ZRS availability depends on region and account type. Moving from a single storage stamp to zonal placement can require a conversion and physical data movement. ZRS protects against a zone failure, not a disaster that permanently affects the entire region.

radio_button_uncheckedshort_text17. GRS adds asynchronous replication to a secondary region

Geo-redundant storage (GRS) first commits data synchronously using LRS in the primary region, then copies it asynchronously to a geographically distant secondary region, where LRS creates local replicas. The primary and secondary storage scale units use separate fault and upgrade domains. GRS is designed for at least 99.99999999999999% durability—sixteen nines—over a year.

With GRS, secondary data becomes readable only after a failover. Read-access geo-redundant storage (RA-GRS) exposes a read-only secondary endpoint before failover, so applications can read the secondary during a primary-region problem. Because inter-region replication is asynchronous, the latest writes can lag; inspect last-sync time and design for a recovery point.

radio_button_uncheckedshort_text18. GZRS combines zone continuity with regional disaster recovery

Geo-zone-redundant storage (GZRS) uses ZRS across availability zones in the primary region and asynchronously replicates to an LRS-protected secondary region. Azure pairs the regions within the same geography. GZRS keeps primary-region reads and writes available through a zone failure, retains a disaster-recovery copy for a complete regional outage, targets the same scalability as the other redundancy modes, and is designed for sixteen nines of annual object durability.

Read-access geo-zone-redundant storage (RA-GZRS) additionally exposes the secondary copy for reading before failover. The module recommends GZRS when consistency, durability, availability, performance, and regional resilience all matter, and RA-GZRS when secondary read access is also required. Azure Files does not support RA-GRS or RA-GZRS.

radio_button_uncheckedshort_text19. Compare redundancy by the outage that must remain serviceable

radio_button_uncheckedshort_text20. Every storage service exposes a distinct endpoint

A storage account name forms the subdomain in each default endpoint. The service-specific DNS suffix completes the account endpoint; the object path is appended afterward.

A blob named myblob inside mycontainer therefore has the address https://mystorageaccount.blob.core.windows.net/mycontainer/myblob. The account namespace is globally unique, and current account names contain 3–24 lowercase letters or numbers.

radio_button_uncheckedshort_text21. A custom domain maps a subdomain to a blob or static-website endpoint

Direct mapping creates a public DNS CNAME from a custom subdomain such as blobs.contoso.com to the storage hostname, for example contosoblobs.blob.core.windows.net. Register the custom domain with the storage account, allow DNS propagation, verify ownership, and test access to a known object.

The native mapping supports subdomains, not the zone apex. Direct mapping by itself is HTTP-only; use Azure Front Door or Azure CDN when the custom domain needs HTTPS or root-domain delivery. For a live domain that cannot tolerate interruption, use the asverify intermediary CNAME and indirect validation workflow before switching the production CNAME.

radio_button_uncheckedshort_text22. Firewall, service endpoints, and private endpoints solve different boundaries

Storage firewall rules govern the public endpoint. They can allow selected virtual-network subnets, public IP ranges, resource instances, or trusted-service exceptions and deny other sources. In the portal these controls appear under networking and public network access; test the result so an assumed rule does not leave the account exposed or block production.

A private endpoint does not automatically disable the public endpoint; configure public network access and firewall policy to match the isolation objective. Each storage subresource can require its own private endpoint and private DNS record. Use the normal connection string and hostname rather than connecting directly to a privatelink URL.

radio_button_uncheckedshort_text23. Assessment answers connect requirements to features

radio_button_uncheckedshort_text24. Compact version of every topic

radio_button_uncheckedshort_text25. Active recall and official resources

Active-recall prompts

• Explain Azure Storage redundancy to a nontechnical stakeholder without calling it backup.
• Choose an account type for a general application, high-transaction block blobs, SMB/NFS shares, and page blobs.
• Draw LRS, ZRS, GRS, RA-GRS, GZRS, and RA-GZRS from memory.
• Build the four default endpoints from a storage-account name.
• Compare a firewall rule, service endpoint, and private endpoint.
• Explain why a custom subdomain needs a CNAME and ownership verification.
• Ask Microsoft Copilot to compare storage account types, then verify its answer against the current account matrix.

Official documentation

• Introduction to Azure Storage
• Storage account overview
• Introduction to Blob Storage
• Azure Storage redundancy
• Authorize data access
• Storage firewall rules
• Use private endpoints for Azure Storage
• Map a custom domain to a Blob Storage endpoint
• Training: Create an Azure storage account
• Training: Design and implement private access to Azure services