AWS Basics · Lesson 424 min read

Storage: S3, EBS, EFS & Databases

Storage comes in three shapes. Learn the shapes once and every AWS data service slots into place, then lock it down and keep the bill flat.

From your mentor

Beginners drown trying to memorise services. Don't. There are only three shapes of storage, block, file, object, and each AWS service is just one of them. Get the shapes, and the rest is detail.

AWS storage is just three shapes, and once you know the shapes, every data service slots in.

In 10 minutes you’ll know which shape to use. You do NOT need every S3 storage class yet.

Pick your way in, same idea, 5 doors

Three ways to keep data: a hard drive attached to one computer (EBS), a shared folder many computers open at once (EFS), and an endless bucket you toss files into by name (S3). You pick by how you need to reach it.

Next: the default that keeps an S3 bucket private and encrypted from the very first byte.
01

The three shapes of storage

Every storage service on AWS is one of three shapes. Tell them apart and you'll always know which service you actually need.

Amazon EBS

Block

A raw disk attached to one machine.

Like the hard drive inside a laptop, one computer, fast, low-level.

Amazon EFS

File

A shared folder many machines mount at once.

Like the network drive at an office, everyone sees the same files.

Amazon S3

Object

Files addressed by name over HTTP, near-infinite scale.

Like a giant valet: hand it a file, get a ticket (the key) to fetch it later.

In plain English

Think of a hotel. Block (EBS) is the safe bolted inside one room, fast, private to that guest. File (EFS) is the shared supply closet every room can open. Object (S3) is the bell desk: you hand over a bag, get a ticket, and collect it from anywhere later. Same “storage,” totally different jobs.
02

S3, the internet’s hard drive

S3 stores objects (files) in buckets, addressed by a key. It scales without limit and is the backbone of almost every AWS architecture.

A bucket is a globally-unique namespace; an object is your file plus metadata; the key is its full name (e.g. photos/2026/cat.jpg). There are no real folders, the “/” is just part of the key.

Eleven nines of durability

Every S3 class is designed for 99.999999999% durability, store 10 million objects and you’d expect to lose one roughly every 10,000 years. What changes between classes isn’t safety; it’s access speed, availability, and cost.

That trade-off is the whole game. Pick the class that matches how often you’ll actually read the data:

Hot · frequentcheaper to store, slower / costlier to read → Cold · archive

S3 Standard

Hot data accessed often

Intelligent-Tiering

Unknown / changing access, auto-moves tiers

Standard-IA

Infrequent but needs instant access (backups)

One Zone-IA

Infrequent + re-creatable (single AZ, cheaper)

Glacier Instant Retrieval

Archive you still read in real time (~quarterly)

Glacier Flexible Retrieval

Archive, retrieve in minutes/hours (~yearly)

Glacier Deep Archive

Cheapest, compliance / cold archive (<1×/yr)

Let lifecycle rules do it for you

You rarely choose a cold class by hand. Upload to Standard, then a lifecycle ruleauto-transitions objects to IA → Glacier as they age, or use Intelligent-Tieringand let S3 move them based on real access. (You’ll add a lifecycle rule in your task list.)
03

Locking down a bucket

The leaked-S3-bucket is the most famous breach on the internet. Here's the climb from that disaster to a properly private bucket.

Careful here

Almost every “millions of records exposed” headline is the same root cause: a public S3 bucket. It’s so common that AWS now blocks public access by default, but you still need to understand why, because one wrong policy can switch it back on.
S3 bucketthe climb
  1. Rung 0 · Naive

    Public bucket (imagine the guardrail off)

    Turn off Block Public Access or attach a policy that allows *, anyone on the internet can list and read your objects.

    This is the classic data breach. Open buckets have leaked medical records, backups, and credentials at scale.
  2. Better

    Block Public Access on + explicit grants

    Keep Block Public Access enabled; grant only specific IAM principals or services via a bucket policy.

    No accidental exposure, access is allow-listed, never open to the world.
  3. Best practice today

    Private + encrypted + least privilege

    BPA on, default SSE encryption (or SSE-KMS), a TLS-only bucket policy, scoped IAM, and a VPC endpoint for private access.

    Defense in depth: encrypted at rest and in transit, reachable only by exactly who needs it, provably private.

AWS already moved you up the ladder

Since 2023, new buckets get Block Public Access ON and ACLs disabled by default, and since Jan 2023 every new object is encrypted with SSE-S3 automatically. You start near Rung 2, your job is to not climb back down, and to reach Rung 3.
04

