2.1.4.2. Application Storage Patterns for Deployments (EFS, S3, EBS)
2.1.4.2. Application Storage Patterns for Deployments (EFS, S3, EBS)
Deployments to EC2 instances need to put files somewhere — and the storage choice affects availability, performance, and deployment complexity.
Amazon EBS (Elastic Block Store): Block storage attached to a single EC2 instance. Use for application data that requires low-latency disk I/O (databases, logs). EBS volumes are AZ-specific — if you deploy across AZs, each instance needs its own EBS volume. Snapshots enable cross-AZ/cross-region copying.
Amazon EFS (Elastic File System): Shared NFS file system accessible from multiple EC2 instances simultaneously. Use when multiple instances need access to the same files (shared config, uploaded content, CMS media). EFS works across AZs within a region.
Amazon S3: Object storage for deployment packages, static assets, and artifacts. CodeDeploy pulls deployment bundles from S3. CloudFront serves S3 content to end users. Not suitable for random read/write workloads (no file locking, high-latency for small files).
| Pattern | Storage | When to Use |
|---|---|---|
| Deployment artifacts | S3 | CodeDeploy bundles, CloudFormation templates |
| Shared application data | EFS | Multi-instance web apps, CMS content |
| Instance-local data | EBS | Databases, application logs, scratch data |
| Static website hosting | S3 + CloudFront | Frontend assets, SPAs |
Exam Trap: During Blue/Green deployments, the new instances don't automatically get the same EBS data as the old ones. If your application stores state on EBS, you need a data migration strategy (EBS snapshots, application-level replication, or better — move state to RDS/DynamoDB/EFS). This is a common reason Blue/Green deployments fail for stateful applications.
