Azure Storage Accounts

An Azure Storage Account is the foundational resource that gives you access to Azure's core storage services: Blob Storage (object store), Azure Files (managed file shares), Queue Storage (message queues), Table Storage (NoSQL key-value store), and Azure Data Lake Storage Gen2 (hierarchical namespace for analytics). A single storage account can host all these services simultaneously and provides a unique namespace in Azure — the account name becomes part of the URL for every object it contains.

Azure offers several storage account types: Standard general-purpose v2 (GPv2) — the recommended type for most scenarios, supports all storage services and redundancy options at standard performance. Premium block blobs — SSD-backed storage for scenarios requiring very low latency for Blob Storage operations. Premium file shares — SSD-backed Azure Files shares for high-IOPS workloads like databases or home directories. Premium page blobs — SSD storage for Azure VM OS and data disks (Managed Disks use this under the hood). For most use cases, start with a Standard GPv2 account.

Azure Storage replicates your data automatically to protect against hardware failures. The four redundancy options are: LRS (Locally Redundant Storage) — three synchronous copies within a single data centre. ZRS (Zone-Redundant Storage) — three synchronous copies across three availability zones in one region. GRS (Geo-Redundant Storage) — LRS in primary + async replication to a secondary region (LRS). GZRS (Geo-Zone-Redundant Storage) — ZRS in primary + async replication to a secondary region. More redundancy means higher durability and cost.

Choose your redundancy tier based on your RTO, RPO, and budget requirements: LRS — cheapest, 11 nines durability, no protection against data centre failure. Use for dev/test or data you can recreate. ZRS — protects against data centre failure, good for production data in a single region. GRS/GZRS — protects against an entire Azure region going offline; data is replicated asynchronously to the paired region. For critical business data that must survive a regional disaster, GRS or GZRS is the appropriate choice despite the added cost.

Azure Storage offers two performance tiers: Standard — backed by hard disk drives (HDD), suitable for most workloads at lower cost per GB. Premium — backed by solid-state drives (SSD), designed for latency-sensitive scenarios requiring single-digit millisecond I/O. Standard storage is billed per GB stored; Premium is more expensive per GB but delivers consistent, predictable performance. For web assets, backups, logs, and archiving, Standard is appropriate. For VMs with I/O-intensive databases or file shares accessed by desktop users, Premium is the better choice.

Storage account names must be globally unique across all of Azure (because they form part of a public DNS name like mystorageacct.blob.core.windows.net). Names must be 3-24 characters long and contain only lowercase letters and numbers — no hyphens, underscores, or uppercase. Since names must be globally unique, common words and brand names are already taken. A good practice is to combine a company prefix, environment (prod/dev), and purpose (store/media), then append a random suffix if needed: e.g., contosoprodmedia7x2.

Each storage account has two 512-bit access keys that grant full administrative access to everything in the account. These keys should be treated like passwords — stored in Azure Key Vault rather than in code or configuration files. Azure generates two keys so you can perform key rotation without downtime: update your applications to use Key 2, then regenerate Key 1, then switch applications to Key 1, then regenerate Key 2. For finer-grained access control, use Shared Access Signatures (SAS) or Azure RBAC instead of sharing the master keys.

Azure RBAC (Role-Based Access Control) is the recommended way to authorise access to storage data without sharing keys. Assign the Storage Blob Data Reader role to allow read-only access to Blob Storage, or Storage Blob Data Contributor for read/write. These roles are assigned to Entra ID users, groups, or managed identities, so access is tied to an authenticated identity rather than a shared secret. RBAC authorisation for storage is available for Blob, Queue, and Table services (not File — that uses SMB/NFS protocols with their own access controls).

By default, storage accounts accept connections from any network. For production security, restrict access using the Storage Account Firewall: allow only specific public IP ranges or virtual network subnets. For the highest security, disable public internet access entirely and use a Private Endpoint — a private IP address within your VNet that routes traffic to the storage account through Azure's private backbone, never exposing it on the public internet. Private Endpoints are the recommended approach for storage accounts containing sensitive or regulated data.

Azure Storage provides built-in data protection features to guard against accidental deletion: Blob soft delete — deleted blobs and versions are retained for a configurable period (1-365 days) and can be recovered without restoring from backup. Blob versioning — every overwrite creates a new version, so you can restore any previous version of a blob. Container soft delete — accidentally deleted containers can be recovered. These features are disabled by default and should be enabled for production storage accounts that hold important data not backed up elsewhere.

Azure Monitor automatically collects metrics for every storage account: total capacity used, number of transactions, ingress and egress bytes, and end-to-end latency. You can view these in the Azure portal's Insights blade for your storage account, which provides pre-built charts for capacity, availability, and performance. For detailed access auditing, enable Storage Diagnostic Logs to record every read, write, and delete operation to a log destination — useful for security investigations and compliance reporting.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: a storage account is the root resource for all Azure storage services, identified by a globally unique name, redundancy options — LRS, ZRS, GRS, GZRS — provide increasing levels of durability at increasing cost, and access should be controlled via RBAC and private endpoints rather than sharing master access keys. Next up we dive into Blob Storage — Azure's object store for unstructured data.