Storage Account Fundamentals
Lecture 1: Create Storage AccountLecture 2: Redundant StorageLecture 3: Advanced OptionsLecture 8: Final Creation~1/5 of AZ-104 ExamOverview
Storage accounts are one of three fundamental IaaS services in Azure, alongside Virtual Machines and Networking. Approximately one-fifth of the AZ-104 exam covers storage topics, making this one of the highest-weighted sections on the exam.
Exam Tip
Storage is disproportionately represented on the AZ-104 exam. Expect questions on redundancy tiers, access control (keys vs Entra ID), secure transfer requirements, and naming constraints. Know the differences between LRS, ZRS, GRS, RA-GRS, and GZRS cold.
Creating a Storage Account
Prerequisites
To create a storage account you need:
- An active Azure Subscription
- A Resource Group to place the storage account in
- A globally unique name -- unique across ALL Azure storage accounts (millions exist)
DANGER
Storage account names must be globally unique across the entire Azure platform. Due to namespace saturation across millions of existing accounts, choosing a descriptive yet available name requires careful planning. See Naming Conventions below.
Region Selection
Region selection is a critical decision that affects cost, compliance, features, and performance.
| Factor | Details |
|---|---|
| Pricing varies by region | East US = 2.1 cents/GB, UK = 1.9 cents/GB -- prices differ across regions |
| Data residency | Some countries require data to remain within national borders by law |
| Feature availability | Certain features are only available in specific regions |
| Latency | Place storage in the same region as the apps and VMs accessing it |
Best Practice
Always place your storage account in the same region as the applications and virtual machines that will consume the data. This minimizes latency and avoids cross-region egress charges. Before selecting a region, verify data residency laws apply to your workload.
Service Types
Azure Storage accounts support several service types:
| Service | Description |
|---|---|
| Blob Storage | Most common and the default. Object storage for unstructured data. |
| Data Lake Storage | Designed for big data workloads and extremely large datasets. |
| Files | Fully managed file shares accessible via SMB and NFS protocols. |
| Tables | NoSQL key-value store for semi-structured data. |
| Queues | Message queuing for decoupled application communication. |
Performance Tiers
| Tier | Use Case | Per-GB Monthly Cost | Per-10K Reads | Notes |
|---|---|---|---|---|
| Standard | Normal usage, default tier | Lower | ~0.6 cents | Suitable for most workloads |
| Premium | Low-latency scenarios | Much higher | ~0.2 cents | Only economical if the same file is accessed dozens of times per second, 24/7 |
INFO
The Premium tier has a much higher per-GB monthly charge but a lower per-access charge (0.2 cents vs 0.6 cents per 10,000 reads). This makes it economical only when the same files are accessed dozens of times per second around the clock. For frequently accessed data that does not require the Premium storage model, consider Azure Cache for Redis as a caching layer instead.
Storage Redundancy
Microsoft automatically keeps multiple copies of your data at no extra cost for the base redundancy level (LRS). There are four main tiers with increasing cost and protection, plus combination tiers.
Why Three Copies?
Azure stores a minimum of three copies of your data. This protects against a single drive failure AND the statistically unlikely scenario of two simultaneous drive failures. Three copies means two drives would have to fail at the same time before any data loss occurs.
Redundancy Options
| Type | Copies | Location | Cost (East US) | Protection Level |
|---|---|---|---|---|
| LRS (Locally-Redundant Storage) | 3 copies | Single data center | 2.10 cents/GB | Drive failure |
| ZRS (Zone-Redundant Storage) | 3 copies across 3 DCs | 3 different buildings within the region | 2.60 cents/GB | Building/power outage |
| GRS (Geo-Redundant Storage) | 6 copies (3 per region) | Two paired regions | 4.60 cents/GB | Regional disaster |
| RA-GRS (Read-Access GRS) | Same as GRS + read URL | Two regions with secondary read URL | 5.90 cents/GB | Regional disaster + read failover |
| GZRS (Geo-Zone-Redundant Storage) | 6 copies across zones in 2 regions | Two regions, 3 zones each | Highest | Maximum protection |
Exam Tip
Know the exact difference between GRS and RA-GRS. Both replicate 6 copies across two paired regions. The difference is that RA-GRS provides a secondary read-only URL so applications can read data from the secondary region during an outage. This costs approximately 1.5 cents/GB more than standard GRS.
Regional Availability Limitations
Not all redundancy options are available in every Azure region:
- Newer regions (e.g., East US) have all redundancy options available
- Older regions (e.g., North Central US) may only offer LRS and GRS
- Some regions (e.g., Qatar) only offer LRS and ZRS
Always verify availability in your target region before committing to a redundancy strategy.
GRS Read Access
- The secondary region provides a read-only URL for your storage account
- Costs extra (~1.5 cents/GB upgrade from GRS to RA-GRS)
- Useful for disaster recovery read scenarios where applications must continue reading data during a primary region outage
Redundancy Hierarchy
Redundancy Architecture
direction: right
title: Azure Storage Redundancy Models {
style.font-size: 28
}
lrs: LRS -- Single Data Center {
dc1: Data Center 1 {
style.fill: "#e8f4f8"
copy1: Copy 1 {style.fill: "#4a9"}
copy2: Copy 2 {style.fill: "#4a9"}
copy3: Copy 3 {style.fill: "#4a9"}
}
}
zrs: ZRS -- Three Data Centers {
dc1: Data Center 1 {
style.fill: "#e8f4f8"
copy1: Copy 1 {style.fill: "#3a8"}
}
dc2: Data Center 2 {
style.fill: "#e8f4f8"
copy2: Copy 2 {style.fill: "#3a8"}
}
dc3: Data Center 3 {
style.fill: "#e8f4f8"
copy3: Copy 3 {style.fill: "#3a8"}
}
}
grs: GRS -- Two Paired Regions {
primary: Primary Region {
style.fill: "#e8eef8"
copy1: Copy 1 {style.fill: "#38a"}
copy2: Copy 2 {style.fill: "#38a"}
copy3: Copy 3 {style.fill: "#38a"}
}
secondary: Secondary Region {
style.fill: "#f8e8e8"
copy4: Copy 4 {style.fill: "#a63"}
copy5: Copy 5 {style.fill: "#a63"}
copy6: Copy 6 {style.fill: "#a63"}
}
primary -> secondary: Async Replication
}Durability vs Availability
These are fundamentally different concepts often conflated. Azure has never lost customer data -- even LRS has 11 nines of durability.
| Concept | Definition | Measurement | Key Insight |
|---|---|---|---|
| Durability | Probability data is preserved over time | 11 nines (LRS) to 16 nines (GRS/GZRS) | A front-end outage does NOT affect durability -- data stays safe on disk |
| Availability | Ability to interact with and access data | SLA-defined uptime (99.9% - 99.99%) | Network/front-end issues affect availability but data is intact |
Exam Tip
The exam may present scenarios where a region has an outage and ask about data safety. Durability (data safety) is separate from availability. Even during an availability zone failure with LRS, the surviving copies retain data integrity. Azure Storage has never confirmed a customer data loss event.
Customer-Managed Failover
Azure has NEVER executed a full regional failover for storage. But customers can initiate failover themselves for smaller outages affecting their specific service.
| Type | Status | Behavior | GRS State After | Data Risk |
|---|---|---|---|---|
| Unplanned Failover | GA | Secondary becomes primary | Demoted to LRS -- must re-enable GRS manually | Data after "last sync time" may be lost |
| Planned Failover | Preview | Swaps primary and secondary cleanly | GRS preserved | No data loss (graceful swap) |
The storage account exposes a "last sync time" property. Because geo-replication is asynchronous, writes after this timestamp have NOT reached the secondary and will be lost in unplanned failover.
DANGER
Unplanned failover demotes your account to LRS. You must manually re-enable GRS afterward, which triggers a full re-sync to the new secondary region. This takes time and incurs egress charges.
Exam Tip
Know: Unplanned failover = LRS after completion. Planned failover (preview) = GRS preserved. "Last sync time" determines potential data loss window.
# Check last sync time
az storage account show --name myaccount --resource-group myRG --query "geoReplicationStats" --output json
# Initiate failover (unplanned)
az storage account failover --name myaccount --resource-group myRGAzure Region Pairs
Region Pair Reference
Azure regions are paired for geo-redundant replication. Key pairs include:
| Primary Region | Paired Region |
|---|---|
| East US | West US |
| East US 2 | Central US |
| UK South | UK West |
| North Europe | West Europe |
| Southeast Asia | East Asia |
| Australia East | Australia Southeast |
| Canada Central | Canada East |
| Japan East | Japan West |
| Germany West Central | Germany North |
| Brazil South | South Central US |
When you select GRS, RA-GRS, or GZRS redundancy, Azure automatically replicates to the paired region. You cannot choose a custom secondary region.
Advanced Options
Security Settings
Require Secure Transfer (REST API)
- Enabled by default -- forces HTTPS for all REST API operations
- Disables unencrypted HTTP access
- Should remain enabled unless you have a specific, justified need for HTTP
DANGER
Disabling secure transfer allows unencrypted HTTP connections to your storage account. This exposes data in transit to interception. Only disable this if you have a legacy application that absolutely cannot use HTTPS, and plan a migration path immediately.
Allow Anonymous (Public) Access
- Disabled by default -- requires authentication for all access
- Enabling is a high security risk
- Only enable for truly public content: images, MP4 videos, JavaScript files
- Historically, publicly exposed storage buckets (across all cloud providers) are constantly scanned by automated tools looking for sensitive data
Exam Tip
Know that anonymous access is disabled by default and that enabling it is a security risk. The exam may test scenarios where you must determine the correct access level for different types of content (public website assets vs. confidential documents).
Authentication Methods
Azure storage accounts support two authentication methods. These are not mutually exclusive -- both can be enabled simultaneously.
| Method | Description | Security Level | Use Case |
|---|---|---|---|
| Storage Account Key (Claims-based) | Enabled by default. A long, impossible-to-guess string. Grants full access if compromised. | Lower -- all-or-nothing access | Legacy application support |
| Microsoft Entra ID (RBAC) | Can be enabled alongside keys. Applications must register with Entra ID. | Higher -- fine-grained, role-based | Modern, Entra-aware applications |
Best Practice
Prefer Microsoft Entra ID authentication with RBAC over storage account keys whenever possible. Entra ID provides fine-grained access control, audit logging, and conditional access policies. Storage account keys grant full access to the entire account and should be rotated regularly if used.
Protocol Security
- Minimum TLS version: Default is TLS 1.2 (recommended)
- TLS 1.0 and TLS 1.1 are considered insecure and should not be used
- Enforcing TLS 1.2 ensures all client connections use modern encryption
Data Lake Storage Gen2
| Feature | Details |
|---|---|
| Hierarchical namespace | Real files and folders (unlike the flat container-based blob model) |
| Big data workloads | Purpose-built for analytics at scale |
| Protocol support | Required for SFTP and NFS access |
| Access control | Separate limits and POSIX-compliant ACL policies |
INFO
Enabling the hierarchical namespace converts the storage account to Data Lake Storage Gen2. This is a one-way, irreversible decision. The storage model changes from flat container-based blobs to a true file system with directories. This is required if you need SFTP or NFS protocol access.
Final Creation
Creation Process
- Navigate to the Review and Create tab -- Azure validates all settings
- Optionally save as ARM template for Infrastructure as Code automation
- Settings are passed through Azure Resource Manager for deployment
- Typical creation time: approximately 1 minute 20 seconds
Post-Creation Overview
After deployment completes, the storage account overview displays:
| Property | Example Value |
|---|---|
| Provisioning state | Succeeded |
| Account type | General Purpose v2 |
| Redundancy | Locally-redundant storage (LRS) |
| Performance tier | Standard |
| Region | East US |
TIP
After creation, you can export the ARM template from the portal by navigating to the storage account > Automation > Export template. This is invaluable for recreating the same configuration in other environments or for version-controlling your infrastructure.
Naming Conventions
Storage account names have strict constraints:
| Rule | Requirement |
|---|---|
| Length | 3-24 characters |
| Allowed characters | Lowercase letters and numbers only |
| Disallowed characters | No hyphens, underscores, or uppercase letters |
| Uniqueness | Must be globally unique across all of Azure |
Recommended Naming Pattern
Use the pattern: {company}{env}{region}{purpose}{random}
Examples:
contosoprodeus2stor01-- Contoso, production, East US 2, storage, instance 01myappdevweu1data03-- MyApp, development, West Europe, data, instance 03acmestagewus1blob42-- Acme, staging, West US, blob, instance 42
This pattern provides organizational clarity while staying within the character and format constraints.
CLI and PowerShell Reference
Create a Storage Account
# Create a storage account with Standard LRS
az storage account create \
--name mystorageaccount2024 \
--resource-group myResourceGroup \
--location eastus \
--sku Standard_LRS \
--kind StorageV2 \
--access-tier Hot
# List all storage accounts in table format
az storage account list --output table
# Show properties of a specific account
az storage account show \
--name mystorageaccount2024 \
--resource-group myResourceGroup# Create a storage account with Standard LRS
New-AzStorageAccount `
-ResourceGroupName "myResourceGroup" `
-Name "mystorageaccount2024" `
-Location "eastus" `
-SkuName "Standard_LRS" `
-Kind "StorageV2" `
-AccessTier "Hot"
# List all storage accounts
Get-AzStorageAccount | Format-Table StorageAccountName, Location, Kind
# Show properties of a specific account
Get-AzStorageAccount `
-ResourceGroupName "myResourceGroup" `
-Name "mystorageaccount2024"SKU Values for Redundancy Tiers
# LRS
az storage account create --sku Standard_LRS ...
# ZRS
az storage account create --sku Standard_ZRS ...
# GRS
az storage account create --sku Standard_GRS ...
# RA-GRS
az storage account create --sku Standard_RAGRS ...
# GZRS
az storage account create --sku Standard_GZRS ...
# RA-GZRS
az storage account create --sku Standard_RAGZRS ...# LRS
New-AzStorageAccount -SkuName "Standard_LRS" ...
# ZRS
New-AzStorageAccount -SkuName "Standard_ZRS" ...
# GRS
New-AzStorageAccount -SkuName "Standard_GRS" ...
# RA-GRS
New-AzStorageAccount -SkuName "Standard_RAGRS" ...
# GZRS
New-AzStorageAccount -SkuName "Standard_GZRS" ...
# RA-GZRS
New-AzStorageAccount -SkuName "Standard_RAGZRS" ...ARM Template
ARM Template -- Storage Account
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountName": {
"type": "string",
"minLength": 3,
"maxLength": 24,
"metadata": {
"description": "Globally unique storage account name (lowercase and numbers only)"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for the storage account"
}
},
"skuName": {
"type": "string",
"defaultValue": "Standard_LRS",
"allowedValues": [
"Standard_LRS",
"Standard_ZRS",
"Standard_GRS",
"Standard_RAGRS",
"Standard_GZRS",
"Standard_RAGZRS",
"Premium_LRS",
"Premium_ZRS"
],
"metadata": {
"description": "Storage account SKU (redundancy tier)"
}
}
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2023-01-01",
"name": "[parameters('storageAccountName')]",
"location": "[parameters('location')]",
"kind": "StorageV2",
"sku": {
"name": "[parameters('skuName')]"
},
"properties": {
"accessTier": "Hot",
"supportsHttpsTrafficOnly": true,
"minimumTlsVersion": "TLS1_2",
"allowBlobPublicAccess": false
}
}
],
"outputs": {
"storageAccountId": {
"type": "string",
"value": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
},
"storageAccountName": {
"type": "string",
"value": "[parameters('storageAccountName')]"
}
}
}MS Learn References
- Storage account overview
- Azure Storage redundancy
- Create a storage account
- Introduction to Azure Data Lake Storage Gen2
- Azure Storage disaster recovery planning and failover
- Initiate a storage account failover
Lab Exercises
Prerequisites
Ensure you have an active Azure subscription (a free trial works) and the Azure CLI installed locally or access to Azure Cloud Shell.
Lab 1: Create a Storage Account via Azure Portal
- Navigate to the Azure Portal
- Click Create a resource > search for Storage account
- Configure the Basics tab:
- Select your subscription and resource group (or create a new one)
- Enter a globally unique name following the naming convention
- Select East US as the region
- Choose Standard performance
- Select Locally-redundant storage (LRS) for redundancy
- Review the Advanced tab:
- Verify Require secure transfer for REST API operations is enabled
- Verify Allow enabling anonymous access on individual containers is disabled
- Note the Minimum TLS version is set to 1.2
- Click Review + Create, then Create
- Wait for deployment to complete (~1 minute 20 seconds)
- Navigate to the resource and review the Overview blade
Lab 2: Create a Storage Account via Azure CLI
# Create a resource group
az group create --name lab-storage-rg --location eastus
# Create the storage account
az storage account create \
--name labstor$(date +%s | tail -c 8) \
--resource-group lab-storage-rg \
--location eastus \
--sku Standard_LRS \
--kind StorageV2 \
--access-tier Hot \
--https-only true \
--min-tls-version TLS1_2
# Verify the account was created
az storage account show \
--name <your-account-name> \
--resource-group lab-storage-rg \
--query "{Name:name, Location:location, SKU:sku.name, Kind:kind}" \
--output tableLab 3: Compare LRS vs GRS Pricing
- Open the Azure Pricing Calculator
- Add a Storage Accounts resource
- Configure for East US, Block Blob Storage, Standard tier
- Set storage capacity to 100 GB
- Compare the monthly cost with:
- LRS redundancy
- GRS redundancy
- RA-GRS redundancy
- Note the cost multiplier between each tier
Lab 4: Export and Review the ARM Template
- In the Azure Portal, navigate to the storage account created in Lab 1
- In the left menu, go to Automation > Export template
- Review the generated ARM template JSON
- Click Download to save the template locally
- Compare the downloaded template with the ARM template example in this page
- Identify additional properties Azure automatically populated
Lab 5: Explore Advanced Options
- Create a new storage account (or modify your existing one)
- On the Advanced tab, explore each setting:
- Toggle Require secure transfer and understand the impact
- Review the Allow anonymous access warning
- Check the Default to Microsoft Entra authorization option
- Note the Minimum TLS version dropdown options
- Toggle Enable hierarchical namespace to understand Data Lake Gen2
- Do not deploy -- simply review the options and cancel
Clean Up
After completing the labs, delete the resource group to avoid ongoing charges:
az group delete --name lab-storage-rg --yes --no-wait