Kubernetes
PVC
ReadWriteMany
AWS
Cloud Storage

Kubernetes PVC with ReadWriteMany on AWS

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Introduction

ReadWriteMany, usually shortened to RWX, means the same volume can be mounted read-write by multiple nodes or pods at the same time. On AWS, this is not something standard EBS volumes provide across nodes, so the storage backend choice matters more than the PVC YAML itself.

Why RWX Is Different on AWS

Kubernetes access modes describe what the underlying storage can do. A PVC requesting ReadWriteMany will only bind successfully if the backing storage class supports shared read-write mounts.

On AWS, Amazon EBS is typically ReadWriteOnce. It is great for single-node block storage, but it is not the normal answer for a multi-writer workload spread across nodes.

For RWX, the standard AWS-native choice is Amazon EFS, exposed to Kubernetes through the EFS CSI driver. EFS is a network file system, so multiple pods on different nodes can mount the same data concurrently.

Typical EFS-Based Setup

The high-level flow is:

  1. Create an EFS file system.
  2. Make sure mount targets and security groups allow NFS traffic.
  3. Install the Amazon EFS CSI driver in the cluster.
  4. Create a StorageClass and PVC that use the driver.
  5. Mount the claim from one or more pods.

An example StorageClass and PVC:

yaml
1apiVersion: storage.k8s.io/v1
2kind: StorageClass
3metadata:
4  name: efs-sc
5provisioner: efs.csi.aws.com
6parameters:
7  provisioningMode: efs-ap
8  fileSystemId: fs-12345678
9  directoryPerms: "755"
10mountOptions:
11  - tls
12---
13apiVersion: v1
14kind: PersistentVolumeClaim
15metadata:
16  name: shared-data
17spec:
18  accessModes:
19    - ReadWriteMany
20  storageClassName: efs-sc
21  resources:
22    requests:
23      storage: 5Gi

Then mount it from a workload:

yaml
1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: writer
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: writer
10  template:
11    metadata:
12      labels:
13        app: writer
14    spec:
15      containers:
16        - name: app
17          image: nginx:stable
18          volumeMounts:
19            - name: shared
20              mountPath: /usr/share/nginx/html
21      volumes:
22        - name: shared
23          persistentVolumeClaim:
24            claimName: shared-data

With EFS behind the claim, both replicas can see the same files.

Design Tradeoffs

RWX is about sharing, not raw local-disk performance. Because EFS is network-attached storage, latency and throughput characteristics differ from EBS. That is usually fine for shared content, uploads, model files, or application state that truly needs a common filesystem view.

It is often a bad fit for write-heavy databases that expect low-latency block storage. In those cases, people request RWX because it sounds convenient, but the better architecture is usually one writer backed by EBS or a managed database service.

Operational Checks

If the claim stays pending or pods cannot mount the volume, check the entire chain:

  • the EFS CSI driver is installed and healthy
  • the fileSystemId is correct
  • EFS mount targets exist in the right subnets
  • node security groups allow NFS traffic on port 2049
  • the cluster IAM setup matches the CSI driver requirements

A quick check is:

bash
kubectl get pvc,pv
kubectl describe pvc shared-data
kubectl get pods -n kube-system | grep efs

The describe output usually points directly at provisioning or mount errors.

Common Pitfalls

The biggest mistake is expecting EBS to behave like shared network storage. Standard EBS-backed storage classes do not give you true multi-node ReadWriteMany.

Another issue is requesting RWX without installing the correct CSI driver. The PVC may be valid YAML and still never bind.

Network configuration is also a common source of pain. EFS needs reachable mount targets and permissive security-group rules for NFS traffic.

Finally, do not treat RWX as a generic solution for any stateful workload. Shared filesystem semantics help some applications and actively hurt others.

Summary

  • 'ReadWriteMany requires storage that supports concurrent read-write mounts.'
  • On AWS, Amazon EFS is the usual Kubernetes answer for RWX.
  • EBS is typically the wrong choice for multi-node shared filesystem access.
  • Install the EFS CSI driver and wire the PVC to an EFS-backed StorageClass.
  • Check driver health, mount targets, IAM, and NFS networking when claims or mounts fail.

Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.