Amazon EFS provides a shared filesystem that applications can mount from more than one machine. The historical EFS provisioner connected Kubernetes requests for persistent storage to that filesystem, reducing manual volume setup for workloads that needed shared files. It is useful to understand this design when maintaining an older deployment. The current EFS CSI driver uses a different integration model, so existing file paths and permissions need deliberate migration.
Deployment and operating notes
This entry describes the earlier EFS external provisioner and its ConfigMap-based filesystem configuration. The current Kubernetes SIG EFS CSI driver documents static and dynamic provisioning, with access-point-based dynamic provisioning. Installing the CSI driver does not automatically convert existing PV objects, paths or ownership settings from the retired stable chart.
Inventory each filesystem ID, mount target, security group, directory path, UID/GID, reclaim policy and application claim before migration. Choose static mapping for existing data where appropriate or plan a deliberate copy into newly provisioned access-point paths. Confirm IAM permissions and network reachability separately; a bound PVC can still fail to mount. Rehearse reads, writes and permissions using a non-production workload, then verify the application’s locking and shared-filesystem expectations. Protect the original data and avoid deleting claims until reclaim behavior is understood. Keep a recoverable mount path during cutover; changing a StorageClass name is not a data migration or a rollback plan.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
The Kubernetes project provides an AWS EFS provisioner that is used to fulfill PersistentVolumeClaims with EFS PersistentVolumes.
The efs-provisioner allows you to mount EFS storage as PersistentVolumes in kubernetes. It consists of a container that has access to an AWS EFS resource. The container reads a configmap which contains the EFS filesystem ID, the AWS region and the name you want to use for your efs-provisioner. This name will be used later when you create a storage class.
The EFS external storage provisioner runs in a Kubernetes cluster and will create persistent volumes in response to the PersistentVolumeClaim resources being created.
These persistent volumes can then be mounted on containers.
Prequisites
You must create the EFS file system and end points yourself first.
The end points must be accessible to the cluster and the cluster nodes must have permission to mount EFS file systems.
Sources & further reading
Spotted something that needs another look?
Help improve this page →