AWS Storage Services Explained: S3, EBS, EFS, RDS, DynamoDB

How to choose in 60 seconds

AWS storage services at a glance

When to use each service

Amazon S3#

S3 is AWS’s object storage. You store complete files (images, videos, PDFs, logs, code archives) and retrieve them over HTTP. Every object has a unique key inside a bucket. There are no folders, no file locks, and no partial updates.

Use it when: storing user uploads, serving static website assets, creating a data lake for analytics, or keeping application backups. See the Amazon S3 overview for a full breakdown of how it works.

Do not use it when: you need low-latency block I/O, the ability to update part of a file in place, or database queries on structured data.

Example workload: A web app where users upload profile photos. The app stores each photo in S3 and serves it via CloudFront. S3 handles any volume of uploads without provisioning storage in advance.

Amazon EBS#

EBS (Elastic Block Store) is a virtual hard drive attached to an EC2 instance. The OS mounts it like a physical disk. Databases, application binaries, and OS volumes all sit on EBS.

Use it when: running an EC2 instance (every instance needs a root EBS volume), or self-managing a database like PostgreSQL or MySQL on EC2. See EBS volumes explained for volume types, IOPS provisioning, and snapshots.

Do not use it when: multiple EC2 instances need simultaneous access to the same files. Standard EBS volumes attach to one instance at a time. EBS Multi-Attach is available on io1 and io2 volumes for specific clustered workloads, but it is not a general-purpose shared filesystem solution; use EFS for that.

Example workload: A PostgreSQL database running directly on an EC2 instance. The database files live on an EBS volume that provides consistent, low-latency I/O.

Amazon EFS#

EFS (Elastic File System) is a managed NFS filesystem. Multiple EC2 instances can mount and use it simultaneously, making it the right choice when shared file access is the core requirement.

Use it when: several EC2 instances need to read and write the same files, such as a shared media library for a CMS or a shared configuration directory for a multi-server application.

Do not use it when: only one instance needs the storage. EBS is simpler and cheaper for single-instance workloads. See S3 vs EFS for a direct comparison of when to choose each.

Example workload: A WordPress deployment spread across three EC2 instances behind a load balancer. All three mount the same EFS volume so uploaded media is consistent across every server without custom sync logic.

Amazon RDS#

RDS is a managed relational database service. AWS handles provisioning, patching, backups, and Multi-AZ failover. You get a standard MySQL, PostgreSQL, SQL Server, or Oracle database without managing the OS or storage yourself.

Use it when: your application needs SQL queries, foreign keys, JOINs, transactions, or a well-understood relational data model. For a full introduction see Amazon RDS overview, or jump to running MySQL on RDS or PostgreSQL on RDS.

Do not use it when: you need to scale writes beyond what a single database server can handle, or your access patterns are purely key-based without relational queries.

Example workload: A transactional e-commerce backend. Orders, products, customers, and inventory live in a PostgreSQL schema with foreign keys and multi-table transactions.

Amazon Aurora#

Aurora is AWS’s own relational database engine, protocol-compatible with MySQL and PostgreSQL. It uses a distributed storage layer that maintains six copies of data across three Availability Zones automatically.

Use it when: your production workload needs faster failover than standard RDS (under 30 seconds compared to 60-120 seconds), more than 5 read replicas, storage that auto-scales up to 128TB without manual intervention, or Aurora Global Database for read scaling across regions and disaster recovery.

Do not use it when: you are running a development or staging environment with low traffic. Aurora costs 20-40% more than equivalent standard RDS instances, and the availability benefits do not justify the price at small scale. See RDS vs Aurora for a detailed cost and capability comparison.

Example workload: A SaaS application with thousands of concurrent users and a strict uptime SLA. Aurora ensures failover completes in under 30 seconds and read replicas distribute query load across multiple AZs.

Amazon DynamoDB#

DynamoDB is AWS’s managed NoSQL database. It stores items as key-value or document structures and scales horizontally to any throughput level. There is no SQL, no joins, and no schema enforcement beyond the primary key.

Use it when: you know your access patterns upfront (lookup by user ID, order ID, session token), you need write throughput beyond a single relational database, or your schema changes frequently without migration overhead. See DynamoDB overview for how tables, keys, and throughput modes work.

Do not use it when: you need complex SQL queries, ad hoc reporting, or a highly relational data model with many foreign keys.

Example workload: A gaming application that stores player scores and retrieves leaderboards by game ID. Each lookup is a primary key query; throughput scales automatically with the player count.

Amazon ElastiCache#

ElastiCache is a managed in-memory cache. It supports two engines: Redis (richer data structures, optional persistence, pub/sub) and Memcached (simpler, multi-threaded). Reads happen in microseconds, not milliseconds.

Use it when: reducing repetitive database queries, storing session tokens, maintaining rate-limit counters, or building a pub/sub messaging layer.

Do not use it when: you need durable primary storage.

Example workload: An API server that fetches the same product catalogue for hundreds of requests per second. ElastiCache stores the database query result in memory and serves it for a configurable TTL, eliminating repeated database load.

S3 Glacier and S3 Glacier Deep Archive#

