Implement and manage storage

Storage accounts

• A storage account is the namespace for blobs, files, queues and tables. The name is 3-24 characters, lowercase letters and digits only, and globally unique (it becomes name.blob.core.windows.net).
• Use general-purpose v2 (StorageV2) for nearly everything. Premium account types exist for low latency: premium block blobs, premium file shares (FileStorage), and premium page blobs.
• Enabling hierarchical namespace makes it Azure Data Lake Storage Gen2 (real directories, POSIX ACLs). It has to be chosen at creation.
• Performance tier (Standard HDD-backed, Premium SSD-backed) and redundancy are chosen at creation; redundancy can be changed later (see below). Region can’t be changed.
• Services: Blob (objects), Azure Files (SMB/NFS shares), Queue (messages), Table (NoSQL key/attribute).
• Blob types: block (files, media), append (logs), page (VM disks, 512-byte pages).

az storage account create -n stcontoso001 -g rg-st -l westeurope --sku Standard_GRS --kind StorageV2 --min-tls-version TLS1_2 --allow-blob-public-access false

New-AzStorageAccount -ResourceGroupName rg-st -Name stcontoso001 -Location westeurope -SkuName Standard_GRS -Kind StorageV2

Redundancy

• Durability: LRS 11 nines, ZRS 12, geo options 16.
• The secondary Region copy is asynchronous (some data loss possible, tracked by last sync time). Zone redundancy is synchronous.
• Secondary endpoint: name-secondary.blob.core.windows.net.
• Customer-managed failover switches the secondary to become primary; the account becomes LRS in the new region and you re-enable geo-redundancy afterwards.
• Changing redundancy: update the SKU (az storage account update --sku Standard_ZRS). Some conversions (for example LRS to ZRS, or involving different regions and zones) need a live migration request or a manual copy; conversions between ZRS and GRS aren’t a single step.
• Premium accounts support LRS and ZRS only.
• Cheapest option meeting “survive a zone failure in one Region” is ZRS. “Survive a regional disaster, read from the secondary” is RA-GRS or RA-GZRS.

Access to storage

There are five ways to authorise requests. Know the trade-offs.

• Set “Allow storage account key access” to disabled to force Entra auth. Set “Allow blob anonymous access” to disabled to prevent public containers.
• Key rotation: two keys let you move apps to key2, then regenerate key1 with no downtime. A key expiration policy reminds you when to rotate (it doesn’t rotate automatically). Store keys in Key Vault.

SAS tokens

• A SAS contains permissions (r, w, d, l and so on), start and expiry, allowed IPs, allowed protocols (HTTPS only) and signed resource.
• An ad hoc SAS can’t be revoked individually except by regenerating the account key that signed it (which kills every SAS from that key). A SAS tied to a stored access policy is revoked by deleting or editing the policy.
• Stored access policy: defined on a container, file share, queue or table (up to 5 per resource). It holds start, expiry and permissions. A service SAS references it by identifier. Account SAS and user delegation SAS can’t use stored policies.

az storage container policy create --container-name data --name readonly --permissions r --expiry 2027-01-01 --account-name stcontoso001
az storage blob generate-sas --container-name data --name f.txt --policy-name readonly --account-name stcontoso001
az storage container generate-sas --name data --permissions r --expiry 2026-12-31T00:00Z --https-only --as-user --auth-mode login --account-name stcontoso001

(--as-user --auth-mode login produces the user delegation SAS.)

Firewalls and virtual networks

• By default a storage account accepts traffic from all networks on its public endpoint. Setting Selected networks (default action Deny) allows only:
  • Virtual network rules: subnets with the Microsoft.Storage service endpoint enabled.
  • IP rules: public IPv4 ranges in CIDR. Private address ranges (10.x, 172.16-31.x, 192.168.x) can’t be used in IP rules.
  • Resource instance rules for specific Azure resources (by managed identity).
  • Exceptions: Allow trusted Microsoft services (for example Azure Backup, Event Grid, Monitor logging) and read access to logs and metrics.
• Private endpoint: gives the account a private IP in your VNet (one per sub-resource: blob, file, queue, table, dfs, web). Needs a privatelink DNS zone (privatelink.blob.core.windows.net) so the normal name resolves to the private IP. You can then disable public access entirely.
• Service endpoints keep using the public IP of the account but source traffic from the subnet identity; private endpoints use a private IP. Private endpoints work from on-premises over VPN or ExpressRoute; service endpoints don’t.
• Firewall rules apply to all protocols (blob, file…) and can take up to about a minute to take effect. A client in the same region as the account that uses a public IP via an Azure service may be blocked unless covered by an exception.

az storage account update -n stcontoso001 -g rg-st --default-action Deny
az storage account network-rule add -n stcontoso001 -g rg-st --vnet-name vnet1 --subnet snet1
az storage account network-rule add -n stcontoso001 -g rg-st --ip-address 203.0.113.0/24

Identity-based access for Azure Files

SMB access using a user’s identity (instead of the storage key) works with three directory sources:

1. On-premises AD DS (domain-joined clients, synced to Entra ID with Entra Connect).
2. Microsoft Entra Domain Services (managed domain).
3. Microsoft Entra Kerberos for hybrid identities (Entra-joined or hybrid-joined clients, no line of sight to a domain controller required).

