Storage options for a Kubernetes cluster

This article compares the storage capabilities of Amazon Elastic Kubernetes Service (EKS) and Azure Kubernetes Service (AKS). It also describes storage options for workload data on AKS.

Amazon EKS storage options

Amazon EKS provides different types of storage volumes for applications that require data storage. You can use these volumes for temporary and long-lasting storage.

Ephemeral volumes

Use ephemeral volumes when your applications require temporary storage but don't need to persist data after restarts. For example:

• A caching service moves infrequently used data to temporary storage.
• Read-only input data, like configuration data, is stored in files.

Kubernetes supports different types of ephemeral volumes, such as emptyDir, ConfigMap, downwardAPI, secret, CSI ephemeral volumes, and generic ephemeral volumes.

Amazon EBS

For generic ephemeral volumes in EKS Standard, you can use the Amazon EBS CSI driver to provision temporary, block-level scratch space that's directly tied to a pod's lifecycle. Unlike traditional emptyDir volumes, which share the node's root disk, generic ephemeral volumes automatically use an independent AWS EBS volume when the pod starts and delete it when the pod terminates.

EKS Auto Mode manages the underlying Amazon EBS CSI driver. You don't need to install or manage the storage controller yourself.

Amazon EC2 instance store

You can also use Amazon EC2 instance stores, which provide temporary block-level storage for EC2 instances. These volumes are physically attached to the hosts and only exist during the lifetime of the instance. To use local store volumes in Kubernetes, you must partition, configure, and format the disks by using Amazon EC2 user data.

The Amazon EC2 Instance Store CSI driver isn't supported in EKS Auto Mode.

FSx for Lustre scratch volumes

Although they're not managed as ephemeral Kubernetes storage, you can provision scratch type (Scratch_1, Scratch_2) FSx for Lustre file systems on EKS. These file systems are designed for temporary, short-term data processing. They can be mounted via Persistent Volume Claims (PVCs), and you can delete the file system when the compute job completes.

Persistent volumes

You typically use Kubernetes to run stateless applications, but sometimes you need persistent data storage. You can use Kubernetes persistent volumes to store data independently from pods so that the data can persist beyond the lifetime of a given pod. Amazon EKS supports different types of storage options for persistent volumes.

Amazon EBS

Use Amazon EBS volumes for block-level storage, databases, and throughput-intensive applications. If you use Amazon EKS, you can use the latest generation of block storage gp3 to balance price and performance. For higher-performance applications, you can use io2 Block Express volumes. To minimize cost, you can use HDD-based st1/sc1 volumes.

In EKS Auto Mode, the EBS CSI driver is automatically managed.

Amazon EFS

Amazon EFS is a serverless elastic file system that you can share across multiple containers and nodes. It automatically expands and shrinks as files are added or removed, which eliminates the need for capacity planning. The Amazon EFS CSI driver integrates Amazon EFS with Kubernetes. The Amazon EFS CSI driver isn't compatible with Windows-based container images.

In EKS Auto Mode, when you set up EFS, you need to create the underlying file system first and manually define the mapping by using standard StorageClass objects, PersistentVolume (PV), and PVC.

Amazon S3 Files

Amazon S3 Files is a high-performance, low-latency shared file system that's layered over your Amazon S3 data. This design allows file-dependent applications, workflows, and teams to operate on S3 datasets by using their existing tools. The Amazon EFS CSI driver allows AWS-hosted clusters to natively mount these S3 file systems as persistent volumes in both EKS Standard and EKS Auto Mode.

Amazon FSx for Lustre

Amazon FSx for Lustre provides high-performance parallel file storage. Use this type of storage for scenarios that require high-throughput and low-latency operations. You can link this file storage to an Amazon S3 data repository to store large datasets.

FSx for Lustre is supported in both EKS Standard and EKS Auto Mode.

Amazon FSx for NetApp ONTAP

Amazon FSx for NetApp ONTAP is a fully managed, shared storage solution that's built on NetApp's ONTAP file system. You can provision and manage highly available shared file storage natively in your EKS Standard and EKS Auto Mode clusters by using the NetApp Astra Trident CSI driver.

