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.

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

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

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