Storage Account Types

Azure Storage Account Types Explained

Azure Storage is one of the most versatile and foundational services in Azure, offering blob storage, file shares, queues, and tables under a single account. Choosing the right storage account type, redundancy option, and access tier directly impacts performance, availability, durability, and cost. A single misconfiguration, like choosing LRS instead of ZRS for production data or leaving all blobs in the Hot tier when most are rarely accessed, can cost thousands of dollars or put critical data at risk.

This guide breaks down the different storage account kinds, performance tiers, redundancy options, access tiers, lifecycle management, security configurations, and monitoring strategies. Whether you are storing application logs, serving static websites, hosting data lake analytics, or managing enterprise file shares, this guide helps you make informed decisions that balance cost, performance, and durability.

Storage Account Kinds

Azure offers several storage account kinds, each supporting different combinations of services and features. For new workloads, General-purpose v2 (GPv2) is almost always the right choice. The other kinds exist for specialized use cases or are legacy types that Microsoft recommends upgrading.

Standard vs Premium Performance

The performance tier determines the underlying storage media (HDD vs SSD) and affects latency, IOPS, and throughput characteristics.

# Standard GPv2 with Zone-Redundant Storage (production default)
az storage account create \
  --name prodappstorage \
  --resource-group myRG \
  --location eastus2 \
  --sku Standard_ZRS \
  --kind StorageV2 \
  --access-tier Hot \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --https-only true \
  --default-action Deny

# Premium Block Blob Storage for high-transaction workloads
az storage account create \
  --name premiumblobs \
  --resource-group myRG \
  --location eastus2 \
  --sku Premium_LRS \
  --kind BlockBlobStorage \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

# Data Lake Gen2 (GPv2 with hierarchical namespace enabled)
az storage account create \
  --name mydatalake \
  --resource-group myRG \
  --location eastus2 \
  --sku Standard_ZRS \
  --kind StorageV2 \
  --hns true \
  --min-tls-version TLS1_2

# Premium File Storage for high-IOPS file shares
az storage account create \
  --name premiumfiles \
  --resource-group myRG \
  --location eastus2 \
  --sku Premium_LRS \
  --kind FileStorage

Redundancy Options

Azure Storage always stores multiple copies of your data to protect against hardware failures, network outages, and power events. The redundancy option you choose determines how and where those copies are maintained. This directly affects durability (likelihood of data loss), availability (ability to access data during outages), and cost.

Choosing the Right Redundancy

Use this decision framework to select the appropriate redundancy level:

• Development and testing: LRS is sufficient. Data loss from a datacenter failure is acceptable in non-production environments, and LRS is the cheapest option.
• Production workloads (single-region): ZRS is the minimum recommendation. It protects against zone-level failures, which are more common than full region outages. The cost premium over LRS is approximately 25%.
• Business-critical data: RA-GZRS provides the highest durability (16 nines) with the ability to read data from the secondary region during a primary region outage. This is ideal for compliance-sensitive data and applications that cannot tolerate any data unavailability.
• Backup and disaster recovery: GRS or GZRS provides geo-redundancy without the additional cost of read-access to the secondary. Suitable for backup data that only needs to be accessed during a regional disaster.

# Change an existing account from LRS to ZRS (zero-downtime migration)
az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --sku Standard_ZRS

# Change to Geo-Zone Redundant with Read Access
az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --sku Standard_RAGZRS

# Check the replication status of a geo-redundant account
az storage account show \
  --name mystorageaccount \
  --resource-group myRG \
  --query '{SKU:sku.name, StatusOfPrimary:statusOfPrimary, StatusOfSecondary:statusOfSecondary, LastSyncTime:geoReplicationStats.lastSyncTime}' \
  --output table

# Initiate a customer-managed account failover (for GRS/GZRS accounts)
# WARNING: This makes the secondary become the new primary
az storage account failover \
  --name mystorageaccount \
  --resource-group myRG \
  --no-wait

Blob Access Tiers

Azure Blob Storage offers four access tiers that let you optimize cost based on how frequently data is accessed. The fundamental trade-off is simple: lower storage cost comes with higher access cost. You can set a default tier at the account level and override it per individual blob, giving you fine-grained cost optimization.

*Prices are approximate for East US 2 with LRS. Actual costs vary by region and redundancy option.

Early Deletion Penalties

Each tier has a minimum storage duration. If you move or delete a blob before the minimum period, you are charged for the remainder. For example, moving a blob from Cool tier after only 10 days incurs a charge equivalent to 20 additional days of Cool storage. This makes it important to set tiers correctly upfront and use lifecycle management rules rather than frequent manual tier changes.

Lifecycle Management Policies

Lifecycle management rules are the primary mechanism for cost optimization in storage-heavy workloads. They automatically transition blobs between tiers or delete them based on the last modification date, creation date, or last access time. Organizations that implement lifecycle management typically save 40-60% on storage costs.

{
  "rules": [
    {
      "enabled": true,
      "name": "optimize-log-storage",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToCold": {
              "daysAfterModificationGreaterThan": 90
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 365
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          },
          "snapshot": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/", "backups/", "telemetry/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "tier-based-on-access",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterLastAccessTimeGreaterThan": 30
            },
            "tierToCold": {
              "daysAfterLastAccessTimeGreaterThan": 90
            },
            "enableAutoTierToHotFromCool": true
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["uploads/", "media/"]
        }
      }
    }
  ]
}