Amazon FSx for OpenZFS

Amazon FSx for OpenZFS provides a fully managed service for migrating on-premises ZFS or Linux-based file systems to AWS without changing application code or workflows. It uses the open-source OpenZFS file system for scalable, efficient storage. The FSx for OpenZFS CSI driver enables Amazon EKS clusters to manage the lifecycle of these volumes.

FSx for OpenZFS is supported in both EKS Standard and EKS Auto Mode.

Amazon File Cache

Amazon File Cache is a fully managed, high-speed AWS service that processes file data from any location. It automatically loads files when they're needed and releases them when they aren't. The Amazon File Cache CSI driver enables Amazon EKS clusters to manage the lifecycle of these caches via a standard interface.

Amazon File Cache is supported in both EKS Standard and EKS Auto Mode.

Backup

You can back up your Amazon EKS persistent volumes by using Amazon EKS backup (part of AWS Backup) or Velero. EKS backup is the easiest method because it handles everything natively without requiring extra tools.

The CSI snapshot controller provides snapshot functionality for EKS. You can use it to get point-in-time copies of your data. This functionality requires both a CSI driver with snapshot support (like the Amazon EBS CSI driver) and the CSI snapshot controller. The snapshot controller is available either as an Amazon EKS managed add-on or as a self-managed installation.

See AKS Backup to learn about how AKS handles backup and snapshots.

EKS and AWS Secrets Manager

You can use AWS Secrets and Configuration Provider (ASCP) for the Kubernetes Secrets Store CSI driver to securely store and manage secrets in Secrets Manager and access them from applications that run on Amazon EKS. Access to secrets can be restricted to specific Kubernetes pods via IAM roles and policies. ASCP obtains the pod identity, maps it to an IAM role, assumes that role, and then retrieves only the secrets that the role is permitted to access.

See AKS and Key Vault to learn about the Key Vault provider for the Secrets Store CSI driver.

AKS storage options

Applications that run in AKS might need to store and retrieve data. Some application workloads can use local, fast storage on unneeded, empty nodes. But other application workloads require storage that persists on more regular data volumes within the Azure platform. Multiple pods might need to:

• Share the same data volumes.
• Reattach data volumes if the pod is rescheduled on a different node.

The following sections introduce the storage options and core concepts that provide storage to your applications in AKS.

Volume types

Kubernetes volumes represent more than just a traditional disk to store and retrieve information. You can also use Kubernetes volumes to inject data into a pod for its containers to use.

Common volume types in Kubernetes include emptyDirs, secrets, and ConfigMaps.

EmptyDirs

For a pod that defines an emptyDir volume, the volume is created when the pod is assigned to a node. As the name suggests, the emptyDir volume is initially empty. All containers in the pod can read and write the same files in the emptyDir volume, although this volume can be mounted at the same or different paths in each container. When a pod is removed from a node for any reason, the data in the emptyDir is deleted permanently.

Secrets

A secret is an object that holds a small amount of sensitive data, such as a password, token, or key. If you don't use a secret, this information is included in a pod specification or container image. A secret prevents the need to embed confidential data directly in your application code. You can create secrets independently of the pods that use them. This practice reduces the risk of exposing the secret and its data when you create, view, and edit pods. Kubernetes and the applications that run in your cluster can take extra precautions with secrets, such as preventing sensitive data from being written to nonvolatile storage. Secrets are similar to ConfigMaps, but they're specifically designed to store confidential data.

You can use secrets for the following purposes:

• Set environment variables for a container.
• Provide credentials such as SSH keys or passwords to pods.
• Allow the kubelet to pull container images from private registries.

The Kubernetes control plane also uses secrets, such as bootstrap token secrets, to help automate node registration.

ConfigMaps

A ConfigMap is a Kubernetes object that you use to store nonconfidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume. You can use a ConfigMap to decouple environment-specific configurations from your container images, which makes your applications easily portable.

