Storage Accounts
An Azure Storage Account is the foundational container for all Azure storage services — Blobs, Files, Queues, and Tables. Everything storage-related starts here.
Simple Explanation
A Storage Account is like a locker rental facility. The account is the building; inside you choose lockers (Blob containers, File shares, Queues, Tables). Different locker types serve different storage needs.
Storage Services Within an Account
| Service | Purpose | Use When |
|---|---|---|
| Blob Storage | Unstructured object storage | Images, videos, backups, logs, static web assets |
| Azure Files | Managed SMB/NFS file shares | Legacy app file shares, lift-and-shift |
| Queue Storage | Message queue for async processing | Decouple app components, background jobs |
| Table Storage | NoSQL key-value store | Simple structured data, cheap non-relational storage |
Performance Tiers
| Tier | Purpose | Backed by |
|---|---|---|
| Standard | General purpose, balanced cost | Magnetic (HDD) |
| Premium | Low-latency, I/O-intensive workloads | SSD |
Redundancy Options
| Redundancy | What it means | Use When |
|---|---|---|
| LRS (Locally Redundant) | 3 copies in one datacenter | Dev/test; cost-sensitive workloads |
| ZRS (Zone Redundant) | 3 copies across 3 availability zones | High availability in one region |
| GRS (Geo Redundant) | LRS + async copy to paired region | Disaster recovery (secondary read not enabled) |
| RA-GRS (Read-Access Geo) | GRS + read access to secondary region | DR + need to read from secondary |
| GZRS / RA-GZRS | ZRS + geo replication | Maximum availability + DR |
Storage account names must be globally unique, 3–24 characters, lowercase letters and numbers only. Plan your naming convention early — you cannot rename an account after creation.
Visual Representation
Commands
# Create a standard storage account (LRS) az storage account create \ --name mystorageaccountweb \ --resource-group rg-storage \ --location eastus \ --sku Standard_LRS \ --kind StorageV2 # Create with ZRS (zone-redundant) az storage account create \ --name mystorageacctzrs \ --resource-group rg-storage \ --location eastus \ --sku Standard_ZRS \ --kind StorageV2 # Get connection string az storage account show-connection-string \ --resource-group rg-storage \ --name mystorageaccountweb \ --output tsv # List storage accounts az storage account list --resource-group rg-storage --output table # Enable soft delete (recovery window = 7 days) az storage account blob-service-properties update \ --account-name mystorageaccountweb \ --resource-group rg-storage \ --enable-delete-retention true \ --delete-retention-days 7 # Add firewall rule (restrict to specific IP) az storage account network-rule add \ --resource-group rg-storage \ --account-name mystorageaccountweb \ --ip-address 203.0.113.10
Hands-on
- Create a Standard_LRS storage account in your preferred region.
- Browse the Storage account in Portal: find Blob, Files, Queues, Tables.
- Enable soft delete for blobs (7-day retention window).
- Add a firewall rule to restrict access to your IP only.
- Retrieve the connection string and export it as an environment variable.
Debugging Scenario
Issue: App cannot connect to storage account from a VM.
- Check if storage firewall is enabled and the VM's IP or VNet is not whitelisted.
- Verify NSG outbound rules allow port 443 to Azure Storage (service tag
Storage). - Check that the connection string or SAS token used is not expired.
- Use Storage Activity Log to see recent access denials.
Interview Questions
Beginner
A top-level Azure resource that groups Blob, File, Queue, and Table storage services. You configure redundancy and performance here; all child services inherit these settings.
LRS stores 3 copies in one datacenter. GRS adds an asynchronous copy to a paired region for disaster recovery, at ~2x the cost of LRS.
Scenario-based
Use GRS or RA-GRS redundancy. GRS replicates data to a paired secondary region. RA-GRS allows reading from the secondary endpoint during primary region failure.
Summary
Storage Accounts are the foundation of Azure Storage. Choose Standard for general workloads and Premium for high-IOPS scenarios. Always select the right redundancy tier (LRS for dev, ZRS/GRS for production) to match your availability and disaster recovery requirements.