EKS EFSElastic File System

Elastic File System (EFS) is AWS’s managed NFS service, seamlessly integrating with Amazon EKS to provide shared, scalable file storage for containers. In this guide, we’ll explore EFS essentials, Kubernetes integration, performance considerations, dynamic provisioning, and a cost–capacity comparison with EBS and S3.

What Is Amazon EFS?

EFS delivers a fully managed, elastic NFS file system that automatically scales storage up and down as you add or remove files. It abstracts away capacity planning and low-level configuration, letting developers focus on applications.

Key Benefits of EFS

EFS Integration with Kubernetes

To use EFS in EKS, you perform infrastructure setup outside the cluster, then leverage the EFS CSI driver for mounting:

1. Provision EFS

   • Create an EFS file system and mount targets in each subnet.
   • Configure security groups to allow NFS traffic (port 2049) from EKS node subnets.
   • Assign IAM roles or policies permitting elasticfilesystem:ClientMount and related actions.

2. Install the EFS CSI Driver

   helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
   helm install aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \
     --namespace kube-system
   

3. Define PV & PVC

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: efs-pv
   spec:
     capacity:
       storage: 5Gi
     volumeMode: Filesystem
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     csi:
       driver: efs.csi.aws.com
       volumeHandle: fs-12345678
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: efs-pvc
   spec:
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 5Gi
     storageClassName: ""
     volumeName: efs-pv
   

4. Mount in a Pod

   apiVersion: v1
   kind: Pod
   metadata:
     name: efs-app
   spec:
     containers:
       - name: app
         image: nginx
         volumeMounts:
           - name: efs-vol
             mountPath: /usr/share/nginx/html
     volumes:
       - name: efs-vol
         persistentVolumeClaim:
           claimName: efs-pvc
   

With the CSI driver, pods in any AZ can mount the same file system concurrently:

Performance and Workload Considerations

EFS offers shared read/write access but inherits NFS characteristics:

• File locking may block concurrent writes on the same file.
• Latency can be higher than block storage for small-file operations.
• Throughput scales with burst credits and Provisioned Throughput modes.

Dynamic Provisioning

The EFS CSI driver supports creating subdirectories under one mount target for isolated PVCs. This simplifies management compared to a generic NFS provisioner:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-12345678
  directoryPerms: "750"
reclaimPolicy: Delete
volumeBindingMode: Immediate

When you create a PVC using this storage class, the driver auto-creates a subpath:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: app1-pvc
spec:
  storageClassName: efs-sc
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

EFS vs. EBS vs. S3: Cost and Capacity Trade-offs

Choose EFS for cross-AZ, multi-writer scenarios with POSIX semantics. Opt for EBS when you need high-performance block storage. Use S3 for inexpensive, scalable object storage.

Further Reading

• Amazon EFS Documentation
• AWS EFS CSI Driver
• Kubernetes Persistent Volumes