This chapter covers storage account design decisions for Azure, a critical topic for the AZ-305 exam. Understanding how to choose the right storage account kind, performance tier, replication strategy, and access model directly impacts cost, performance, and availability. Approximately 15-20% of the exam questions touch on storage design, making this one of the highest-weighted domains. You will learn the precise differences between storage account types, when to use each replication option, and how to design for specific workload requirements.
Jump to a section
Think of Azure Storage as a massive public library system. The storage account is the library building itself, with a unique address (the endpoint URL). Inside, there are different sections: Blob storage is like the general book stacks for unstructured data (books, magazines), File storage is like a shared reference desk where staff can access files from any terminal, Queue storage is like a suggestion box where patrons drop requests and librarians process them in order, and Table storage is like a card catalog with structured records. Each section has its own access rules: you need a library card (access key) to enter, or you can get a temporary pass (SAS token) for limited access. The library also has different performance tiers: Standard is like a community library with moderate speed, Premium is like a research library with fast retrieval. Replication is like having multiple branches that share the same collection: LRS keeps one copy in the same branch, GRS keeps copies in a different city, and RA-GRS allows you to read from the remote branch even during a disaster. The library enforces rules on how many patrons can enter at once (scalability limits) and charges based on how many books are stored and how often they are checked out (cost model).
What is an Azure Storage Account and Why It Exists
An Azure Storage Account is a container that groups all Azure Storage data services together. It provides a unique namespace for your storage data, accessible from anywhere in the world over HTTP or HTTPS. The storage account contains four primary services: Blob Storage (for unstructured object data), File Storage (for SMB file shares), Queue Storage (for message queuing), and Table Storage (for NoSQL key-value storage). The storage account itself is not a data service but a management and billing boundary.
The reason storage accounts exist is to provide a unified access point, security boundary, and performance envelope. Each storage account has a unique endpoint in the format <accountname>.blob.core.windows.net, <accountname>.file.core.windows.net, etc. All data within a storage account shares the same replication settings, access keys, and firewall rules.
How Storage Accounts Work Internally
When you create a storage account, Azure assigns it a primary region (where the data is stored) and optionally a secondary region for geo-replication. The storage account is backed by a scale unit called a storage stamp – a cluster of storage nodes that provide the storage capacity and throughput. Each stamp can serve multiple storage accounts, but each storage account is assigned to a single primary stamp.
Data written to a storage account is first written to the primary stamp. Depending on the replication type, the data may be synchronously or asynchronously copied to other stamps within the same region (for LRS/ZRS) or to a secondary region (for GRS/RA-GRS). The storage account uses a partition key to distribute data across multiple nodes within the stamp for scalability.
Key Components, Values, Defaults, and Timers
Storage Account Kinds: There are three kinds: StorageV2 (general purpose v2), BlobStorage, and FileStorage. StorageV2 is the default and supports all services. BlobStorage is legacy (only blobs) and FileStorage is for premium file shares only. For AZ-305, know that StorageV2 is recommended for most scenarios.
Performance Tiers: Standard (uses magnetic disks) and Premium (uses SSDs). Premium is further divided into BlockBlobStorage (for block blobs), FileStorage (for files), and PageBlobStorage (for page blobs). Standard accounts have lower IOPS and throughput limits.
Replication Options: - LRS (Locally Redundant Storage): 3 synchronous copies within a single data center in the primary region. Default. Lowest cost. Not resilient to a data center failure. - ZRS (Zone-Redundant Storage): 3 synchronous copies across 2-3 availability zones within the primary region. Resilient to a zone failure. - GRS (Geo-Redundant Storage): LRS in primary region + asynchronous copy to a secondary region (LRS there). Resilient to a regional failure. - RA-GRS (Read-Access Geo-Redundant Storage): GRS plus the ability to read from the secondary region (even if no failover has occurred). - GZRS (Geo-Zone-Redundant Storage): ZRS in primary + asynchronous copy to secondary region. - RA-GZRS: GZRS with read access to secondary.
Default Replication: LRS. For production workloads requiring high availability, ZRS or GRS is recommended.
Failover: For GRS/RA-GRS, you can initiate a customer-managed failover to the secondary region. This changes the secondary to become the primary. The failover is one-way – you cannot fail back automatically. The RTO for a manual failover is typically 1 hour, but can be longer.
Access Tiers for Blob Storage: Hot (frequent access, higher storage cost, lower access cost), Cool (infrequent access, lower storage cost, higher access cost), Archive (offline, lowest storage cost, highest retrieval cost and latency). Default is Hot. Cool has a 30-day minimum storage duration; Archive has 180-day minimum.
Encryption: All data in Azure Storage is encrypted at rest using Storage Service Encryption (SSE) with Microsoft-managed keys by default. You can use customer-managed keys (CMK) in Azure Key Vault or infrastructure encryption for double encryption.
Network Access: By default, storage accounts accept connections from any network. You can restrict to specific virtual networks and IP addresses using firewall rules and service endpoints or private endpoints.
Configuration and Verification Commands
Using Azure CLI:
# Create a storage account
az storage account create \
--name mystorageaccount \
--resource-group myResourceGroup \
--location eastus \
--sku Standard_GRS \
--kind StorageV2 \
--access-tier Hot
# List storage accounts
az storage account list --resource-group myResourceGroup --output table
# Show replication
az storage account show --name mystorageaccount --resource-group myResourceGroup --query 'sku'Using PowerShell:
# Create a storage account
New-AzStorageAccount -ResourceGroupName myResourceGroup `
-Name mystorageaccount `
-Location eastus `
-SkuName Standard_GRS `
-Kind StorageV2 `
-AccessTier Hot
# Get storage account key
Get-AzStorageAccountKey -ResourceGroupName myResourceGroup -Name mystorageaccountHow It Interacts with Related Technologies
Storage accounts integrate with Azure Virtual Networks via service endpoints (which expose the storage account to a VNet) and private endpoints (which give the storage account a private IP in the VNet). They also work with Azure CDN for caching blob content, Azure Backup for backing up file shares and blobs, and Azure Site Recovery for replicating VMs using storage accounts. Azure Policy can enforce compliance rules on storage accounts, and Azure Monitor provides metrics and logs for storage operations.
Assess Workload Requirements
Begin by identifying the type of data: unstructured blobs, structured tables, file shares, or messages. Determine performance needs: IOPS and throughput. For high IOPS, choose Premium performance. For latency-sensitive workloads, Premium is required. Also consider access patterns: frequent vs. infrequent access determines the access tier (Hot, Cool, Archive). For example, a media streaming service needs Premium BlockBlobStorage with Hot tier, while archival backups can use Cool or Archive tier.
Choose Storage Account Kind
Select the appropriate kind: StorageV2 for general purpose (supports blobs, files, queues, tables), BlobStorage for legacy blob-only scenarios (not recommended for new deployments), or FileStorage for premium file shares only. For almost all scenarios, StorageV2 is the correct choice. This decision affects available features: for example, lifecycle management policies are only available on StorageV2 and BlobStorage.
Select Replication Strategy
Based on the required SLA and disaster recovery needs, choose replication: LRS for non-critical data (99.999999999% durability, 11 nines), ZRS for zone-resilient (same durability but across zones), GRS for regional failover (durability with async copy to paired region, RTO of 1 hour typically), RA-GRS for read access during normal operations from secondary. For maximum availability, GZRS combines ZRS and geo-replication. The SLA for read requests is 99.9% for LRS/ZRS, 99.99% for RA-GRS/RA-GZRS.
Configure Network Access
Decide on network security: allow all networks (default), restrict to specific IP addresses, or use virtual network service endpoints/private endpoints. Private endpoints provide the most secure access by giving the storage account a private IP in your VNet, eliminating exposure to the public internet. Service endpoints are simpler but still expose the storage account to the internet (though restricted to the VNet). For compliance, many enterprises require private endpoints.
Set Access Tier and Lifecycle Management
For blob storage, set the default access tier (Hot or Cool). Implement lifecycle management policies to automatically move blobs between tiers (e.g., move to Cool after 30 days, to Archive after 90 days) and delete old blobs. This optimizes cost. For example, a policy can be: 'if blob age > 30 days, move to Cool; if > 180 days, move to Archive; if > 365 days, delete'.
Enterprise Scenario 1: Media Streaming Platform
A company hosts a video-on-demand service. They store source videos (large files, accessed infrequently) and encoded renditions (frequently accessed). They use two storage accounts: one Premium BlockBlobStorage for the renditions to ensure low latency streaming, and one StorageV2 with Cool tier for the source files. Replication is ZRS for the premium account to tolerate zone failures, and LRS for the source account (acceptable because source files are backed up offline). They use Azure CDN to cache renditions at edge locations. Misconfiguration: initially they used Standard performance for renditions, causing buffering during peak hours. After switching to Premium, performance improved. They also set lifecycle policies to move old source files to Archive after 90 days, saving 50% on storage costs.
Enterprise Scenario 2: Financial Services Compliance
A bank needs to store transaction logs for 7 years. They use a StorageV2 account with RA-GRS replication to ensure read access to logs even during a regional outage (required by auditors). They use private endpoints to ensure logs never traverse the public internet. They implement a lifecycle policy to move logs to Cool after 30 days (infrequent access) and to Archive after 1 year. After 7 years, logs are deleted. The bank also enables soft delete for blobs to prevent accidental deletion. Common mistake: not enabling RA-GRS, so during a regional disaster, logs were unavailable for 24 hours until manual failover completed. After switching to RA-GRS, they met the 1-hour RPO requirement.
Enterprise Scenario 3: SaaS Application with Multi-Tenant Storage
A SaaS provider stores customer data in separate storage accounts per tenant for isolation. Each tenant gets a StorageV2 account with LRS (acceptable because data is backed up via Azure Backup). They use a naming convention like 'sa-tenant123-prod'. They restrict network access using service endpoints from their application VNet. They use Azure Policy to enforce encryption with customer-managed keys and deny creation of storage accounts without private endpoints. The challenge: managing thousands of storage accounts – they use Azure Blueprints to automate creation and apply policies. Misconfiguration: one tenant account was accidentally created without encryption, exposing data. Azure Policy now ensures all new accounts have encryption enabled.
What AZ-305 Tests on This Topic
AZ-305 objective 2.1: 'Design a storage solution' – this includes selecting storage account types, replication, access tiers, and network access. The exam expects you to recommend the correct storage account kind and performance tier based on workload requirements (e.g., for high IOPS, choose Premium). You must know the SLA differences: LRS and ZRS have 99.9% read SLA, RA-GRS has 99.99% read SLA. You must know the durability numbers: 11 nines for LRS/ZRS, 16 nines for GRS (due to geo-replication).
Common Wrong Answers and Why Candidates Choose Them
Choosing GRS for all workloads 'for maximum durability': Many candidates think GRS is always best. But GRS has higher cost and write latency due to async replication. For workloads that can tolerate zone failure but not regional failure, ZRS is better. For non-critical data, LRS is sufficient.
Selecting BlobStorage kind for a new deployment: BlobStorage is legacy and lacks features like lifecycle management. The exam expects StorageV2 for new deployments.
Picking RA-GRS when read access to secondary is not needed: RA-GRS costs more than GRS. Only choose it if you need read access during normal operations.
Assuming Premium performance is always faster: Premium is faster but more expensive. For workloads that don't need high IOPS, Standard is cost-effective.
Specific Numbers and Terms That Appear on the Exam
Durability: LRS/ZRS = 99.999999999% (11 nines), GRS = 99.99999999999999% (16 nines).
SLA: 99.9% for LRS/ZRS read, 99.99% for RA-GRS/RA-GZRS read, 99.9% for write operations on all.
Replication types: LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS.
Access tiers: Hot, Cool, Archive. Minimum storage duration for Cool: 30 days, Archive: 180 days.
Storage account kinds: StorageV2 (default), BlobStorage (legacy), FileStorage (premium files).
Performance: Standard (HDD), Premium (SSD).
Edge Cases and Exceptions
ZRS is not available in all regions: Check regional availability. For example, ZRS is not available in some older regions.
GRS failover is one-way and irreversible: Once you fail over, you cannot fail back automatically. You must set up a new GRS configuration.
Archive tier is offline: Blobs in Archive must be rehydrated to Hot or Cool before reading, which can take up to 15 hours (Standard priority) or 1 hour (High priority).
Firewall rules and service endpoints: When using service endpoints, the storage account still has a public endpoint but restricts traffic to the VNet. Private endpoints give a private IP.
How to Eliminate Wrong Answers
If the question mentions 'lowest cost' and 'non-critical data', choose LRS.
If it says 'zone failure tolerance', choose ZRS.
If it says 'regional disaster recovery with read access', choose RA-GRS or RA-GZRS.
If it says 'high IOPS for block blobs', choose Premium BlockBlobStorage.
If it says 'SMB file shares with low latency', choose Premium FileStorage.
StorageV2 is the recommended storage account kind for new deployments supporting blobs, files, queues, and tables.
LRS provides 11 nines durability (99.999999999%) and is the lowest cost, but not zone or region resilient.
ZRS provides zone resilience with 11 nines durability, but is not available in all regions.
GRS provides regional disaster recovery with async replication (RPO < 15 min) and 16 nines durability.
RA-GRS provides read access to the secondary region during normal operations, with a 99.99% read SLA.
Premium performance (SSD) is required for high IOPS workloads; Standard (HDD) is for general purpose.
Access tiers (Hot, Cool, Archive) optimize cost based on access frequency; Cool has 30-day min, Archive 180-day min.
Private endpoints provide the most secure network access by giving a private IP in your VNet.
Lifecycle management policies can automate tier transitions and deletions to reduce costs.
Changing replication type may cause data movement and potential downtime; plan accordingly.
These come up on the exam all the time. Here's how to tell them apart.
LRS (Locally Redundant Storage)
3 synchronous copies within a single data center
Not resilient to a data center failure
Lowest cost replication option
99.9% read SLA
Available in all regions
ZRS (Zone-Redundant Storage)
3 synchronous copies across 2-3 availability zones
Resilient to a zone failure (but not region failure)
Higher cost than LRS
99.9% read SLA
Not available in all regions (check regional support)
GRS (Geo-Redundant Storage)
LRS in primary + async copy to secondary region
Secondary is not readable unless failover occurs
Resilient to a regional failure
99.9% read SLA (primary only)
Lower cost than RA-GRS
RA-GRS (Read-Access Geo-Redundant Storage)
Same as GRS but secondary is readable during normal operations
Allows read access from secondary region at any time
Resilient to a regional failure with read access during disaster
99.99% read SLA (because secondary is readable)
Higher cost than GRS
Mistake
GRS provides synchronous replication to the secondary region.
Correct
GRS uses asynchronous replication. Data is first written synchronously to the primary region (LRS), then asynchronously to the secondary. This means there is a potential for data loss if a regional disaster occurs before the async copy completes (RPO is typically less than 15 minutes).
Mistake
You can change the replication type of a storage account at any time without downtime.
Correct
Changing replication type is possible but may involve data movement. For example, changing from LRS to GRS triggers an async copy to the secondary region, which can take hours and may incur egress costs. Some changes (like from GRS to LRS) are immediate but may cause a brief period of unavailability.
Mistake
Archive tier blobs can be read directly if you wait long enough.
Correct
Archive tier blobs are offline and cannot be read directly. They must be rehydrated to Hot or Cool tier first, which takes up to 15 hours for standard priority. During rehydration, the blob is still in Archive and cannot be accessed until it reaches the target tier.
Mistake
All storage account kinds support all services.
Correct
Only StorageV2 supports all four services (blob, file, queue, table). BlobStorage only supports blobs, and FileStorage only supports file shares. Choosing the wrong kind will prevent you from creating certain services.
Mistake
Private endpoints are the same as service endpoints.
Correct
Private endpoints give the storage account a private IP in your VNet, eliminating exposure to the public internet. Service endpoints allow access from a VNet but the storage account still has a public endpoint. Private endpoints are more secure and recommended for compliance.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
LRS replicates data three times within a single data center, offering 11 nines durability but no zone or region resilience. ZRS replicates across availability zones in the same region, protecting against zone failure. GRS replicates to a paired region asynchronously, protecting against regional failure. RA-GRS is GRS with read access to the secondary region, providing a higher read SLA (99.99%). For the exam, remember the durability numbers and SLA differences.
Use Premium storage when your workload requires high IOPS and low latency. For example, a database running on Azure VMs using page blobs, or a media streaming service using block blobs. Standard storage is suitable for most general-purpose workloads. Premium is more expensive, so only choose it if performance requirements demand it.
Yes, you can change the replication type, but it may involve data movement and potential downtime. For example, changing from LRS to GRS starts an async replication to a secondary region, which can take hours. Some changes, like from GRS to LRS, are immediate but may cause a brief unavailability. Always plan for these changes during maintenance windows.
A service endpoint allows access to the storage account from a specific VNet, but the storage account still has a public endpoint. A private endpoint gives the storage account a private IP in your VNet, eliminating public internet exposure. Private endpoints are more secure and are recommended for compliance with regulations that require data not to traverse the internet.
Use Azure Storage lifecycle management policies. You can define rules based on blob age or last modification time. For example, a policy can move blobs to Cool tier after 30 days of no access, and to Archive after 90 days. You can also delete blobs after a certain period. These policies are cost-effective for managing data lifecycle.
For read operations, LRS and ZRS have a 99.9% SLA, while RA-GRS and RA-GZRS have a 99.99% SLA. For write operations, all have a 99.9% SLA. Durability for LRS and ZRS is 99.999999999% (11 nines), and for GRS and RA-GRS it is 99.99999999999999% (16 nines).
Yes, Azure Storage is commonly used as a backup target for Azure Backup, which stores backup data in a Recovery Services vault that uses storage accounts. You can also directly store backups in blob storage. For long-term retention, use Cool or Archive tiers to reduce costs.
You've just covered Storage Account Design Decisions — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?