EBS, the disk for your EC2

Elastic Block Store is a network-attached disk for a single EC2 instance. You pick a volume type by how much speed (IOPS) or throughput you need.

gp3Default

General Purpose SSD

Baseline 3,000 IOPS / 125 MB/s · scale to 80k / 2,000

The default. Boot disks, most apps & databases.

io2 Block Express

Provisioned IOPS SSD

Up to 256,000 IOPS · 99.999% durable

Mission-critical, IOPS-hungry databases.

st1

Throughput HDD

Up to 500 MB/s · big sequential reads

Big streaming: logs, data warehouses.

sc1

Cold HDD

Lowest cost · up to 250 MB/s

Rarely accessed, cost-sensitive bulk data.

In plain English

Don’t overthink it: gp3 is the right answer ~90% of the time. Reach for io2 only when a database is genuinely starved for IOPS, and the HDDs (st1/sc1) only for big, cheap, sequential data. Start at gp3 and change only if a metric tells you to.

The disk outlives the instance, and keeps billing

An EBS volume is billed per provisioned GB-month even while the instance is stopped, and can linger after termination unless “delete on termination” is set. Snapshots (incremental backups to S3) are a separate charge. This is a top source of a creeping bill.
05

EFS, a shared drive that grows itself

Elastic File System is a fully-managed NFS file share. Many instances mount it at once, and it grows and shrinks automatically, you never provision size.

The one question that decides EBS vs EFS: does more than one machine need the same files at the same time? If yes, EFS. If it’s one instance’s own disk, EBS.

EBS (block)EFS (file)
Attached toOne instance at a timeMany instances at once
CapacityYou provision the sizeElastic, grows/shrinks automatically
Spans AZsSingle AZ (snapshot to move)Multi-AZ by default
Reach for itBoot disk, a database’s own volumeShared content, uploads, lift-and-shift apps
06

RDS vs DynamoDB, managed data stores

When you need a database (not just files), AWS runs it for you two very different ways. The choice is relational vs NoSQL, and how you want to scale.

Amazon RDS

Managed relational database

Model
Relational (SQL), tables, joins, transactions
Engines
PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Aurora
You pick
An instance size; AWS manages backups, patching, Multi-AZ failover
Scales
Vertically + read replicas; you plan capacity
Best for
Structured data, complex queries, strong consistency
vs

Amazon DynamoDB

Serverless NoSQL

Model
NoSQL, key-value & document
Serverless
No instances; single-digit-ms at any scale
You pick
On-demand (pay per request) or provisioned capacity
Scales
Automatically, effectively without limit
Best for
High-throughput, known access patterns, huge scale
?

Worth pondering

Rule of thumb: if you’d naturally write SQL with joins and your data is structured, start with RDS (Aurora for serious scale). If you have a known access pattern at huge throughput, a key you look things up by, DynamoDB gives single-digit-millisecond reads at any size with zero servers to manage.
07

What storage actually costs

Storage looks cheap per GB, the surprises come from requests, retrievals, transfer out, and minimum durations. Know the five dials.

Cost pieceHow it billsBeginner trap
StoragePer GB-month, varies by classCold classes are cheap to store…
RequestsPer 1,000 PUT/GET/LIST, varies by classMillions of tiny requests add up
RetrievalPer GB for IA & Glacier classes…but expensive + slow to read back
Data transfer out~$0.09/GB to the internet (in is free)The silent biggest line item
Early deleteMin-duration charge (30/90/180 days)Deleting Glacier early still bills the minimum

The mental model

Hot classes: cheap to read, pricier to store. Cold classes: dirt-cheap to store, pricey + slow to read. Match the class to how often you’ll actually touch the data, and let lifecycle rules handle the rest.
08

How this shows up in interviews

Interview angle

“How would you store user-uploaded files for a web app, and keep them secure and cheap?”

How to answer it

Pick the shape first (object → S3), then talk security defaults and a lifecycle/cost plan. Naming durability vs availability vs class shows depth.

  1. 1Uploads are objects, so S3, not a disk (EBS) or a database blob.
  2. 2Keep Block Public Access on; serve files via CloudFront or pre-signed URLs, never a public bucket.
  3. 3Rely on default SSE-S3 encryption (or SSE-KMS for stricter control), and a TLS-only bucket policy.
  4. 4Start in S3 Standard; add a lifecycle rule to move cold objects to Standard-IA then Glacier, or use Intelligent-Tiering.
  5. 5Watch data-transfer-out and request costs, not just per-GB storage.

