Amazon S3

If user uploads live only on a web server's local disk, file locations become messy the moment you replace that server or scale out to several of them. Without separate backup and sharing paths, a single server failure quickly turns into file loss and broken downloads.

In the past, you had to keep expanding NAS appliances or file servers and manage both capacity and backups yourself. That made scaling and durability cumbersome, which is why object-store models like S3 became the default for cloud file storage.

S3 stores files as objects inside buckets and reads and writes them through HTTP APIs. Storage classes and lifecycle policies can automatically move data across cost tiers based on access frequency, and Object Lock can prevent changes or deletion for a defined period, which is why S3 often sits at the center of CloudFront delivery, Lambda post-processing, and Athena analytics.

S3, EBS, and EFS all store data. The difference is how you access them. EBS is a block disk attached to a single instance, EFS is a shared filesystem mounted by multiple instances, and S3 is an API-based object store that treats files as objects. If the data should be read and written over HTTP without mounting a filesystem, S3 is the right choice.

Well-suited for static web assets, user uploads, backup and recovery, archives, log retention, and data lakes where large volumes of files must be shared across services. Not a good fit when you need a mounted filesystem or a disk attached directly to a server.