S3, EBS & EFS
Object/block/file storage and S3 classes.
AWS offers distinct storage services for distinct access patterns, and choosing correctly is a frequent architecture decision. The three core building blocks are object storage (S3), block storage (EBS), and file storage (EFS).
S3 object storage and its classes
Amazon S3 is highly durable (eleven nines) object storage accessed over HTTPS APIs — ideal for files, backups, data lakes, and static website assets. Its power for cost optimization is storage classes: S3 Standard for frequently-accessed data, Standard-Infrequent Access for cheaper storage with a retrieval fee (still millisecond access), Intelligent-Tiering to move objects automatically based on access, and Glacier / Glacier Deep Archive for very cheap archival where retrieval takes minutes to hours. Lifecycle rules transition objects to colder tiers or expire them on a schedule, so you pay less for data you rarely touch without manual work.
# NEED SERVICE# store objects/files, durable, HTTPS → S3 (object)# a disk for ONE instance (in one AZ) → EBS (block, persistent)# fast scratch, lost on stop → EC2 instance store (ephemeral)# shared POSIX file system, many hosts → EFS (elastic NFS, multi-AZ)## S3 classes: Standard → Standard-IA → Intelligent-Tiering → Glacier → Deep Archive# (hot, instant) (cold, minutes–hours)
EBS and EFS
Amazon EBS provides persistent block storage — a virtual disk attached to a single EC2 instance within one AZ, surviving stop/start (unlike the ephemeral instance store, which is lost on stop). Snapshot EBS volumes to S3 for backup and cross-AZ/Region recovery. When multiple instances need a shared file system, Amazon EFS is a managed, elastic NFS that many instances across AZs can mount concurrently. The rule of thumb: S3 for objects and unstructured data, EBS for a single instance’s disk, EFS for shared POSIX access, and instance store only for temporary scratch. Matching the service to the access pattern is both a performance and a cost decision.