Green flags

  • Picks the storage shape before the service
  • Never reaches for a public bucket
  • Knows durability ≠ availability ≠ cost class

Red flags

  • Stores uploads in a database or on the instance disk
  • Makes the bucket public “to keep it simple”
  • Picks Glacier for hot data to “save money”

Q.Durability vs availability in S3?

A.Durability = will it ever be lost (11 nines); availability = can you reach it right now.

Durability
Availability
“Will my data ever be lost?”
“Can I reach it this second?”
11 nines across all classes
Standard 99.99%, One Zone-IA 99.5%
Glacier: just as durable
Glacier: minutes-to-hours to retrieve

They’re checking: That you don’t mistake Glacier’s slow retrieval for “less durable”.

Q.EBS or EFS for this workload?

A.One instance’s disk = EBS; many instances sharing files = EFS; just blobs over HTTP = neither, use S3.

EBS
EFS
Block, single-AZ
File (NFS), multi-AZ
One instance at a time
Many instances at once
Fixed-size volume
Elastic, grows automatically

They’re checking: That you map access pattern to shape, and know when it’s actually S3.

Q.When DynamoDB over RDS?

A.DynamoDB for known key-based access at high throughput; RDS for relational data, joins, and transactions.

DynamoDB
RDS
Key/value, known access pattern
Relational, joins, ad-hoc queries
Serverless, single-digit-ms at any scale
Vertical scaling + read replicas
Per-item, eventual or strong reads
Strong transactional consistency

They’re checking: That you pick by access pattern, not “NoSQL is modern”.

Q.A bucket’s objects are encrypted, are you done on security?

A.No, encryption at rest is on by default but it doesn’t stop a public bucket from leaking.

  • Keep Block Public Access on, and use a least-privilege bucket policy.
  • Require TLS (aws:SecureTransport), and ideally reach it via a VPC endpoint.

They’re checking: That you know SSE ≠ “secure”, exposure is a separate axis.

09

Your turn, a real, private bucket

Create a bucket, prove it's locked down, upload to it, and set it to auto-archive. About 15 minutes, inside the Free Tier.

Now do it in your own account

~15 min $0, within the S3 Free Tier (5 GB)

As your IAM admin user, create a private bucket, prove it’s locked down, upload to it, and set it to auto-archive. Stays inside the S3 Free Tier.

Before you start

3 to have ready

Your IAM admin user from Lesson 1.

AWS CLI v2 signed in.

aws sts get-caller-identity

A small file to upload (e.g. hello.txt) and a globally-unique bucket name like yourname-aws-basics-2026.

  1. 1

    Create a bucket.

    Free tier

    Your terminal

    aws cli
    $ aws s3 mb s3://yourname-aws-basics-2026
    AWS docs: s3 mb

    You should see: the bucket is created, with Block Public Access on by default.

  2. 2

    Confirm public access is fully blocked.

    Free tier

    Your terminal

    aws cli
    $ aws s3api get-public-access-block --bucket yourname-aws-basics-2026
    AWS docs: get-public-access-block

    You should see: all four flags are true.

  3. 3

    Upload a file, it’s encrypted with SSE-S3 automatically.

    Free tier

    Your terminal

    aws cli
    $ aws s3 cp ./hello.txt s3://yourname-aws-basics-2026/
    AWS docs: s3 cp

    You should see: the object lists in the bucket, encrypted at rest.

  4. 4

    Add a lifecycle rule that moves objects to Glacier after 30 days.

    Free tier

    Your terminal (or Console → bucket → Management → Lifecycle)

    aws cli
    $ aws s3api put-bucket-lifecycle-configuration --bucket yourname-aws-basics-2026 --lifecycle-configuration file://lifecycle.json
    AWS docs: put-bucket-lifecycle-configuration

    You should see: the rule appears under the bucket’s Management → Lifecycle.

Last step: tear it down

Once you’ve seen it work, remove everything so nothing keeps billing.

Empty and delete the bucket so nothing lingers.

aws s3 rb s3://yourname-aws-basics-2026 --force

S3 Free Tier covers 5 GB of Standard storage; a tiny test file is well within it.

Deleting from Glacier before its minimum duration still bills the minimum, fine for one tiny test file.

Next up

Next, Networking & VPC

CIDR, subnets, route tables, and security groups vs NACLs, the foundations you need before placing any service inside a VPC.