Block, file and hybrid storage, lifecycle rules and backup

One machine, or many

The question that sorts these services is how many machines need the same data at the same moment. An EBS volume lives in one Availability Zone and normally attaches to one instance; Multi-Attach exists, but it is limited to certain volume types within one zone and still requires a cluster-aware file system to be safe. So three instances spread across three zones, all writing one uploads directory with ordinary file permissions, is not a volume problem at all.

Amazon EFS is the answer to that shape: a managed NFS file system that many instances mount simultaneously across zones, growing and shrinking as files come and go. Amazon FSx is the same idea for file systems people already depend on — FSx for Windows File Server provides SMB shares with Active Directory integration, which is the right answer to the identical question asked about a Windows fleet, and FSx for Lustre is the high-performance option for computing clusters. If more than one machine must see the same files at once, you want a file system, not a volume.

Keeping the local interface, moving the capacity

AWS Storage Gateway is an appliance that runs IN YOUR BUILDING and is the only service in this objective that does. It presents a familiar interface locally, caches recently used data on local disk so that working with it feels local, and keeps the full dataset in AWS. That combination is what a stem describes when it says editors need local speed, the archive should live in S3, the on-premises array should shrink, and working over the wide-area link has already been tested and rejected.

The near misses are worth naming because each is right for a different question. A nightly script that copies finished work to S3 is a backup, not a storage tier: the local array still has to hold everything. FSx for Lustre is a high-performance file system that links to S3 but runs in AWS, so it puts nothing in the building. AWS Snowball physically moves a large dataset once, when the network is the constraint; it is a migration device, not an ongoing path.

Backups: what takes them, and where they stay

EBS snapshots are the backup mechanism for a volume: incremental after the first, stored durably by AWS, and the standard way to move a volume between Availability Zones. The property that decides recovery questions is that a snapshot is stored IN THE REGION where it was taken, so an event that removes the Region removes the volumes and their snapshots together. Copying the snapshot to a second Region is a separate, deliberate action, and a recovery plan that does not name it is a plan to lose the backups with the primary. Encrypting the volume does not help; encryption protects confidentiality, not existence.

AWS Backup is the service for the auditor's version of this question. It centralises backup plans, schedules, retention and vaults across the AWS services it supports — EBS volumes, RDS databases, DynamoDB tables, EFS file systems and more — applies them by tag or by resource, and reports on whether the policy was actually followed. Three things are easy to confuse: AWS Backup manages backups OF resources by policy, an S3 lifecycle rule manages objects INSIDE one bucket, and a snapshot is the mechanism for one volume. A question naming several different services and one policy is AWS Backup every time.