S3 Glacier tiers live inside S3 but are designed for data you almost never need. Retrieval takes minutes to hours depending on the tier. The trade-off: storage costs as low as $0.00099 per GB/month for Deep Archive.

Use it when: archiving compliance records, old audit logs, cold backup copies, or any data where regulatory requirements demand retention but retrieval will be rare. Use S3 lifecycle policies to move objects to Glacier tiers automatically as they age, and S3 storage classes to understand when each tier makes financial sense.

Do not use it when: you need fast retrieval. Restore times range from minutes (Expedited) to up to 12 hours (Bulk retrieval in Deep Archive).

Example workload: A fintech company must retain transaction logs for seven years under financial regulations. Active logs stay in S3 Standard for 90 days, then a lifecycle rule moves them to S3 Glacier Deep Archive for long-term retention at minimal cost.

How it works: the storage model behind each service

AWS storage services fall into six categories. Understanding the category helps you choose the right service quickly.

Object storage (S3, S3 Glacier): Data is stored as discrete objects identified by a key. You read or write whole objects at once. There is no filesystem, no file locking, and no in-place editing. Suitable for large volumes of unstructured data: files, backups, media, data lakes.

Block storage (EBS): The OS sees a raw disk device and manages the filesystem itself. Reads and writes happen at the block level, enabling the low-latency random I/O that databases and operating systems require. The disk attaches directly to a compute instance.

Shared file storage (EFS): A network filesystem (NFS) that multiple instances mount simultaneously. It provides standard filesystem semantics (directories, permissions, file locking) and scales storage automatically without pre-provisioning.

Relational databases (RDS, Aurora): A fully managed SQL database engine. Data is structured into tables with rows and columns, related by foreign keys. Supports ACID transactions, complex queries, and JOINs. AWS manages patching, backups, and infrastructure.

NoSQL databases (DynamoDB): Data is stored as items in a table, each identified by a primary key. No schema enforcement beyond the key, no SQL, no joins. Designed for predictable, high-throughput access at any scale.

In-memory cache (ElastiCache): Data lives in RAM for sub-millisecond reads. It sits in front of a slower, durable data store rather than replacing one. Data persistence is optional and requires explicit configuration.

Archive storage (S3 Glacier): An object storage tier optimised for rarely accessed data. Very low storage cost in exchange for slow, sometimes asynchronous retrieval.

Real-world use cases

User-uploaded images, PDFs, videos Store in S3. Return a pre-signed URL or CloudFront URL to the client. Do not proxy large files through your application server.

Static website or frontend assets (HTML, CSS, JS) S3 with CloudFront in front. S3 hosts the files; CloudFront caches them globally and terminates HTTPS. This costs very little at moderate traffic.

EC2 boot volume EBS (General Purpose SSD, gp3 by default). Every EC2 instance requires an EBS root volume. Choose gp3 for most workloads; io2 when databases need high, consistent IOPS.

Database running directly on EC2 EBS. Self-managed PostgreSQL or MySQL on EC2 stores data files on an EBS volume. If you do not want to manage the database yourself, use RDS instead.

Shared media files across multiple EC2 instances EFS. A content management system spread across multiple EC2 instances behind a load balancer needs a single shared location for user-uploaded content. EFS provides this without custom synchronisation logic.

Transactional web application database RDS (PostgreSQL or MySQL). Orders, accounts, and inventory benefit from SQL, transactions, and foreign keys. Enable Multi-AZ for production. RDS handles patching, backups, and failover.

High-throughput session storage, shopping cart, or leaderboard ElastiCache (Redis) for pure speed, or DynamoDB if you need the data to survive a cache flush. ElastiCache is faster but is not a durable store by default; DynamoDB is durable but slightly slower than in-memory.

Analytics and data lake workloads S3 as the storage layer, queried by Athena, Glue, EMR, or Redshift Spectrum. Store data in Parquet or ORC format for efficient columnar queries. See data warehouses vs data lakes for how to structure the broader architecture.

Long-term compliance archive S3 Glacier Deep Archive with Object Lock (WORM mode). Set a lifecycle policy to transition objects automatically. At $0.00099 per GB/month, this is the cheapest storage in AWS.

Key comparisons

S3 vs EBS vs EFS#

For a deeper breakdown, see S3 vs EFS compared.

RDS vs Aurora vs DynamoDB#

For a full comparison, see RDS vs DynamoDB and RDS vs Aurora.

DynamoDB vs ElastiCache for sessions and caching#

Both can store session tokens and shopping cart data. The difference is durability versus speed.

DynamoDB persists data to disk. If your application restarts or a cache layer is cleared, session data survives. TTL is supported natively, so expired sessions delete themselves. Reads take single-digit milliseconds.

ElastiCache (Redis) keeps data in memory. Reads are sub-millisecond. Data can be lost if a node is replaced and persistence is not configured. Redis supports optional persistence and replication, but it is primarily a cache layer, not a durable database.

Use ElastiCache when speed is the priority and session loss on node failure is acceptable. Use DynamoDB when you need durable session storage and can tolerate slightly higher latency.