ConfigMaps don't provide secrecy or encryption. If you want to store confidential data, use a secret rather than a ConfigMap, or use other partner tools to keep your data private.

You can use a ConfigMap to set configuration data separately from application code. For example, you might develop an application to run on your computer for development and to run in the cloud to handle real traffic. You can write the code to look in an environment variable named DATABASE_HOST. Locally, set that variable to localhost. In the cloud, set it to refer to a Kubernetes service that exposes the database component to your cluster. This approach lets you fetch a container image that runs in the cloud and debug the same code locally if needed.

Persistent volumes

Volumes that are defined and created as part of the pod lifecycle only exist until you delete the pod. Pods often expect their storage to remain if a pod is rescheduled on a different host during a maintenance event, especially in StatefulSets. A persistent volume is a storage resource that the Kubernetes API creates and manages. A persistent volume can exist beyond the lifetime of an individual pod. You can use the following Azure Storage tools to provide the persistent volume:

• Azure disk storage
• Azure Files
• Azure NetApp Files
• Azure Blob Storage
• Azure Container Storage

To decide between Azure disk storage or Azure Files, consider whether your application needs concurrent data access or a specific performance tier.

👁 Diagram of persistent volumes in an AKS cluster.

A cluster administrator can statically create a persistent volume, or the Kubernetes API server can dynamically create a volume. If a pod is scheduled and requests storage that's currently unavailable, Kubernetes can create the underlying Azure disk or file storage and attach it to the pod. Dynamic provisioning uses a storage class to identify what type of resource needs to be created.

Storage classes

To specify different tiers of storage, such as premium or standard, you can create a storage class.

A storage class also defines a reclaim policy. When you delete a persistent volume, the reclaim policy controls the behavior of the underlying Azure Storage resource. The underlying resource can either be deleted or kept for use with a future pod.

Clusters that use Azure Container Storage have an extra storage class called acstor-<storage-pool-name>. An internal storage class is also created.

For clusters that use CSI drivers, the following extra storage classes are created:

Unless you specify a storage class for a persistent volume, the default storage class is used. Ensure that volumes use the storage that you need when you request persistent volumes.

The default class is the same as the managed-csi class.

For Kubernetes version 1.29 and later, when you deploy AKS clusters across multiple availability zones, AKS uses ZRS to create managed disks within built-in storage classes. ZRS ensures synchronous replication of your Azure managed disks across multiple Azure availability zones in your chosen region. This redundancy strategy enhances the resilience of your applications and helps safeguard your data against datacenter failures.

However, ZRS costs more than LRS. If cost optimization is a priority, you can create a new storage class that has the skuname parameter set to LRS. You can then use the new storage class in your persistent volume claim.

You can create a storage class for other needs by using kubectl. The following example uses Premium SSDs and specifies that the underlying Azure disk should be retained when you delete the pod:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
 skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

AKS reconciles the default storage classes and overwrites any changes that you make to those storage classes.

For more information, see StorageClass in Kubernetes.

Persistent volume claims

A persistent volume claim requests storage of a particular storage class, access mode, and size. The Kubernetes API server can dynamically provision the underlying Azure Storage resource if no existing resource can fulfill the claim based on the defined storage class.

The pod definition includes the volume mount after the volume connects to the pod.

👁 Diagram of persistent volume claims in an AKS cluster.

After an available storage resource is assigned to the pod that requests storage, the persistent volume is bound to a persistent volume claim. Each persistent volume is associated with one persistent volume claim to ensure dedicated storage.

The following example YAML manifest shows a persistent volume claim that uses the managed-premium storage class and requests an Azure disk that's 5Gi in size:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: azure-managed-disk
spec:
 accessModes:
 - ReadWriteOnce
 storageClassName: managed-premium-retain
 resources:
 requests:
 storage: 5Gi

When you create a pod definition, you also specify:

• The persistent volume claim to request the desired storage.
• The volume mount for your applications to read and write data.

The following example YAML manifest shows how the previous persistent volume claim can mount a volume at /mnt/azure:

kind: Pod
apiVersion: v1
metadata:
 name: nginx
