Introduction

Amazon EFS is a shared network file system, so at the storage layer it can absolutely be mounted by multiple workloads at the same time. The part that trips people up is Kubernetes scoping: PersistentVolumeClaims are namespaced, which means one claim in namespace team-a cannot be referenced directly by a pod in namespace team-b. To share EFS across namespaces, you share the underlying file system, not one PVC object.

In practice, that usually means installing the EFS CSI driver, using ReadWriteMany, and creating a separate PVC in each namespace that points at the same EFS-backed storage design. If you want every namespace to see the exact same files, static provisioning is usually the clearest model.

Understand the Namespace Boundary

Kubernetes PersistentVolumes are cluster-scoped, but PersistentVolumeClaims live inside a namespace. A pod can only mount a claim from its own namespace.

So this does not work as a cross-namespace design:

• create one PVC in team-a
• try to mount that same PVC from a pod in team-b

Instead, model the sharing one layer lower. Let multiple claims represent access to the same EFS file system or directory.

Install the EFS CSI Driver First

On EKS or a self-managed cluster, start by installing the Amazon EFS CSI driver and confirming that worker nodes can reach the EFS mount targets.

You also need these infrastructure pieces correct before Kubernetes storage objects matter:

• EFS mount targets in the required subnets
• security groups that allow NFS traffic
• POSIX ownership and permissions that match your workload

If networking is wrong, the YAML can look perfect while mounts still fail.

Use Static Provisioning for a Truly Shared Directory

Dynamic provisioning with EFS often creates a distinct access point per claim, which is useful for isolation. If your goal is for multiple namespaces to read and write the same directory, static provisioning is usually easier to reason about.

The pattern is:

1. create one PV per namespace-facing claim
2. point each PV at the same EFS file system or same EFS path design
3. create one PVC in each namespace
4. mount the local namespace claim in each pod

Example PV for namespace team-a:

1apiVersion: v1
2kind: PersistentVolume
3metadata:
4  name: shared-efs-team-a
5spec:
6  capacity:
7    storage: 1Ti
8  accessModes:
9    - ReadWriteMany
10  persistentVolumeReclaimPolicy: Retain
11  csi:
12    driver: efs.csi.aws.com
13    volumeHandle: fs-12345678

Matching claim in team-a:

1apiVersion: v1
2kind: PersistentVolumeClaim
3metadata:
4  name: shared-efs
5  namespace: team-a
6spec:
7  accessModes:
8    - ReadWriteMany
9  volumeName: shared-efs-team-a
10  resources:
11    requests:
12      storage: 1Ti

Then create a second PV and PVC pair for team-b, pointing at the same fs-12345678 file system.

Mount the Claim Normally Inside Each Namespace

Once each namespace has its own claim, the pod spec is ordinary Kubernetes.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: report-job
5  namespace: team-b
6spec:
7  containers:
8    - name: app
9      image: public.ecr.aws/docker/library/busybox:1.36
10      command: ["sh", "-c", "echo hello >> /shared/log.txt && sleep 3600"]
11      volumeMounts:
12        - name: data
13          mountPath: /shared
14  volumes:
15    - name: data
16      persistentVolumeClaim:
17        claimName: shared-efs

The pod in team-b mounts its own shared-efs claim, but the bytes still land on the same EFS-backed storage as the pod in team-a.

Decide Between Shared Data and Isolated Data

This design question matters more than the YAML.

Use one shared EFS location when:

• teams must see the same files
• one workload produces files that another consumes
• concurrent read and write access is expected

Use separate EFS access points or directories when:

• teams need isolation
• permissions differ by namespace
• accidental file collisions would be dangerous

EFS makes sharing easy at the file-system level, but that does not mean sharing is always the right application boundary.

Common Pitfalls

The biggest mistake is assuming one PVC can be mounted across namespaces. It cannot, because claims are namespaced.

Another common problem is using dynamic provisioning when the real requirement is one truly shared directory. Dynamic EFS provisioning often gives each claim a separate access point, which is the opposite of a shared-data design.

A third issue is ignoring file permissions. Even when the mount succeeds, mismatched UID, GID, or directory permissions can make one namespace appear broken while another works.

Summary

• Share the underlying EFS storage across namespaces, not a single PVC object.
• PVCs are namespaced, so create one claim per namespace.
• Use ReadWriteMany and the EFS CSI driver for concurrent access.
• Prefer static provisioning when every namespace should see the same files.
• Verify networking and POSIX permissions, not just Kubernetes manifests.