An EBS volume lives in one zone and attaches to one node, so provision it where the Pod will run.

Use gp3, set a zone-aware StorageClass, and plan replicas and spread constraints around it.

StorageClass

kind: StorageClass
metadata: {name: gp3-wffc, annotations: {storageclass.kubernetes.io/is-default-class: "true"}}
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters: {type: gp3, encrypted: "true"}

Check your default class

Many clusters still ship a legacy gp2 default. Create a gp3 class, make it the default, and encrypt volumes. gp3 lets you set IOPS and throughput independently of size.

EBS volumes: fast, zonal, ReadWriteOnce

The EBS CSI driver is the add-on that provisions and attaches Amazon EBS volumes. EBS volumes are zonal, so with a StorageClass that uses WaitForFirstConsumer the driver creates the volume only after the scheduler has chosen a node, in that node's zone. Reveal the four steps with the right arrow. This avoids the classic problem of a volume created in a zone where the Pod cannot run.

Remember the Deck 1 access-mode rule. EBS volumes are ReadWriteOnce, attachable to one node at a time, so a Deployment with one PVC cannot scale across nodes; use a StatefulSet with a claim per replica, or a shared filesystem. Instances also have a limit on the number of attached volumes, which can cap how many stateful Pods fit on a node.

Choose gp3 as the default volume type because it decouples IOPS and throughput from size and is usually cheaper than gp2. Enable encryption (optionally with your own KMS key), allow volume expansion, and consider snapshots through the CSI snapshot controller. Snapshots are crash-consistent: for databases combine them with application-aware backup.

Zone failure is the design consequence: a Pod bound to an EBS volume in a failed zone cannot simply start in another zone with its data. Replicate at the data layer (database replication across zones) or be ready to restore from a snapshot into another zone.