spec:
 containers:
 - name: myfrontend
 image: mcr.microsoft.com/oss/nginx/nginx:1.27.4-alpine
 volumeMounts:
 - mountPath: "/mnt/azure"
 name: volume
 volumes:
 - name: volume
 persistentVolumeClaim:
 claimName: azure-managed-disk

To mount a volume in a Windows container, specify the drive letter and path:

... 
 volumeMounts:
 - mountPath: "d:"
 name: volume
 - mountPath: "c:\k"
 name: k-dir
...

Ephemeral OS disk

By default, Azure automatically replicates the operating system disk for a virtual machine (VM) to Azure Storage to avoid data loss when the VM is relocated to another host. However, containers aren't designed to have local state persisted, so this behavior provides limited value and drawbacks. These drawbacks include slower node provisioning and higher read and write latency.

In contrast, ephemeral OS disks are stored only on the host machine, like a temporary disk. This configuration provides lower read and write latency and faster node scaling and cluster upgrades.

If you don't request Azure managed disks for the OS, AKS defaults to ephemeral OS disks if possible for a given node pool configuration.

• If you select the Standard_E2bds_v5 VM size with the default OS disk size of 100 GiB, the VM supports ephemeral OS disks but only has 75 GB of temporary storage. This configuration defaults to managed OS disks if you don't specify it. If you request an ephemeral OS disk, you receive a validation error.

• If you request the same Standard_E2bds_v5 VM size with a 60-GiB OS disk, this configuration defaults to ephemeral OS disks. The requested size of 60 GiB is smaller than the maximum temporary storage of 75 GiB.

• If you select the Standard_E4bds_v5 SKU with a 100-GiB OS disk, this VM size supports ephemeral OS disks and has 150 GiB of temporary storage. If you don't specify the OS disk type, Azure provisions an ephemeral OS disk to the node pool.

Customer-managed keys

You can manage encryption for your ephemeral OS disk by using your own keys on an AKS cluster. For more information, see Bring your own keys with Azure managed disks in AKS.

Volumes

Kubernetes typically treats individual pods as ephemeral, disposable resources. Applications have different approaches for using and persisting data. A volume represents a way to store, retrieve, and persist data across pods and through the application lifecycle.

Traditional volumes are created as Kubernetes resources that are backed by Azure Storage. You can manually create data volumes to be assigned to pods directly or have Kubernetes automatically create them. Data volumes can use Azure disk storage, Azure Files, Azure NetApp Files, or Blob Storage.

To decide between Azure Files and Azure NetApp Files, see Azure Files and Azure NetApp Files comparison.

Azure disk storage

By default, an AKS cluster comes with precreated managed-csi and managed-csi-premium storage classes that use Azure disk storage. Similar to Amazon EBS, these classes create a managed disk or block device that's attached to the node for pod access.

The disk classes allow both static and dynamic volume provisioning. The reclaim policy ensures that the disk is deleted with the persistent volume. To expand the disk, edit the persistent volume claim.

These storage classes use Azure managed disks with LRS. Data in LRS has three synchronous copies within a single physical location in an Azure primary region. LRS is the least expensive replication option but doesn't provide protection against a datacenter failure. You can define custom storage classes that use ZRS managed disks.

ZRS synchronously replicates your Azure managed disk across three Azure availability zones in your region. Each availability zone is a separate physical location that has independent power, cooling, and networking. ZRS disks provide at least 99.9999999999% of durability over a given year. A ZRS managed disk can be attached by a VM in a different availability zone. ZRS disks aren't available in all Azure regions. For more information, see ZRS options for Azure disks to improve availability.

To mitigate the risk of data loss, use AKS backup to take regular backups or snapshots of disk storage data. Or you can use partner solutions, like Velero or Azure Backup, that have built-in snapshot technology.

You can use Azure disk storage to create a Kubernetes DataDisk resource. You can use the following disks types:

• Premium SSD (recommended for most workloads)
• Premium SSD v2
• Azure Ultra Disk Storage
• Standard SSD

