The four ways AWS stores your data, and how to actually choose between them

Picking a storage service on AWS isn't really about picking a service. It's about answering a handful of questions first: how the data will be accessed, whether it needs to persist independently of any single machine, whether multiple instances need to share it, and how much durability the use case actually demands. Once those are answered, the right service is usually obvious. Skip that step, and you end up choosing based on which name sounds familiar.

Everything here lives inside the same foundation: a Virtual Private Cloud, your own isolated network within AWS, divided into subnets that segment your address space and host the resources that actually use this storage.

Object storage: S3, for data you address by name, not by location

Amazon S3 is one of AWS's oldest and most fundamental services, and it works differently from a traditional file system. Data lives as objects, each with its own key and metadata, inside buckets that require globally unique names. That structure is what makes S3 so versatile: it handles database and application backups, long-term archiving for legal or historical records, static website hosting, big datasets processed by services like EMR or Athena, and content distribution for web and mobile applications, all through the same object model.

The numbers behind it are worth knowing specifically. S3 is built for eleven nines of durability, 99.999999999%, meaning that out of ten million stored objects, you'd expect to lose roughly one every ten thousand years, achieved by redundantly storing data across multiple devices and Availability Zones. Availability sits at 99.99%. Scalability is effectively unlimited, with no advance provisioning required, and security comes from strong access controls, encryption both at rest and in transit, and direct integration with IAM.

S3 also lets you tune cost against access pattern through its storage classes. S3 Standard is the default for frequently accessed, latency-sensitive data. S3 Standard-IA costs less but charges more on retrieval, suited to data you don't touch daily but need quickly when you do. S3 One Zone-IA goes cheaper still by sacrificing multi-AZ resilience, appropriate only for non-critical data where losing an Availability Zone is an acceptable risk. Glacier Instant Retrieval covers long-lived, rarely accessed data that still needs millisecond retrieval. Glacier Flexible Retrieval is for archival data with retrieval measured in minutes to hours. Glacier Deep Archive is the cheapest tier of all, built for seven-to-ten-plus year retention with retrieval times measured in hours, ideal for compliance archives. And S3 Intelligent-Tiering handles the case where you genuinely don't know the access pattern in advance, automatically shifting objects between tiers as usage reveals itself.

A handful of features round out the object model: Versioning protects against accidental overwrites and deletions, Lifecycle Policies automate the transitions between storage classes or eventual deletion, Transfer Acceleration speeds up long-distance uploads using CloudFront's edge network, Multipart Upload improves throughput and resilience for large files, and Cross-Region Replication automatically copies objects to another region for disaster recovery or reduced latency elsewhere.

Block storage: EBS, for data tied to a specific instance

Amazon EBS behaves like a raw, unformatted hard drive attached directly to an EC2 instance, one you format and mount like local disk. Unlike the instance's own ephemeral storage, an EBS volume persists independently: terminate the instance, and the volume can remain. The one hard constraint is that a volume is tied to a specific Availability Zone, and it can only attach to an instance in that same zone.

EBS comes in volume types optimized for different workloads: SSD-backed options (gp2, gp3, io1, io2 Block Express) suit transactional workloads, boot volumes, and frequently accessed data, while HDD-backed options (st1, sc1) fit throughput-heavy workloads like big data or log processing. Snapshots provide incremental, point-in-time backups stored durably in S3. Encryption covers both volumes and their snapshots. Multi-Attach, available only on io1 and io2 Block Express volumes, allows a single volume to attach to multiple instances within the same Availability Zone for genuinely shared access. And volumes can be resized or have their type changed without ever detaching them from a running instance.

File storage: EFS and FSx, for data multiple instances need to share

When more than one instance needs concurrent access to the same files, block storage stops being the right model. Amazon EFS provides a shared file system over NFS that multiple EC2 instances can access at once, growing and shrinking automatically without advance provisioning. It's a regional service, meaning instances across different Availability Zones within the same region can reach the same file system, which makes it a natural fit for lift-and-shift enterprise applications, content management systems, shared home directories, and big data workloads that need concurrent file access.

Amazon FSx covers the cases EFS doesn't: fully managed third-party file systems for specific ecosystems. FSx for Windows File Server provides SMB-accessible file servers for Windows-based applications. FSx for Lustre is a high-performance system built for compute-intensive work like HPC, machine learning, and media processing. FSx for NetApp ONTAP brings managed NetApp file systems for enterprise applications that need advanced data management. FSx for OpenZFS serves Linux, Windows, and macOS workloads on an open-source file system. Each trades general-purpose flexibility for deep compatibility with a specific ecosystem's expectations.

The bridge back to on-premises: AWS Storage Gateway

Not every workload lives entirely in the cloud, and Storage Gateway exists for exactly that boundary: a hybrid service connecting an on-premises appliance to AWS storage, with local caching for frequently accessed data. It comes in three forms. File Gateway stores data as S3 objects while remaining accessible via NFS and SMB on-premises. Volume Gateway provides iSCSI-based block storage backed by EBS snapshots or cached volumes in AWS. Tape Gateway presents a virtual tape library interface for existing backup software, storing the actual tapes in S3 Glacier or Glacier Deep Archive. Together they cover cloud bursting, disaster recovery, data migration, and ongoing hybrid storage needs, without forcing an all-or-nothing move to the cloud.

Matching the service to the actual requirement

Reduced to a decision guide: block storage for a single EC2 instance means EBS, sized and typed to the workload's performance needs. Shared file storage across Linux instances means EFS; the Windows equivalent means FSx for Windows File Server. Durable, scalable storage for websites, backups, or archives means S3, with the storage class chosen by how often that data actually gets touched. Bridging existing on-premises storage into AWS means Storage Gateway. And high-performance computing workloads point specifically toward FSx for Lustre.

None of these choices require memorizing every feature of every service. What they require is starting from the actual shape of the workload, how it's accessed, how durable it needs to be, whether it's shared, and letting that shape point to the service, rather than picking a familiar name and hoping the workload adapts to it.