Microsoft has released Azure Container Storage v2.0.0, introducing significant performance enhancements and architectural simplifications for stateful workloads on Azure Kubernetes Service (AKS). The release focuses on deeper NVMe integration, streamlined user experience, and expanded open-source availability, while removing all service fees beyond underlying storage costs.
The new version delivers substantial performance gains through optimized local NVMe disk integration. According to Microsoft’s benchmarking using fio, the industry standard storage testing tool, Azure Container Storage with NVMe striping now provides approximately seven times higher IOPS and four times lower latency compared to the previous version. These improvements translate directly to real-world application benefits, with PostgreSQL deployments showing 60% higher transactions per second and over 30% reduction in latency when tested against Microsoft’s own PostgreSQL for AKS deployment guide.
Beyond traditional database workloads, the v2.0.0 release demonstrates particular strength in AI and machine learning scenarios through its integration with KAITO, the Kubernetes AI Toolchain Operator. Large language model deployments, which often involve loading tens or hundreds of gigabytes into GPU memory, have historically suffered from network storage bottlenecks. By automatically provisioning striped NVMe volumes on GPU nodes, KAITO can now cache model files locally, resulting in over five times faster model loading compared to ephemeral OS disks. The cached volumes persist across pod restarts, eliminating repetitive network transfers and enabling faster scale-out during traffic spikes.
Microsoft has fundamentally simplified the architecture in response to user feedback from earlier versions. The most notable change eliminates the custom StoragePool resource that previously required manual configuration before creating persistent volume claims. Users now interact solely with standard Kubernetes StorageClasses and PVCs, aligning with familiar Kubernetes patterns. The architecture itself has been streamlined from multiple controllers and node daemons to a single lightweight operator plus CSI driver components, reducing resource overhead and system complexity. This lighter footprint enables deployment on single-node or two-node clusters, previously impossible in versions that required a minimum of three nodes.
The removal of the bundled Prometheus operator addresses another significant pain point. Previous versions automatically deployed Prometheus for metrics collection, creating conflicts in clusters with existing monitoring infrastructure. Version 2.0.0 instead exposes metrics through standard endpoints that can be scraped by Azure Monitor, Azure Managed Prometheus, or any existing Prometheus deployment. Additional improvements include eliminating the dependency on cert-manager for webhook certificates and relocating components to the kube-system namespace alongside built-in CSI drivers, reducing policy conflicts.
A major shift in the business model makes Azure Container Storage v2.0.0 completely free to use. While users continue to pay for underlying storage resources, Microsoft has eliminated the per-gigabyte monthly fee previously charged for storage pools exceeding 5 TiB. This pricing change applies to both the managed Azure service and the open-source version, removing cost barriers for large-scale deployments.
The open-source release represents another strategic development. Microsoft has published the core components, including the local CSI driver for NVMe and ephemeral disk management, on GitHub. This enables deployment on self-hosted Kubernetes clusters running on Azure VMs, extends transparency to the broader community, and invites external contributions. The open-source foundation aligns with Microsoft’s stated commitment to Kubernetes ecosystem principles while potentially accelerating feature development through community participation.
Azure Container Storage’s approach differs from competing solutions in AWS and Google Cloud. AWS relies on the Amazon EBS CSI driver for EKS clusters, which manages Amazon Elastic Block Store volumes through standard Kubernetes storage interfaces, with additional support through the Amazon EFS Container Storage Interface driver for file system storage. Google Cloud uses the Compute Engine Persistent Disk CSI driver as the primary storage method for GKE clusters, complemented by Hyperdisk volumes that allow dynamic performance tuning by independently configuring IOPS and throughput. Both AWS and Google Cloud follow the standard CSI driver model without the integrated platform-managed approach or built-in NVMe optimization that Azure Container Storage provides. Microsoft’s strategy of combining ultra-fast local NVMe with a simplified, free management layer represents a distinct architectural choice in the competitive landscape of Kubernetes storage solutions.
