Storage Accounts (Blob/Azure Data Lake Storage Gen2)
The presented resiliency recommendations in this guidance include Storage Account and associated settings.
Summary of Recommendations
The below table shows the list of resiliency recommendations for Storage Account and associated resources.
Recommendation | Category | Impact | State | ARG Query Available |
---|---|---|---|---|
ST-1 - Ensure that storage accounts are zone or region redundant | Availability | High | Verified | Yes |
ST-2 - Do not use classic storage accounts | Governance | High | Verified | Yes |
ST-3 - Ensure performance tier is set as per workload | System Efficiency | Medium | Verified | No |
ST-5 - Enable soft delete for recovery of data | Disaster Recovery | Medium | Verified | No |
ST-6 - Enable versioning for accidental modification and keep the number of versions below 1000 | Disaster Recovery | Low | Verified | No |
ST-7 - Consider enabling point-in-time restore for standard general purpose v2 accounts with flat namespace | Disaster Recovery | Low | Verified | No |
ST-8 - Monitor all blob storage accounts | Monitoring | Low | Verified | No |
ST-9 - Consider upgrading legacy storage accounts to v2 storage accounts | System Efficiency | Low | Verified | Yes |
Recommendations Details
ST-1 - Ensure that storage accounts are zone or region redundant
Category: Availability
Impact: High
Guidance
Redundancy ensures that your storage account meets its availability and durability targets even in the face of failures. When deciding which redundancy option is best for your scenario, consider the tradeoffs between lower costs and higher availability. Locally redundant storage (LRS) is the lowest-cost redundancy option and offers the least durability compared to other options. Microsoft recommends using zone-redundant storage (ZRS), geo-redundant storage (GRS), or geo-zone-redundant storage (GZRS) to ensure your storage accounts are available if an availability zone or region becomes unavailable.
Resources
Resource Graph Query
// Azure Resource Graph Query
// This query will return all storage accounts that are not using Zone or Region replication
Resources
| where type =~ "Microsoft.Storage/storageAccounts"
| where sku.name in~ ("Standard_LRS", "Premium_LRS")
| project recommendationId = "st-1", name, id, tags, param1 = strcat("sku: ", sku.name)
ST-2 - Do not use classic storage accounts
Category: Governance
Impact: High
Guidance
Classic storage accounts will be fully retired on August 31, 2024. If you have classic storage accounts, start planning your migration now.
Resources
- Azure classic storage accounts retirement announcement
- Migrate your classic storage accounts to Azure Resource Manager
Resource Graph Query
// Azure Resource Graph Query
// Find all Azure classic Storage Account
resources
| where type =~ 'microsoft.classicstorage/storageaccounts'
| project recommendationId = 'st-2', name, id, tags, param1=type
ST-3 - Ensure Performance tier is set as per workload
Category: System Efficiency
Impact: Medium
Guidance
Consider using appropriate storage performance tier for workload scenarios. Each workload scenario requires appropriate performance tiers and it’s important that appropriate performance tiers are selected based on the storage usage.
Resources
- Types of storage accounts
- Scalability and performance targets for standard storage accounts
- Performance and scalability checklist for Blob storage
- Scalability and performance targets for Blob storage
- Premium block blob storage accounts
- Scalability targets for premium block blob storage accounts
- Scalability and performance targets for premium page blob storage accounts
Resource Graph Query
// cannot-be-validated-with-arg
ST-5 - Enable soft delete for recovery of data
Category: Disaster Recovery
Impact: Medium
Guidance
Soft delete option allow for recovering data if its deleted by mistaken. Moreover Lock will prevent accidentally deleting storage account.
Resources
Script
// under-development
ST-6 - Enable versioning for accidental modification and keep the number of versions below 1000
Category: Disaster Recovery
Impact: Low
Guidance
Consider enabling versioning to recover data from accidental modification or deletion. Having a large number of versions per blob can increase the latency for blob listing operations. Microsoft recommends maintaining fewer than 1000 versions per blob. You can use lifecycle management to automatically delete old versions.
Resources
Script
// under-development
ST-7 - Consider enabling point-in-time restore for standard general purpose v2 accounts with flat namespace
Category: Disaster Recovery
Impact: Low
Guidance
Consider enabling point-in-time restore for standard general purpose v2 accounts with flat namespace. Point-in-time restore provides protection against accidental deletion or corruption by enabling you to restore block blob data to an earlier state.
Resources
Script
// under-development
ST-8 - Monitor all blob storage accounts
Category: Monitoring
Impact: Low
Guidance
When you have critical applications and business processes that rely on Azure resources, you need to monitor and get alerts for your system. Resource logs aren’t collected and stored until you create a diagnostic setting and route the logs to one or more locations. When you create a diagnostic setting, you specify which categories of logs to collect.
Resources
Script
// under-development
ST-9 - Consider upgrading legacy storage accounts to v2 storage accounts
Category: System Efficiency
Impact: Low
Guidance
General-purpose v2 accounts are recommended for most storage scenarios with the latest features or the lowest per-gigabyte pricing. Legacy account types (Standard general-purpose v1 and Blob Storage) aren’t recommended by Microsoft, but may be used in certain scenarios. Please consider the scenarios (classic compatibility, transaction-intensive, etc.) listed in the documentation and upgrade legacy storage accounts to v2 storage accounts when applicable.
Upgrading to a general-purpose v2 storage account from your general-purpose v1 or Blob storage accounts is straightforward. There’s no downtime or risk of data loss associated with upgrading to a general-purpose v2 storage account. Upgrading a general-purpose v1 or Blob storage account to general-purpose v2 is permanent and cannot be undone.
Resources
Script
// Azure Resource Graph Query
// Find all Azure Storage Accounts, that upgradeable to General purpose v2.
Resources
| where type =~ "Microsoft.Storage/storageAccounts" and kind in~ ("Storage", "BlobStorage")
| extend
param1 = strcat("AccountKind: ", case(kind =~ "Storage", "Storage (general purpose v1)", kind =~ "BlobStorage", "BlobStorage", kind)),
param2 = strcat("Performance: ", sku.tier),
param3 = strcat("Replication: ", sku.name)
| project recommendationId = "st-9", name, id, tags, param1, param2, param3