⌂ Home

CSI, AWS EBS, and EFS

Understand how Kubernetes uses CSI drivers to provision cloud storage, how PVCs trigger AWS volumes, and when to choose EBS versus EFS.

Pods do not call AWS storage APIs directly. A Pod uses a PVC, the PVC references a StorageClass, Kubernetes asks a CSI driver to create or attach real cloud storage, and the Pod finally mounts that storage as a filesystem path.

Core Concepts

CSI Is The Translator

CSI, the Container Storage Interface, is the standard plugin model Kubernetes uses to talk to storage platforms such as AWS. The CSI driver knows how to create, attach, detach, resize, and sometimes snapshot cloud volumes.

PVC Is The App Request

Your application asks for storage through a PersistentVolumeClaim. It does not need AWS-specific logic in the Pod spec.

StorageClass Is The Policy

The StorageClass decides which provisioner to use, what disk type to request, and when binding should happen.

AWS Gives The Real Storage

In AWS, the CSI driver can create an EBS volume for single-node block storage or work with EFS for shared network file storage.

How Cloud Storage Works In Kubernetes

App requests storage

A Pod references a PVC such as app-data instead of calling AWS directly.

PVC points to a StorageClass

The claim says which storage policy to use, such as an AWS EBS CSI class.

CSI driver calls AWS APIs

The EBS CSI driver asks AWS to create a real EBS volume that matches the request.

Kubernetes creates a PV

The resulting cloud disk is represented inside the cluster as a PersistentVolume bound to the PVC.

Node attaches and mounts storage

Kubernetes attaches the volume to the correct node and mounts it into the Pod at the requested path.

Key point: The Pod sees a normal mount path like /data. The CSI driver and Kubernetes hide the cloud API details behind the storage abstraction.

Representative YAML

AWS EBS CSI StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
  fsType: ext4

PVC That Triggers EBS Creation

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 20Gi

Pod That Uses The Claim

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: app-data

AWS EBS vs AWS EFS

Topic	AWS EBS	AWS EFS
Storage style	Block storage, disk-like	Shared network filesystem
Typical access pattern	Usually `ReadWriteOnce`	Usually shared multi-node access
Best fit	Databases, stateful apps, single-writer workloads	Shared files, content, multi-node workloads
Mental model	One workload needs its own disk	Many workloads need the same file tree
Common mistake	Expecting EBS to behave like a shared filesystem	Using EFS where low-latency block semantics are required

Design hint: Use EBS when the app wants a disk. Use EFS when many Pods or nodes need the same shared files.

How To Use It In Practice

Stateful apps on AWS

Use a PVC with an EBS CSI StorageClass for workloads such as PostgreSQL, MySQL, or any app that needs durable single-node block storage.

Portable app specs

Keep cloud details in the StorageClass so the Pod and PVC stay cleaner and more reusable across environments.

Dynamic provisioning

Let Kubernetes and the CSI driver create volumes automatically instead of pre-creating and wiring every disk manually.

Cloud storage teaching path

Explain storage as: Pod -> PVC -> StorageClass -> CSI driver -> cloud volume -> mounted filesystem path.