Azure Container Storage

About Azure Container Storage

Azure Container Storage is Microsoft's volume management and orchestration service for stateful container workloads. It integrates with Kubernetes so teams can provision and manage persistent volumes with standard Kubernetes objects instead of treating storage as a separate VM-centric layer. The current 2.x generation supports local NVMe and Azure Elastic SAN as backing storage, while the earlier 1.x line is still relevant for Azure Disks. Buyers should choose it when storage performance, fast volume attach and detach, and Kubernetes-native operations matter more than broad file-sharing compatibility.

What is Azure Container Storage used for?

Azure Container Storage is designed for stateful applications running on Kubernetes. Common fits include databases, analytics engines, streaming and messaging systems, CI/CD workloads, and latency-sensitive AI or machine learning workloads. Microsoft positions local NVMe for very low latency workloads that can tolerate local disk characteristics or provide their own replication, while Elastic SAN provides durable network-attached block storage with predictable throughput and redundancy options.

The service manages the storage lifecycle through Kubernetes constructs such as StorageClass objects, persistent volumes and persistent volume claims. That lets platform teams keep storage provisioning closer to the Kubernetes workflow instead of manually wiring each workload to a separate storage service.

How do local NVMe and Elastic SAN differ?

Local NVMe is the highest performance option and is tied to supported node VM sizes. It can be used for ephemeral or persistent volumes, but Microsoft notes that local NVMe does not provide storage-level replication or snapshots. It is therefore a better fit when the application can tolerate local storage failure characteristics or implements its own replication.

Elastic SAN is the durable option in Azure Container Storage 2.x. It supports persistent volumes, volume expansion, snapshots, encryption, and locally redundant or zone-redundant storage. Microsoft also says Elastic SAN can support thousands of persistent volumes per cluster, which helps avoid per-VM disk attachment limits that can constrain large stateful Kubernetes deployments.

How is Azure Container Storage deployed on AKS?

Microsoft supports installing Azure Container Storage on a new or existing Azure Kubernetes Service cluster. The Azure CLI flow can install only the service first and defer driver deployment until a storage type is selected, or it can install the service together with local NVMe or Elastic SAN support. Terraform installation is also documented.

Current installation guidance requires Linux node pools. Windows containers are not supported. For local NVMe, the selected VM SKU must expose compatible local NVMe data disks. Elastic SAN use requires the Microsoft.ElasticSan resource provider to be registered in the subscription. Microsoft also documents specific outbound endpoints that may need to be allowlisted when a restrictive firewall sits in the path.

What changed in Azure Container Storage version 2?

Version 2 introduced a simpler Kubernetes-native model but also includes breaking changes from version 1. Microsoft removed the StoragePool custom resource, moved users toward standard Kubernetes StorageClass objects, changed the local NVMe CSI provisioner name, changed the ephemeral storage annotation, and removed the bundled Prometheus Operator.

Microsoft's migration guidance says organizations moving from 1.x to 2.x should completely remove the prior Azure Container Storage version and review the new setup process. Version choice also depends on backing storage: Microsoft currently directs local NVMe and Elastic SAN users to version 2, while Azure Disks remain a version 1 scenario.

What is the current support lifecycle?

Azure Container Storage uses a versioned support model aligned with AKS extension guidance. Microsoft states that major and minor releases receive 12 months of support from their release date, while patch releases share the end-of-life date of the related release line.

As of the pricing and lifecycle check on August 28, 2026, version 2.2.0 is supported through June 17, 2027 and validates Kubernetes 1.35, 1.34 and 1.33. Microsoft recommends checking the Azure Container Storage support table before upgrading Kubernetes because unsupported version combinations can create operational risk.

How much does Azure Container Storage cost?

Pricing checked August 28, 2026. Microsoft currently states that Azure Container Storage version 2.0.0 and later has no separate service fee. That does not make the workload free: customers still pay for the underlying AKS compute, Elastic SAN capacity and performance, network usage, and other Azure resources used by the application.

Older Azure Container Storage versions have a tiered pricing structure. Organizations still running 1.x should therefore evaluate both migration work and the pricing implications rather than assuming the current no-service-fee model applies to every installed version.

What are the main limitations?

Azure Container Storage is not a universal Kubernetes storage layer. Microsoft currently limits the managed AKS experience to Linux nodes using Ubuntu or Azure Linux and does not support Windows containers or ARM node pools. The FAQ also states that read-write-many workloads are not supported. Microsoft points customers needing RWX semantics toward Azure Files or Blob CSI drivers instead.

The service itself does not provide a separate SLA. Microsoft explains that availability commitments come from the underlying storage option. Region support is also limited to a subset of Azure regions, and Elastic SAN has its own regional availability that must be checked separately.

How does it differ from Azure Managed Disks, Azure Files and Elastic SAN?

Azure Container Storage is primarily the Kubernetes orchestration layer, not a replacement for every underlying Azure storage service. Azure Managed Disks provide block storage for VMs and are used by Kubernetes through disk integrations. Azure Files provides shared file storage and is a better fit when workloads need SMB, NFS or read-write-many access. Azure Elastic SAN is a managed SAN service that supplies durable block storage and can act as the backing store for Azure Container Storage 2.x.

Choose Azure Container Storage when the main requirement is Kubernetes-native lifecycle management, rapid volume operations and a storage design optimized for stateful container workloads. Choose the underlying storage services directly when Kubernetes orchestration is not the problem you are trying to solve.

Who should choose something else?

Teams running Windows containers, ARM-based node pools or workloads that require RWX shared storage should choose another storage path because those scenarios are outside current Azure Container Storage support. Azure Files is the clearer first-party option for shared file access, while direct Azure Disks may be simpler for smaller AKS environments that do not need the additional orchestration layer.

Organizations with stable non-container VM workloads should also stay with VM-oriented storage services rather than adding Kubernetes-specific tooling. Finally, teams using Azure Container Storage 1.x only because Azure Disks are required should evaluate the supported version and migration path carefully instead of assuming version 2 is a drop-in replacement.