An Azure disk is mounted as ReadWriteOnce, so it's only available to a single node. For storage volumes that pods on multiple nodes can access simultaneously, use Azure Files.

Premium SSD v2 disks

Premium SSD v2 disks are designed for input/output(I/O)-intense enterprise workloads. They provide consistent submillisecond disk latency, high input/output operations per second (IOPS), and high throughput. You can independently configure the performance (capacity, IOPS, and throughput) of Premium SSD v2 disks at any time. So you easily improve cost efficiency while meeting performance needs. For more information about how to configure a new or existing AKS cluster to use Azure Premium SSD v2 disks, see Use Premium SSD v2 disks on AKS.

Ultra Disk Storage

Ultra Disk Storage is an Azure managed disk tier that provides high throughput, high IOPS, and consistent low-latency disk storage for Azure VMs. Use Ultra Disk Storage for data-intensive and transaction-heavy workloads. Like other disk storage SKUs and Amazon EBS, Ultra Disk Storage mounts one pod at a time and doesn't provide concurrent access.

To enable Ultra Disk Storage on your AKS cluster, use the flag --enable-ultra-ssd.

Be aware of Ultra Disk Storage limitations, and select a compatible VM size. Ultra Disk Storage has LRS replication.

Bring your own keys (BYOK)

Azure encrypts all data in a managed disk at rest, including the OS and data disks of an AKS cluster. By default, data is encrypted with Microsoft-managed keys. For more control over encryption keys, you can supply customer-managed keys to provide encryption at rest for both the OS and data disks in AKS clusters. For more information, see BYOK with Azure managed disks in AKS and Server-side encryption of Azure disk storage.

Azure Files

Disk storage can't provide concurrent access to a volume, but you can use Azure Files to mount a Server Message Block (SMB) version 3.1.1 share or NFS version 4.1 share that's backed by Azure Storage. This process provides network-attached storage that's similar to Amazon EFS. Azure Files has two storage options:

• Azure Files Standard storage backs the file share with regular hard disk drives (HDDs).

• Azure Files Premium storage backs the file share with high-performance solid-state drives (SSDs). The minimum file share size for Premium is 100 GB.

Azure Files has the following storage account replication options to protect your data if failure occurs:

• Standard_LRS: Standard LRS
• Standard_GRS: Standard geo-redundant storage (GRS)
• Standard_ZRS: Standard ZRS
• Standard_RAGRS: Standard read-access GRS (RA-GRS)
• Standard_RAGZRS: Standard read-access geo-zone-redundant storage (RA-GZRS)
• Premium_LRS: Premium LRS
• Premium_ZRS: Premium ZRS

To optimize costs for Azure Files, purchase Azure Files capacity reservations.

Azure NetApp Files

Azure NetApp Files is an enterprise-class, high-performance, metered file storage service that runs on Azure and supports volumes by using NFS (NFSv3 or NFSv4.1), SMB, and dual protocol (NFSv3 and SMB or NFSv4.1 and SMB) volumes. Kubernetes users have two options for using Azure NetApp Files volumes for Kubernetes workloads:

• Create Azure NetApp Files volumes statically. Create volumes outside of AKS via the Azure CLI or the Azure portal. After creation, these volumes are exposed to Kubernetes by creating a PersistentVolume. Statically created Azure NetApp Files volumes have many limitations. For example, they can't be expanded and they need to be overprovisioned. We don't recommend statically created volumes for most use cases.

• Create Azure NetApp Files volumes dynamically through Kubernetes. This is the preferred method to create multiple volumes directly through Kubernetes by using NetApp Trident. Trident is a CSI-compliant dynamic storage orchestrator that helps provision volumes natively through Kubernetes.

For more information, see Configure Azure NetApp Files for AKS.

Blob Storage

The Blob Storage CSI driver is a CSI specification-compliant driver that AKS uses to manage the lifecycle of Blob Storage. The CSI is a standard for exposing arbitrary block and file storage systems to containerized workloads on Kubernetes.