# Enable last access time tracking (required for access-based tiering)
az storage account blob-service-properties update \
  --account-name mystorageaccount \
  --resource-group myRG \
  --enable-last-access-tracking true

# Apply the lifecycle management policy
az storage account management-policy create \
  --account-name mystorageaccount \
  --resource-group myRG \
  --policy @lifecycle-policy.json

# Verify the policy
az storage account management-policy show \
  --account-name mystorageaccount \
  --resource-group myRG

# Check current tier distribution of blobs
az storage blob list \
  --account-name mystorageaccount \
  --container-name logs \
  --query "[].{Name:name, Tier:properties.blobTier, Size:properties.contentLength, LastModified:properties.lastModified}" \
  --output table --num-results 50

Data Lake Storage Gen2

Data Lake Storage Gen2 is a set of capabilities built on Azure Blob Storage, activated by enabling the hierarchical namespace on a GPv2 account. It adds true directory-level operations, POSIX-compatible ACLs, and integration with analytics frameworks like Apache Spark, Azure Databricks, and Azure Synapse Analytics.

When to Enable Hierarchical Namespace

• Big data analytics: If you use Databricks, Synapse, HDInsight, or any Hadoop-compatible analytics tool, enable HNS. Directory-level operations are dramatically faster (rename a directory of 1 million files in milliseconds vs hours).
• Fine-grained access control: HNS supports POSIX ACLs at the file and directory level, which is essential for multi-tenant data lake architectures where different teams need access to different directories.
• Do NOT enable for general-purpose storage: If you are just storing blobs, serving static content, or using Queue/Table storage, the hierarchical namespace adds no benefit and cannot be disabled once enabled.

Security Configuration

Azure Storage provides multiple layers of security that should all be configured for production workloads. Security misconfigurations in storage accounts are among the most common findings in cloud security audits.

Security Checklist

param location string = resourceGroup().location
param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: { name: 'Standard_ZRS' }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    minimumTlsVersion: 'TLS1_2'
    supportsHttpsTrafficOnly: true
    allowBlobPublicAccess: false
    allowSharedKeyAccess: false
    publicNetworkAccess: 'Disabled'
    encryption: {
      services: {
        blob: { enabled: true, keyType: 'Account' }
        file: { enabled: true, keyType: 'Account' }
        queue: { enabled: true, keyType: 'Account' }
        table: { enabled: true, keyType: 'Account' }
      }
      keySource: 'Microsoft.Storage'
      requireInfrastructureEncryption: true
    }
    networkRules: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
      virtualNetworkRules: []
      ipRules: []
    }
  }
}

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2023-01-01' = {
  parent: storageAccount
  name: 'default'
  properties: {
    deleteRetentionPolicy: {
      enabled: true
      days: 30
    }
    containerDeleteRetentionPolicy: {
      enabled: true
      days: 30
    }
    isVersioningEnabled: true
    changeFeed: {
      enabled: true
      retentionInDays: 90
    }
    lastAccessTimeTrackingPolicy: {
      enable: true
    }
  }
}

output storageAccountId string = storageAccount.id
output blobEndpoint string = storageAccount.properties.primaryEndpoints.blob

Azure Files

Azure Files provides fully managed file shares accessible via SMB (Server Message Block) and NFS (Network File System) protocols. File shares are commonly used for lift-and-shift migrations of on-premises file servers, shared configuration across multiple VMs, and persistent storage for containerized applications.

Azure Files vs Blob Storage

Monitoring and Diagnostics

Monitoring storage accounts is essential for detecting performance issues, tracking costs, and identifying security anomalies. Azure provides built-in metrics and diagnostic logging for all storage services.

# Enable diagnostic logging for blob service
az monitor diagnostic-settings create \
  --name storage-diagnostics \
  --resource /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount/blobServices/default \
  --workspace /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/myWorkspace \
  --logs '[{"category":"StorageRead","enabled":true},{"category":"StorageWrite","enabled":true},{"category":"StorageDelete","enabled":true}]' \
  --metrics '[{"category":"Transaction","enabled":true},{"category":"Capacity","enabled":true}]'

# Check storage account capacity (used bytes)
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount/blobServices/default \
  --metric UsedCapacity \
  --interval PT1H \
  --output table

# Check transaction counts and latency
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount/blobServices/default \
  --metric Transactions SuccessServerLatency \
  --interval PT1H \
  --output table

Choosing the Right Configuration

Use this decision framework to select the appropriate storage configuration for your workload:

1. Determine the workload type: Blobs for unstructured data (documents, images, logs, backups), Files for SMB/NFS shares, Queues for messaging, Tables for NoSQL key-value data, Data Lake for big data analytics.
2. Evaluate performance requirements: Standard HDD-backed storage handles most workloads. Choose Premium SSD-backed storage only for latency-sensitive applications like databases, real-time media processing, or high-transaction IoT telemetry ingestion.
3. Select redundancy based on criticality: LRS for dev/test, ZRS for production, RA-GZRS for business-critical data that must survive regional failures.
4. Plan access tier transitions: Set up lifecycle management policies from day one. Most organizations save 40-60% on storage costs by automatically tiering data that ages out of active use.
5. Enable security features: Disable public blob access, require HTTPS, enforce TLS 1.2, use Private Endpoints for VNet-only access, and consider disabling shared key access to enforce Azure AD authentication exclusively.
6. Plan for data protection: Enable soft delete, blob versioning, and point-in-time restore for production data. These features add minimal cost but provide critical recovery capabilities.