• Two layers of permissions: share-level via RBAC roles (Storage File Data SMB Share Reader, Contributor, Elevated Contributor, which also lets you change NTFS ACLs) and file/folder level via standard NTFS ACLs (set with icacls or File Explorer).
• Clients connect over TCP 445. Many ISPs block it; use VPN, ExpressRoute or private endpoint. SMB 3.x provides encryption in transit.
• Enable identity-based auth on the storage account first, then give share-level roles. Cloud-only Entra users aren’t supported with Kerberos auth.

Encryption

• All data is encrypted at rest with 256-bit AES (SSE), always on, and can’t be turned off. Default keys are Microsoft-managed.
• Customer-managed keys (CMK) live in Azure Key Vault or Managed HSM. The vault needs soft delete and purge protection, and the account uses a managed identity to access the key. Key can be rotated; use automatic key version updates.
• Customer-provided keys can be sent per blob request (Blob only).
• Infrastructure encryption gives a second layer with a different key and algorithm. It must be enabled at account creation.
• Encryption scopes let containers or blobs use different keys inside one account.
• Secure transfer required forces HTTPS/SMB encryption. Set the minimum TLS version to 1.2.

Object replication

• Asynchronous copy of block blobs between a source and destination container, which can be in different accounts, Regions or subscriptions.
• Prerequisites: blob versioning enabled on both accounts, change feed enabled on the source. Not supported for accounts with hierarchical namespace.
• A replication policy has rules (source container, destination container, optional prefix filters, minimum creation time). Rules are one-way. Archived blobs aren’t replicated.
• Use for lower read latency in other regions, compute near the data, data distribution. It is not a backup: it copies new and changed blobs, so pair it with versioning and soft delete for recovery.

Azure Storage Explorer and AzCopy

• Storage Explorer is a GUI (Windows, macOS, Linux) for blobs, files, queues, tables and Data Lake. Sign in with Entra, a connection string, an account key, or a SAS URL.
• AzCopy is a command-line copy tool, optimised for throughput and supports server-to-server copy.

azcopy login
azcopy copy "C:\data" "https://stcontoso001.blob.core.windows.net/data" --recursive
azcopy copy "https://src.blob.core.windows.net/c?<SAS>" "https://dst.blob.core.windows.net/c?<SAS>" --recursive
azcopy sync "./local" "https://stcontoso001.blob.core.windows.net/data" --recursive
azcopy remove "https://stcontoso001.blob.core.windows.net/data/old?<SAS>" --recursive

• copy copies everything matched; sync only transfers differences (one direction) and can delete extras with --delete-destination. Authenticate with azcopy login (needs a Storage Blob Data role) or a SAS on the URL. Account key auth isn’t supported.
• For huge offline moves, use Azure Data Box; Azure Import/Export for disks.

Blob storage

• Structure: account > container > blob. Container names are lowercase 3-63 characters. Public access levels: Private, Blob (anonymous read of blobs), Container (anonymous read and list).
• Tiers:

• The account default access tier can be Hot or Cool only. Archive is set per blob. Deleting or moving a blob out early incurs an early deletion charge.
• Archive rehydration: change the tier to Hot/Cool/Cold (Set Blob Tier) or copy the blob to an online tier. Standard priority can take up to 15 hours; high priority can be under 1 hour for blobs under 10 GB, at higher cost. You can’t read an archived blob.
• Premium block blob accounts don’t use tiers.

Lifecycle management

• Policy of rules at account level (JSON): filters (blobTypes, prefixMatch, blob index tags) and actions: tierToCool, tierToCold, tierToArchive, delete, based on days since last modification, creation, or last access (needs last access time tracking), applied to base blobs, snapshots and versions.
• Runs once a day; changes can take 24 hours to start. Rules are case-sensitive.

{"rules":[{"name":"age","enabled":true,"type":"Lifecycle","definition":{
 "filters":{"blobTypes":["blockBlob"],"prefixMatch":["logs/"]},
 "actions":{"baseBlob":{"tierToCool":{"daysAfterModificationGreaterThan":30},
                       "tierToArchive":{"daysAfterModificationGreaterThan":180},
                       "delete":{"daysAfterModificationGreaterThan":730}}}}}]}

Versioning, snapshots and soft delete

• Soft delete protects against accidental deletion; versioning against overwrite. Versions accumulate and cost storage, so pair with lifecycle rules.
• Azure Backup for blobs (operational backup) uses a Backup vault.

Azure Files

• Fully managed file shares over SMB (2.1, 3.x) and NFS 4.1 (premium, not both on one share). Share quotas up to 100 TiB (standard large file shares).
• Tiers (standard, in a GPv2 account): Transaction optimized, Hot, Cool. Premium (SSD, FileStorage account) for low latency. Billing on premium is by provisioned size.
• Share snapshots: read-only point-in-time copies of the share (up to 200 per share), incremental; restore individual files from the Previous Versions tab. Snapshots must be deleted before the share is deleted.
• Soft delete for file shares: enabled by default for new accounts, 7 days retention by default; recovers a deleted share (not individual files).
• Azure File Sync extends a share to Windows Server with cloud tiering. Azure Backup can protect file shares through a Recovery Services vault.
• Mount (Windows):

$cred = "/user:Azure\stcontoso001 /pass:<key>"
net use Z: \\stcontoso001.file.core.windows.net\share1 $cred

sudo mount -t cifs //stcontoso001.file.core.windows.net/share1 /mnt/share -o username=stcontoso001,password=<key>,serverino,vers=3.1.1

az storage share-rm create --storage-account stcontoso001 --name share1 --quota 100 --access-tier TransactionOptimized