Adopt and use the CSI so that AKS can write, deploy, and iterate plug-ins. The plug-ins expose new storage systems or improve existing storage systems in Kubernetes. CSI drivers in AKS eliminate the need to modify the core Kubernetes code and wait for its release cycles.

When you mount Blob Storage as a file system into a container or pod, you can use it with applications that handle large amounts of unstructured data, such as:

• Log file data.
• Images, documents, and streaming video or audio.
• Disaster recovery data.

Applications can access the data on the object storage via Blobfuse2 or the NFS 3.0 protocol. Before the introduction of the Blob Storage CSI driver, the only option was to manually install an unsupported driver to access Blob Storage from your application that runs on AKS. A Blob Storage CSI driver that's enabled on AKS has two built-in storage classes: azureblob-fuse-premium and azureblob-nfs-premium.

To create an AKS cluster that has CSI drivers support, see CSI drivers on AKS. For more information, see Compare access to Azure Files, Blob Storage, and Azure NetApp Files with NFS.

Azure Managed Lustre

Azure Managed Lustre is a managed parallel file system that accelerates access to your data for high-performance computing tasks and provides the scalability of cloud solutions.

NFS server

For shared NFS access, you should use Azure Files or Azure NetApp Files. You can also create an NFS server on an Azure VM that exports volumes.

This option only supports static provisioning. You must provision the NFS shares manually on the server. You can't provision NFS shares automatically on AKS.

This solution is based on infrastructure as a service (IaaS) rather than platform as a service (PaaS). You manage the NFS server, including OS updates, high availability, backups, disaster recovery, and scalability.

Azure Container Storage

Azure Container Storage is a cloud-based volume management, deployment, and orchestration service that's built natively for containers. It integrates with Kubernetes so that you can dynamically and automatically provision persistent volumes to store data for stateful applications that run on Kubernetes clusters.

Azure Container Storage uses existing Azure Storage offerings for actual data storage and provides a volume orchestration and management solution that's purposely built for containers. Azure Container Storage supports the following backing storage:

• Local NVMe disk: Use local NVMe storage resources on AKS nodes. NVMe is designed for high-speed data transfer between storage and CPU. It provides high IOPS and throughput.

• Elastic SAN: Provision on-demand, fully managed resources. Elastic SAN suits general purpose databases, streaming and messaging services, continuous integration and continuous delivery environments, and other tier-1 or tier-2 workloads. Multiple clusters can access a single storage area network (SAN) concurrently. However, persistent volumes can only be attached by one consumer at a time.

Azure Container Storage suits the following scenarios:

• Accelerate VM-to-container initiatives: Azure Container Storage provides high-performance storage options for containers, including local NVMe disks (ultra-low latency) and Elastic SAN (durable, network-attached volumes).

• Simplify volume management with Kubernetes: Azure Container Storage provides volume orchestration via the Kubernetes control plane. This feature simplifies the deployment and management of volumes within Kubernetes, without the need to switch between different control planes.

• Reduce the total cost of ownership: To improve cost efficiency, increase the scale of persistent volumes that are supported for each pod or node. To reduce the storage resources needed for provisioning, dynamically share storage resources. Scale-up support for the storage pool itself isn't included.

Azure Container Storage provides the following key benefits:

• Scale out stateful pods rapidly: Azure Container Storage mounts persistent volumes via network block storage protocols, such as NVMe-oF or iSCSI. This capability ensures fast attachment and detachment of persistent volumes. You can start small and deploy resources as needed to ensure that your applications aren't starved or disrupted during initialization or in production. When a pod respawns across the cluster, the associated persistent volume must be rapidly moved to the new pod to maintain application resiliency. By using remote network protocols, Azure Container Storage tightly couples with the pod lifecycle to support highly resilient, high-scale stateful applications on AKS.

• Improve performance for stateful workloads: Azure Container Storage enables superior read performance and provides near-disk write performance by using NVMe-oF over RDMA. This capability allows you to cost-effectively meet performance requirements for various container workloads, including tier-1 I/O-intensive, general-purpose, throughput-sensitive, and dev/test workloads. Accelerate the attach and detach time of persistent volumes and minimize pod failover time.

