Configure & Manage Azure Storage Accounts and Redundancy (AZ-104)

A storage account is the Azure resource that gives your data a unique namespace, and its account kind and performance tier are chosen together when you create it. For almost every workload the answer is standard general-purpose v2 (GPv2): it hosts blobs, files, queues and tables, supports the hot, cool, cold and archive access tiers, and is the only kind that offers every redundancy option.

Premium performance stores data on SSDs for consistently low latency and high transaction rates, and it is delivered through specialised account kinds, each built for one data type:

Two distinctions matter. First, a FileStorage account is not automatically premium: it hosts both SSD shares and provisioned v2 HDD shares, so a requirement for consistent single-digit-millisecond file latency needs the SSD media tier specifically; pay-as-you-go HDD shares (transaction optimized, hot, cool) live in GPv2 accounts. Second, a high rate of small, latency-sensitive blob reads and writes is what premium block blob accounts are for, while bulk, throughput-oriented blob storage stays on standard GPv2.

Older kinds — general-purpose v1 and legacy BlobStorage — still exist but are legacy; a GPv1 account can be upgraded in place to GPv2 (a one-way change). Unless a scenario calls out low latency, SSD file shares or page-blob performance, standard GPv2 is the right kind.

Some storage account settings are permanent and others can be changed at any time, so knowing which is which tells you when a change needs a new account and a data copy. The account name is the first permanent one: it must be 3–24 characters of lowercase letters and digits only (no hyphens, underscores or capitals) and globally unique, because it becomes part of every service endpoint, such as https://contosodata.blob.core.windows.net (with file, queue, table, dfs and web variants).

The hierarchical namespace (Azure Data Lake Storage: real directories, atomic renames and POSIX-style ACLs) is usually chosen at creation, but an existing GPv2 account can be upgraded in place to enable it. The upgrade runs a validation step first, keeps your data where it is, and is one-way — it cannot be turned off afterwards. So "add directory semantics without copying the data" is an in-place upgrade, whereas "switch to premium" or "move to another region" means creating a new account and copying the data.

Redundancy determines how many copies of your data Azure keeps and where, and therefore which failures the data survives. Every option keeps at least three copies; they differ in whether those copies survive a hardware fault, the loss of a datacenter (zone), or the loss of a whole region. The setting applies to every service in the account.

Locally redundant storage (LRS) keeps three copies in a single datacenter — the cheapest option, but a datacenter disaster can lose the data. Zone-redundant storage (ZRS) writes synchronously across availability zones in one region and keeps serving reads and writes if a zone fails. Geo-redundant storage (GRS) keeps LRS copies in the primary region and copies the data asynchronously to the paired secondary region, which is fixed by the primary region you pick. Geo-zone-redundant storage (GZRS) uses ZRS in the primary region plus geo-replication. In the secondary region, GRS and GZRS both store the data as LRS — only the primary differs.

Three limits narrow the choice. Premium account kinds have no geo-redundancy at all: premium block blob and SSD file share accounts support LRS and ZRS, and premium page blobs only LRS — a cross-region copy of premium block blobs needs object replication instead. The archive tier is supported only with LRS, GRS and RA-GRS, never with ZRS, GZRS or RA-GZRS, so a requirement to archive blobs rules the zone-redundant options out. And Azure Files supports GRS and GZRS but not the read-access variants.

RA-GRS and RA-GZRS are GRS and GZRS with read access to the secondary region at all times, without any failover. With plain GRS or GZRS the secondary copy cannot be read or written until the account is failed over — a failover that you, the customer, initiate (see the next section). If the data only needs to exist elsewhere for recovery, GRS or GZRS is enough; if an application must read from the secondary region during normal operation or keep reading during a primary outage without waiting, only the RA- variants work.

The secondary is exposed through its own endpoint: the account name with a -secondary suffix, for example https://contosodata-secondary.blob.core.windows.net. It uses the same access keys as the primary, and it is read-only — writes sent to it fail rather than being forwarded to the primary.

Because geo-replication is asynchronous, the secondary is eventually consistent: reads there can miss recent writes. The account's Last Sync Time property shows the point up to which every write is guaranteed to be in the secondary; anything written after it may not be there yet. Remember too that the secondary region keeps its copies as LRS even for RA-GZRS — zone redundancy applies to the primary only.

