EFS: Throughput Modes, Access Points, and the EKS CSI Driver

What EFS solves that S3 and EBS don't

EBS volumes attach to one EC2 instance at a time (except Multi-Attach in rare configurations). S3 is object storage — no file system semantics, no POSIX, no flock(). EFS fills the gap: a POSIX-compliant file system that multiple instances can mount simultaneously as NFS.

Common production uses: shared configuration files for a fleet of web servers, ML training datasets read by many GPU instances in parallel, container persistent storage in EKS where multiple pods need read-write access to the same files.

Throughput modes: which to choose

EFS offers three throughput modes. The choice affects performance characteristics and cost significantly.

Bursting (original default): throughput scales with storage size. 50 MB/s baseline per TB stored, with burst capability using accumulated credits. New file systems have a burst credit balance. If your workload exceeds baseline throughput for extended periods, credits deplete and performance drops to baseline. This is the classic EFS performance cliff: tests work fine, production fails when credits run out.

Elastic (recommended default as of 2023): automatically scales throughput up to 3 GB/s for reads and 1 GB/s for writes based on actual workload. No credit system. You pay for throughput actually used, not provisioned. For most workloads, Elastic eliminates the burst credit management problem.

Provisioned: you specify a throughput value (MB/s) that is always available regardless of storage size. Use when you have a small file system but need consistently high throughput (e.g., 10 GB file system needing 500 MB/s).

resource "aws_efs_file_system" "shared" {
  creation_token = "shared-storage"
  encrypted      = true
  kms_key_id     = aws_kms_key.efs.arn

  throughput_mode = "elastic"   # recommended for most workloads

  lifecycle_policy {
    transition_to_ia = "AFTER_30_DAYS"  # move infrequently accessed files to IA storage class
  }

  lifecycle_policy {
    transition_to_primary_storage_class = "AFTER_1_ACCESS"  # move back to Standard on access
  }

  tags = {
    Name = "shared-storage"
  }
}

resource "aws_efs_mount_target" "az1" {
  file_system_id  = aws_efs_file_system.shared.id
  subnet_id       = aws_subnet.private_az1.id
  security_groups = [aws_security_group.efs.id]
}

resource "aws_efs_mount_target" "az2" {
  file_system_id  = aws_efs_file_system.shared.id
  subnet_id       = aws_subnet.private_az2.id
  security_groups = [aws_security_group.efs.id]
}

Access points: per-application file system views

EFS access points provide application-specific entry points into a shared file system. Each access point can enforce a specific root directory path and a specific POSIX user/group identity — even if the calling process runs as a different UID.

This solves the multi-tenant problem for containers: multiple pods can share one EFS file system with each pod isolated to its own subdirectory and UID, without needing to configure each container's user mapping.

resource "aws_efs_access_point" "app_data" {
  file_system_id = aws_efs_file_system.shared.id

  root_directory {
    path = "/app-data"
    creation_info {
      owner_gid   = 1000
      owner_uid   = 1000
      permissions = "755"
    }
  }

  posix_user {
    gid = 1000
    uid = 1000
  }
}

When a container mounts via this access point, it sees /app-data as the root /, and all file operations run as UID/GID 1000 — regardless of what user the container runs as.

aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name aws-efs-csi-driver \
  --service-account-role-arn arn:aws:iam::123456789012:role/EFSCSIRole

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap          # dynamic provisioning via access points
  fileSystemId: fs-xxxxxxxx
  directoryPerms: "700"
  basePath: "/dynamic-provisioning" # root directory for auto-created subdirs

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-storage
spec:
  accessModes:
    - ReadWriteMany              # multiple pods can mount this PVC simultaneously
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi               # EFS doesn't enforce capacity — this is informational

EFS vs EBS vs S3 decision framework

| Factor | EFS | EBS | S3 | |---|---|---|---| | Multiple simultaneous writers | Yes | No (except Multi-Attach) | Object-level only | | POSIX semantics | Yes | Yes | No | | Performance | NFS latency (~1ms) | Sub-ms | Higher (HTTP) | | Scale | Auto-scales | Fixed provisioned size | Auto-scales | | Cost (per GB) | Higher | Medium | Lower | | EKS access mode | ReadWriteMany | ReadWriteOnce | Via SDK |

EFS is the right choice when multiple pods or instances need concurrent read-write access to shared files with POSIX semantics. For single-pod persistent storage, EBS is faster and cheaper. For large objects accessed via API, S3 is far cheaper.