Azure Storage Services, Tiers & Redundancy: AZ-900

Azure storage services are the managed cloud services Microsoft Azure provides for keeping data safely and making it available to your applications. Instead of buying and looking after your own disk arrays and file servers, you store data in Azure, and Microsoft handles the underlying hardware, patching, and durability for you. Azure always keeps multiple copies of your data so that a single hardware failure does not lose it.

Different kinds of data need different kinds of storage, so Azure offers several distinct services rather than one. Some data is unstructured — photos, videos, documents, and backups that do not fit neatly into rows and columns. Some is a traditional file share that many people or servers open at once. Some is a stream of messages passed between parts of an application, some is simple structured data such as a lookup table, and some is the disk a virtual machine boots from.

For AZ-900 you are not asked to configure storage; you are asked to recognize which service fits a described need and which setting meets a stated constraint such as cost, immediate access, or surviving an outage. This lesson covers the services, the storage account that holds them, the two settings you tune on top — access tiers and redundancy — and the tools for moving and migrating data into Azure.

The five Azure Storage services each do one job: Azure Blobs store unstructured objects, Azure Files provide shared file shares, Azure Queues pass messages, Azure Tables hold NoSQL key-value records, and Azure Disks are the block-level volumes attached to virtual machines. Microsoft Learn uses these short names; the longer forms (Azure Blob Storage, Azure Queue Storage, and so on) mean the same services.

Two near-twins decide many questions. Azure Disks vs Azure Files: a managed disk is attached to a virtual machine and appears to that VM's operating system as a locally attached drive that the VM formats with its own file system; it is not a folder that users and other servers browse over the network. When many machines or people need the same files, that is a share — Azure Files. Azure Queues vs the data itself: a queue holds small messages saying what work is waiting, not the large files. A common pattern combines services — uploads are stored as blobs while a queue message tells a background worker which blob to process; if the worker is offline, messages wait in the queue so no job is lost.

Azure Blob Storage is Azure's object storage service: it stores data as individual objects — each file plus its metadata — rather than in a file-system folder tree or a database table. Blob stands for "binary large object," and it can be anything: a photo, a video, a PDF, an installer, a log file, or a database backup. That is why Blob Storage is described as being for unstructured data — the service does not care what is inside the object.

Blobs live inside containers, which group related objects within a storage account. Each blob has its own web address, so applications, websites, and users read or write objects directly over HTTP or HTTPS. That makes Blob Storage a natural fit for serving images and video to a website, holding backups and archives, and storing large data sets for analysis.

Because it is built for massive scale with pay-as-you-go pricing, you can store a few files or many petabytes and pay only for what you keep and access. Blobs are also the data type whose access tier you choose, which the next section covers.

Access tiers let you match a blob's storage price to how often it is read: the less often you access data, the cheaper it is to store and the more it costs to read. There are three online tiers — hot, cool, and cold — whose data can be read immediately (milliseconds), and one offline tier — archive — whose data cannot be read until it is rehydrated.

Minimum retention and early deletion. Cool, cold, and archive each have a minimum storage period. If you delete a blob, overwrite it, or move it to another tier before that period ends, Azure applies an early deletion charge, prorated for the days remaining — for example, deleting an archived blob after 60 days is billed as if it had been kept the remaining 120 of its 180 days. So the cheapest tier on paper is not always cheapest in total. Archive suits data you can leave untouched for at least 180 days and can wait hours to read; if reads must be immediate, archive is ruled out however rarely they happen, and the cheapest choice is the coolest online tier whose minimum period the data will outlast.

Reading archived data. While a blob is in the archive tier it cannot be read or modified (you can still list it and see its metadata). To read it you must rehydrate it to an online tier, which can take up to about 15 hours depending on the priority you choose. There are two ways: change the blob's own tier from archive to hot, cool, or cold, or copy the archived blob to a new blob in an online tier. Those are the only two ways: a blob leaves the archive tier only through a tier change on the blob itself or a copy to an online tier.

The account default tier. Every general-purpose v2 storage account has a default access tier — hot unless you change it — that applies to new blobs without an explicitly set tier. The default can be hot, cool, or cold (or Smart, covered below), but never archive; archive is set per blob. Changing the default affects only blobs whose tier is inferred from it, so a blob explicitly moved to archive stays offline. Archive is also available only in accounts using LRS, GRS, or RA-GRS — not in ZRS, GZRS, or RA-GZRS accounts.

Automating tiering. Lifecycle management rules can move blobs to cooler tiers as they age. Microsoft also offers smart tier, which automatically moves data among the hot, cool, and cold tiers based on actual usage, so you do not have to predict the access pattern. You turn it on by setting the account's default access tier to Smart, and it requires a standard general-purpose v2 account using zone-redundant redundancy (ZRS, GZRS, or RA-GZRS). Smart tier never moves data into archive, and neither it nor lifecycle rules rehydrate archived data for you.