• Orchestrate Kubernetes-native volumes: Create storage pools and persistent volumes, capture snapshots, and manage the entire lifecycle of volumes by using kubectl commands without switching between toolsets for different control plane operations.

Partner solutions

Like Amazon EKS, AKS is a Kubernetes implementation, and you can integrate partner Kubernetes storage solutions. Here are some examples of partner storage solutions for Kubernetes:

• Rook turns distributed storage systems into self-managing storage services by automating Azure Storage administrator tasks. Rook delivers its services via a Kubernetes operator for each storage provider.

• Ceph provides a reliable and scalable unified storage service that has object, block, and file interfaces from a single cluster that's built from commodity hardware components.

• MinIO multicloud object storage lets enterprises build AWS S3-compatible data infrastructure on any cloud. It provides a consistent, portable interface to your data and applications.

• Portworx is an end-to-end storage and data management solution for Kubernetes projects and container-based initiatives. Portworx provides container-granular storage, disaster recovery, data security, and multicloud migrations.

• Quobyte provides high-performance file and object storage that you can deploy on any server or cloud to scale performance, manage large amounts of data, and simplify administration.

Storage and AKS Automatic

AKS Automatic manages the storage lifecycle for you. AKS Standard gives you more direct control.

High-level comparison between AKS Automatic and AKS Standard

High-level comparison between AKS Automatic and EKS Auto Mode

Kubernetes storage considerations

Consider the following factors when you choose a storage solution for AKS.

Storage class access modes

In Kubernetes version 1.21 and later, by default, AKS storage classes use CSI drivers only.

Different services support storage classes that have different access modes.

Dynamic vs. static provisioning

Dynamically provision volumes to reduce the management overhead of statically creating persistent volumes. Set an appropriate reclaim policy to eliminate unused disks when you delete pods.

AKS backup

AKS provides various options, similar to EKS backup and snapshot, for persistent data backup or to create a volume snapshot.

Choose a tool to back up persistent data. The tool should match your storage type, such as snapshots, Azure Backup for AKS, Velero, or Veeam Kasten.

To create a volume snapshot in AKS, ensure that the snapshot controller is enabled, create a VolumeSnapshotClass, and then create a VolumeSnapshot that references your PVC. The Azure Files CSI driver supports creating a volume snapshot from a PVC with Azure Files. The Azure Disks CSI driver supports creating a volume snapshot from a PVC with Azure Disks.

AKS and Key Vault

Like EKS ASCP for the Kubernetes Secrets Store CSI driver, Azure Key Vault provider for the Secrets Store CSI driver enables Key Vault to be integrated as a secure secret store for AKS clusters through a CSI volume. You can use it to mount secrets, keys, and certificates directly into pods. It supports CSI inline volumes, and you can use it to mount multiple secret store objects in a single volume. The provider also improves pod portability via the SecretProviderClass Custom Resource Definition (CRD), supports Windows containers, synchronizes with Kubernetes secrets, and provides automatic rotation for both mounted content and synced Kubernetes secrets.

Cost optimization

To optimize Azure Storage costs, use Azure reservations if the service supports them. For more information, see Cost management for a Kubernetes cluster.

Contributors

Microsoft maintains this article. The following contributors wrote this article.

Principal authors:

• Laura Nicolas | Senior Cloud Solution Architect
• Pranab Paul | Senior Global Partner Solution Architect
• Paolo Salvatori | Principal System Engineer

Other contributors:

• Chad Kittel | Principal Software Engineer - Azure Patterns & Practices
• Theano Petersen | Technical Writer

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

• Training: Azure Storage services
• Training: Store data in Azure
• Training: Introduction to Kubernetes
• Training: Introduction to Azure NetApp Files

Related resources

• AKS for Amazon EKS professionals
• Kubernetes identity and access management
• Kubernetes monitoring and logging
• Secure network access to Kubernetes
• Cost management for Kubernetes
• Kubernetes node and node pool management
• Cluster governance