Module 5

Add-ons and storage

A new EKS cluster has a control plane and little else. Managed add-ons install and update networking, DNS and storage drivers, and the CSI drivers connect Pods to EBS, EFS, FSx and S3.

Why it matters. A routine add-on update that overwrites custom settings, or a volume pinned to the wrong zone, are classic production incidents. Both are avoidable with the right defaults.

After this module you can answer

Which components are EKS-managed add-ons?
What does --resolve-conflicts PRESERVE protect?
How do EBS volumes behave across zones?
When do I need EFS, FSx or an S3 mount?
Where does backup fit?

What is inside

1Managed add-ons

2EBS CSI and storage classes

3Shared and object storage

4Module infographic

Add-ons and storage: the parts that make a cluster useful

Module 5 covers the components that a bare cluster needs before it runs real workloads: the VPC CNI, CoreDNS and kube-proxy, plus storage drivers. EKS can manage them as add-ons, meaning the installation, version compatibility and updates are API operations with health reporting rather than YAML you maintain forever.

The storage half applies the Deck 1 storage module to AWS: EBS volumes are zonal and ReadWriteOnce, so StorageClass binding mode and spread constraints matter; EFS provides shared ReadWriteMany; FSx for Lustre and Mountpoint for S3 serve high-throughput and data-lake workloads.

Keep in mind the platform comparison with GKE from Deck 2: Persistent Disk, Filestore and Cloud Storage FUSE are the Google counterparts.