Storage Services Design: EVS, OBS, SFS, Backup and Archive Tiers
What to know
Pick storage by access pattern and consistency need, not by capacity.
EVS is block storage attached to one ECS in the same AZ. Disk types trade cost against IOPS and throughput - extreme SSD, ultra-high I/O, high I/O, general purpose SSD, common I/O. Volumes can be resized, snapshotted, encrypted with KMS, and some types support shared attachment for clustered applications. Crucially, EVS is AZ-scoped: a volume in AZ1 cannot be attached to an ECS in AZ2.
OBS is object storage: effectively unlimited capacity, HTTP/REST access, bucket policies, versioning, WORM, cross-region replication, and lifecycle rules. Storage classes are Standard, Infrequent Access, Archive, and Deep Archive. Objects in archive tiers must be restored before reading, and retrieval takes time (minutes to hours, longest for Deep Archive). Access from inside a VPC should use a VPC endpoint rather than traversing the internet.
SFS / SFS Turbo provides shared POSIX file storage (NFS/CIFS) mountable by many ECS or containers simultaneously - the right answer for shared content, media rendering, HPC scratch, and Kubernetes persistent volumes with ReadWriteMany.
CBR provides policy-driven, application-consistent backup into vaults, with optional cross-region replication for DR.
Traps
OBS is not a POSIX filesystem - you cannot mount it as a normal disk; use a file-system client or SFS. Snapshots are incremental but a restore is a full restore, and a snapshot in the same AZ is not DR. Deleting an ECS does not necessarily delete its EVS disks, and detached disks still bill. Archive classes reduce storage cost but add retrieval cost and latency - do not put active data in them.
Rule of thumb
Database → EVS. Shared concurrent access → SFS. Unstructured/static/backup → OBS. Then apply a lifecycle rule to tier objects by age.