Redundancy is the storage account setting that decides how many copies of your data Azure keeps and where, which in turn decides what failure your data survives. The options combine two choices: how copies are spread in the primary region (one location or three availability zones), and whether data is also copied to a paired secondary region.

In-region options. LRS is the cheapest but does not survive the loss of its datacenter. ZRS keeps working through the loss of one availability zone. Both keep every copy inside one region, which also suits a requirement that data must not leave that region — but neither protects against a whole-region outage.

Geo options and failover. GRS and GZRS copy data to the paired secondary region, protecting against a full regional outage. By default that secondary copy is not readable: it becomes usable only after a failover, which either you start (customer-managed failover) or Microsoft starts in a severe disaster (Microsoft-managed failover). The read-access variants, RA-GRS and RA-GZRS, let applications read the secondary copy at any time, before or without a failover. RA-GRS is the lower-cost of the two because its primary region uses LRS.

GRS vs GZRS. Microsoft designs the geo options for the same very high durability, so the difference is not "more copies is safer." It is availability in the primary region: GRS uses LRS there, so losing that datacenter or zone means waiting for or triggering a failover, while GZRS uses ZRS there and stays readable and writable through a zone failure. Choose GZRS when you need both zone-level availability and regional disaster protection.

A storage account is the Azure resource that holds your Blobs, Files, Queues, and Tables, gives them a globally unique namespace, and carries the settings that apply to them: region, performance, redundancy, and the default access tier. (Azure Disks are the exception — managed disks are their own Azure resources, and Microsoft manages the storage behind them.)

The name is globally unique because it forms the web addresses. A storage account name (3–24 lowercase letters and numbers) must not be used by any other account anywhere in Azure, because every service endpoint is built from it — for example https://<account>.blob.core.windows.net for Blobs, with matching file, queue, and table endpoints. The name does not decide the region, the resource group, or anyone's sign-in.

Standard vs premium. Standard performance is backed by hard disks and priced for general use; premium is backed by solid-state drives for consistently low latency. The type follows the workload: a latency-sensitive file share needs a premium file shares account, not a premium block blob account. Standard file shares billed in the pay-as-you-go model offer their own access tiers (transaction optimized, hot, and cool) to tune cost, but they stay on hard-disk-backed storage. Premium accounts offer only in-region redundancy (LRS or ZRS), and the blob access tiers (hot, cool, cold, archive) belong to standard accounts.

Azure gives you three tools for moving files into and out of storage, and the exam asks you to pick one from who is doing the work and how: AzCopy for scripted command-line copies, Azure Storage Explorer for point-and-click use, and Azure File Sync for keeping on-premises file servers continuously in sync with Azure.

AzCopy and Storage Explorer are one-off copy tools (Storage Explorer actually uses AzCopy for its transfers). Neither keeps two locations in step after the copy finishes.

Azure File Sync is different: it continuously synchronizes one or more Windows Server file servers with an Azure file share (Azure Files — not Blob Storage), so branch offices can each keep a local server while the authoritative copy lives in Azure. Its cloud tiering feature turns the local server into a cache: frequently used files stay on the local disk, while rarely used ones are tiered to the Azure file share and replaced locally by pointers. Users still see every file in the same folders, and opening a tiered file fetches it from Azure on demand, so local disk space is freed while the namespace people use stays the same. File Sync runs on Windows Server only; it is not a general tool for Linux servers or for blob containers.

For larger, one-time moves, Azure offers two migration options that solve different problems: Azure Migrate plans and runs the migration of whole workloads, while Azure Data Box physically ships large amounts of data when the network is too slow.

Azure Migrate is a central hub for moving servers, databases, web apps, and virtual desktops to Azure, and it works in three stages: discover what you run on-premises, assess it — whether each workload is ready for Azure, what size it should be, and an estimate of what it will cost to run — then migrate it, all tracked from one place. Start with Azure Migrate when an organization does not yet know what it has or what moving will cost.

Azure Data Box is a ruggedized physical device Microsoft ships to you. For an import, you copy data onto it and ship it back, and Microsoft uploads it to your storage account. For an export, Microsoft copies data from your storage account onto the device and ships it to you — useful when a large data set must come back on-premises. Data Box fits when there are tens to hundreds of terabytes to move and no or limited network bandwidth, so transferring over the internet would take weeks. Current devices hold tens or hundreds of terabytes each; you do not need exact capacities for AZ-900.

For example, a research lab holding several hundred terabytes of instrument data behind a slow connection would ship it on a Data Box rather than upload for weeks, then use AzCopy for the smaller transfers that follow.