Shared Storage (EFS)

You need several pods to read and write the same files at the same time — a
shared upload directory, a shared build cache, or a CMS that you want to run as
a scalable Deployment. A standard block volume can only be attached to one pod,
so this needs a shared EFS (NFS) volume instead.

Typical uses:

Multiple application replicas sharing the same files
Running a CMS as a Deployment rather than a StatefulSet, so it can scale
horizontally on shared persistent storage
A shared cache for CI/CD build pods

Before you start

EFS is available on AWS environments only. If you need shared storage on
GCP, raise a request and CTO2B will discuss the options with you.
Consider whether you actually need shared access. EFS is a network file
system: latency per operation is higher than block storage and it is billed on
stored data and throughput rather than on a fixed provisioned size. For a
latency-sensitive workload with a single writer, a standard persistent volume
is usually both faster and cheaper.

Step 1 — enable EFS on your Environment

In your Environment's base Component (infra-aws-base-env), add:

terraform:
  variables:
    efs_enabled: true

Click Save and wait for the deployment status to show Completed. This
installs the EFS StorageClass and the CSI driver on your cluster.

Step 2 — find the file system ID

The file system is created by the deployment in Step 1, and it has an ID you
need for the mount. Check the infra-aws-base-env Component in SVIEW once the
deployment completes — if the ID is not shown there, raise a request and CTO2B
will give you the value for your Environment.

If you already have Kubernetes namespace access, you can also read it
straight from the StorageClass:

kubectl get storageclass efs-sc -o jsonpath='{.parameters.fileSystemId}{"\n"}'

Requesting that access is covered in
Namespace Access.
Do not request it solely to look up this one value — asking is quicker.

Step 3 — mount the volume in your application

In your application Component, define the mount path and the file system ID:

pvc:
  efsMounts:
    - name: shared-data
      mountPath: "/mnt/cache"
      fileSystemId: <your-file-system-id>

Click Save. The volume is mounted at the configured path in every pod of
that Component.

How to verify it worked

Check that the Component returns to a healthy state on its dashboard after the
save, and that your application can write to the mount path from more than one
replica at once. If pods stay in Pending or ContainerCreating, the file
system ID is the first thing to re-check.

Common issues

Symptom	Likely cause
Pods stuck waiting on the volume	Step 1 was not completed, or the file system ID does not match your Environment
Slower than expected file operations	Expected for a network file system — see the trade-off note above
Need shared storage on GCP	Not available through this path — raise a request