Skip to main content
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.
The image is an introduction to AWS Elastic File System (EFS), equating it to a Network File System (NFS), with corresponding icons for each.

​
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.
EFS provides NFSv4.1/4.2-compatible mounts with POSIX semantics, making it ideal for workloads requiring shared file access across pods and AZs.

​
Key Benefits of EFS

FeatureBenefit
Regional ServiceMount the same file system in multiple Availability Zones (AZs).
Multi-Writer AccessSupport many-to-many mounts—pods in different AZs share one volume.
Automatic ScalingGrow or shrink storage capacity on demand, up to petabyte scale.
Fully Managed NFSAWS handles back-end storage, patches, and availability.
The image illustrates the benefits of EFS, showing a region with two availability zones, each containing a pod, and one zone featuring an EFS icon.

​
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
The image illustrates how Amazon EFS (Elastic File System) integrates with a Kubernetes cluster, showing components like VPC, subnets, nodes, pods, EFS mount points, IAM permissions, and security group policies.
With the CSI driver, pods in any AZ can mount the same file system concurrently:
The image illustrates a diagram showing pods in two availability zones connected to an EFS mount point and a database.

​
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.
Running high-concurrency databases on EFS can cause I/O contention due to file locks. Evaluate workload patterns and test performance before production use.

​
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
The image illustrates a dynamic provisioning setup with two availability zones, each containing a pod, connected to an EFS mount point for applications.

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

Storage TypeAccess PatternAZ ScopeCost TierIdeal Use Case
EFSNFS, multi-writerRegional$$Shared file storage, web assets
EBSBlock, single-writerSingle AZ$High IOPS databases, low-latency apps
S3ObjectRegional$Backups, archives, static hosting
The image compares EFS and EBS, highlighting that file system size matters in EFS, volume is not a concern in EBS, and EBS and S3 are cheaper options.
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

Watch Video