Account failover promotes the secondary region of a geo-redundant account to be the new primary by updating the endpoints' DNS, and the customer starts it per storage account. There are two customer-managed types and one Microsoft-managed one, and they leave the account in very different states:

After an unplanned failover, nothing replays the lost writes: there is no pending queue, and the old primary copy is gone. Use the Last Sync Time to estimate how much will be lost before you start. To restore protection you re-enable GRS or RA-GRS, which copies the whole account to a new secondary (an egress charge; archived blobs must first be rehydrated). A planned failover needs both regions up and keeps geo-redundancy, so it is the tool for a no-data-loss DR test that ends with a failback.

Microsoft-managed failover is reserved for a catastrophic disaster affecting a whole region; Microsoft starts it for the region, and it cannot be requested for an individual account, subscription or tenant. Plan on customer-managed failover. A few features block customer-managed failover — notably premium block blob accounts (no geo-redundancy) and NFS 3.0 — and failover is a recovery tool, not a way to migrate an account to another region.

Redundancy can be changed on an existing account, but how depends on which part changes. Adding or removing geo-replication or read access (LRS ↔ GRS ↔ RA-GRS, ZRS ↔ GZRS ↔ RA-GZRS) is a setting you save on the account's Redundancy page or with PowerShell/CLI; adding geo-redundancy costs a one-time egress charge to copy the account, and an LRS account that holds blobs archived while it was LRS cannot be switched to GRS or RA-GRS until those blobs are rehydrated or deleted. Adding or removing zone redundancy (LRS ↔ ZRS, GRS ↔ GZRS) is a conversion.

• A customer-initiated conversion (portal Redundancy page, Start-AzStorageAccountMigration or az storage account migration start) runs in the background with no downtime and no data loss (an account with a hierarchical namespace may pause for under 30 seconds at the switch), and the account keeps its endpoints, access keys and SAS tokens. It usually starts within 72 hours and has no completion SLA.
• A manual migration — create a new account and copy the data with a tool such as AzCopy — is for when a deadline matters, the conversion is not supported, or the account must move region. It changes endpoints and usually means downtime.
• A change that touches both zone and geo redundancy takes two steps: for LRS → GZRS, switch to GRS (a setting) and then convert to GZRS, or convert to ZRS and then switch to GZRS. After a zone conversion you must wait at least 24 hours before the next redundancy change.

Common blockers for a conversion to zone redundancy: blobs in the archive tier (zone-redundant options do not support it — move or rehydrate them first), an account that became LRS through an unplanned failover (only a manual migration adds zone redundancy there), NFS 3.0 enabled on Blob Storage, a region without availability zones, and premium block blob accounts (manual migration only). Features such as versioning, soft delete, customer-managed keys and lifecycle rules to the cool tier do not block it.

