Update docs/layers/eks/design-decisions/decide-on-default-storage-cla…

…ss.mdx

Co-authored-by: Erik Osterman (CEO @ Cloud Posse) <[email protected]>

docs/layers/eks/design-decisions/decide-on-default-storage-class.mdx

@@ -55,9 +55,19 @@ We need to decide between **Amazon EFS (Elastic File System)** and **Amazon EBS
 
 ## Recommendation
 
-Use **Amazon EBS** unless there is a good reason not to.
+Use **Amazon EBS** as the primary storage option when:
 
-Use **Amazon EFS** when:
+	•	High performance, low-latency storage is required for workloads confined to a single Availability Zone.
+	•	The workload doesn’t require shared access across multiple Pods.
+	•	You need cost-effective storage with support for snapshots and backups.
+	•	Manual resizing of volumes is acceptable for capacity management, recognizing that failover across AZs requires manual intervention and provisioning.
 
-- Multiple Pods need read/write access to the same data at the same time.
-- Persistent data needs to be available in multiple Availability Zones and the underlying application does not support replication.
+Consider **Amazon EFS** when:
+
+	•	Multiple Pods need concurrent read/write access to shared data across nodes.
+	•	Workloads must persist data across multiple Availability Zones for high availability, and the application does not support native replication.
+	•	Elastic, automatically scaling storage is necessary to avoid manual provisioning, especially for workloads with unpredictable growth.
+	•	You are willing to trade off higher costs and lower performance for multi-AZ durability and easier management of shared storage.
+
+> ![IMPORTANT]
+> EFS should never be used as backend storage for performance-sensitive applications like databases, due to its high latency and poor performance under heavy load.