Object replication asynchronously copies block blobs from a container in a source account to a container in a destination account according to policy rules you define. Unlike redundancy, which Azure manages invisibly inside one account, object replication copies selected blobs between two accounts you own — in any region, in different subscriptions, and even different Microsoft Entra tenants (if the accounts' cross-tenant replication setting allows it).

Prerequisites: blob versioning on both accounts and the change feed on the source. Both accounts must be standard GPv2 or premium block blob accounts, and accounts with a hierarchical namespace (Data Lake Storage) are not supported. Settings such as soft delete, customer-managed keys or the default access tier do not prevent it. Because premium block blob accounts cannot use geo-redundancy, object replication to a premium account in another region is how you keep a cross-region copy while keeping SSD latency.

How it behaves:

• A policy has one or more rules, each mapping a source container to a destination container, optionally filtered by blob-name prefix.
• By default a rule copies only blobs created after the rule exists. To include existing blobs, choose the copy scope when you create the rule: all objects, or objects created after a chosen date (minCreationTime).
• Once a container is a replication destination, client writes to it fail with HTTP 409 (Conflict); reads and deletes still work. To write there you must remove the rule.
• Not replicated: blob snapshots, append blobs and page blobs, and access-tier changes (each account manages its own tiers).
• Replication is asynchronous: a blob reaches the destination some time after the source write completes, so the destination is eventually consistent.

Typical uses are keeping a copy close to readers in another region, running processing near the data, and replicating to an account with different tiering for cost.

All data in Azure Storage is encrypted at rest with 256-bit AES by Storage Service Encryption, and it cannot be turned off; what you configure is who controls the keys and how many layers there are. Encryption is transparent — applications call the storage APIs exactly as before — except with customer-provided keys.

Configuring customer-managed keys

• The account reaches the key through a managed identity granted get, wrapKey and unwrapKey on the key (or the Key Vault Crypto Service Encryption User role). For an existing account a system- or user-assigned identity works; to configure CMK while creating the account you must use a user-assigned identity, because a system-assigned one does not exist until the account does.
• The key vault must have soft delete and purge protection enabled.
• If you configure the key without a version, Azure checks the vault daily and starts using the newest version automatically. If you pin a specific version, rotations are ignored until you update the account to the new version.
• Revoking the identity's access or disabling the key makes the data inaccessible — the point of holding the key yourself.

Infrastructure encryption and encryption scopes

Infrastructure encryption adds a second layer at the infrastructure level, with a different algorithm and a different (Microsoft-managed) key, for requirements of double encryption. For a whole account it can be enabled only at creation.

Encryption scopes give different keys to different containers or blobs inside one account. Each scope uses a Microsoft-managed or customer-managed key, and a scope can require infrastructure encryption when the scope is created — even in an account created without it, which is how you add double encryption for one project without moving the rest of the account. A container's default scope, and whether every blob in it must use that scope, is set when the container is created, so existing data is brought under a new scope by creating a new container and moving the data into it. Disabling a scope makes reads and writes of its data fail with 403; this is how a multi-tenant app can cut off one customer's data while all customers stay in one account. Scopes cannot be deleted, only disabled.

Azure Storage Explorer is the free graphical desktop app (Windows, macOS, Linux) for interactive work, and AzCopy is the command-line tool for scripted, high-throughput transfers. Storage Explorer connects with your Entra sign-in, an access key, a SAS or a connection string, and lets you browse containers, shares, queues and tables, upload and download, and edit properties, metadata and access policies; it uses AzCopy under the hood for its transfers. AzCopy copies between local storage and Azure or directly account-to-account (server-to-server) and fits scripts and pipelines.

azcopy copy "C:\data\*" "https://acct.blob.core.windows.net/container?[SAS]" --recursive

Authorization. AzCopy accepts a SAS appended to each URL, or a Microsoft Entra identity via azcopy login. With Entra, management-plane roles such as Owner or Contributor are not enough: data access needs a data-plane role — Storage Blob Data Contributor (or Owner) to upload, Storage Blob Data Reader to download. A 403 "authorization permission mismatch" after azcopy login usually means that role is missing.

copy vs sync. azcopy copy transfers what you name. azcopy sync compares source and destination by last-modified time and transfers only new or changed files, one way. By default sync never deletes anything at the destination; add --delete-destination=true to remove destination files that no longer exist at the source (or prompt to ask first).

Resuming. Every AzCopy job writes a plan file. azcopy jobs list shows jobs, and azcopy jobs resume <job-id> continues an interrupted job without re-transferring completed files. The plan file does not keep SAS tokens, so supply them again with --source-sas and --destination-sas.

For large, managed migrations from on-premises file shares, Microsoft also offers Azure Storage Mover, an agent-based migration service orchestrated from Azure. Azure File Sync, by contrast, keeps Windows file servers synchronised with Azure file shares; it is not a copy tool for blob containers.

A customer-facing application's data must survive a complete outage of its primary region, and the application must read from the secondary region — to serve some read traffic there and to keep working if the primary is unreachable. Which redundancy option fits?

Eliminate options. LRS and ZRS stay in one region, so neither survives a regional outage. GRS and GZRS replicate to a second region, but their secondary cannot be read until a failover, so they miss the read requirement. That leaves RA-GRS or RA-GZRS.

Between the two, RA-GZRS also protects the primary against a zone failure, while RA-GRS costs less with an LRS primary. One more constraint can decide it: if blobs must move to the archive tier, only RA-GRS works, because the zone-redundant options do not support archive. Either way the application reads through the -secondary endpoint and must tolerate data that lags behind the Last Sync Time.