💾 EBS vs EFS vs S3 — How Does Your App See the Storage?
EBS — Elastic Block Store
Acts like a hard drive plugged into your EC2 instance. One instance, one AZ. Your OS formats and mounts it. Data persists after stop.
🧠 Think: "My server's hard drive"
EFS — Elastic File System
Acts like a shared network drive. Multiple EC2 instances across multiple AZs can mount it simultaneously. Auto-scales, no capacity to manage.
🧠 Think: "Shared folder that all my servers can access"
Unlike Storage Gateway File Gateway, EFS is a true managed cloud file system — not a hybrid bridge into S3.
S3 — Simple Storage Service
Not a file system — an object store. You don't mount it, you call an API (PUT, GET). Flat blobs with URL keys. Massive scale, globally accessible, cheap.
🧠 Think: "A giant bucket of files accessible over the internet"
| 📋 Quick pick |
| Temp files on one server → EBS · Shared config files across servers → EFS · User photos accessible anywhere → S3
|
General Purpose SSD (gp3)
AWS-recommended EBS volume type for most workloads.
- SSD-backed
- balanced price/performance
- supports boot volumes
| 📋 Exam trigger words |
| "recommended EBS volume for most workloads" · "boot volume" → gp3 |
⚡ Instance Store — The One Everyone Forgets (And It's the Fastest)
Every EC2 host machine has real physical disks attached to it. Instance Store lets your instance use those disks directly — no network hop, just raw disk. EBS feels local but still goes over the network. That's why Instance Store wins on speed.
The catch: data only exists while the instance runs. Stop it, terminate it, or if the hardware fails — gone. Not a debate, just gone.
It's included in the EC2 instance price — no extra charge.
Instance Store = ephemeral BLOCK storage physically attached to the host server.
| 📋 Exam trigger words |
| "fault-tolerant" · "can handle failures" · "distributed architecture" · "highest I/O performance" · "lowest latency storage" → Instance Store
|
| ⚠️ Common exam trap |
| Instance Store offers the highest performance and lowest latency, but NOT durability. If the instance stops or fails, the data is lost permanently. |
AMI vs Snapshot
| Resource |
Purpose |
| AMI |
Launch template for EC2 instances |
| EBS Snapshot |
Backup of EBS volume data |
Golden AMI = standardized EC2 image with:
- OS
- patches
- monitoring agents
- application configuration
Exam trigger: "exact copy of EC2 instance in another region" → AMI copy
RDS Read Replicas vs Multi-AZ
| Feature |
Purpose |
| Read Replicas |
Scale read-heavy workloads |
| Multi-AZ |
High availability and failover |
| ⚠️ Common exam trap |
| Read Replicas improve read throughput. Multi-AZ improves availability, NOT read scaling. |
Data Protection, Migration & Storage Services
| Service |
Does what |
Analogy |
Trigger words |
| AWS Backup |
Centralized automated backups across ALL AWS services and on-premises |
The automated backup janitor who never forgets |
"centralize backups" "automate backup policy" "across services" |
| Elastic Disaster Recovery |
Continuously replicates live servers for rapid failover |
The understudy ready to go on stage instantly |
"disaster recovery" "minimal data loss" "failover" "RPO/RTO" |
| DataSync |
Transfers and migrates data between storage systems |
The moving truck for your data |
"migrate data" "transfer to AWS" "sync on-premises to S3" |
| Storage Gateway |
Lets on-premises systems use AWS storage as if it were local |
The magic portal that makes cloud look local |
"hybrid storage" "on-premises access to cloud" "replace tape backups" |
| Snowball Edge |
Physical device for massive data transfer when network is impractical |
The armored truck when the internet highway is too slow |
"terabytes to petabytes" "physical transfer" "no internet" "rugged" |
Aurora — The "Self-Healing" Database
Aurora automatically:
- replicates storage 6 ways across 3 AZs
- repairs failed storage blocks automatically
- provides high availability relational storage
| 📋 Exam trigger words |
| "self-healing relational database" · "high throughput relational database" → Aurora |
| ⚠️ Common exam trap |
| DynamoDB is highly fault tolerant and auto-scaled, but AWS usually reserves the term "self-healing" for Aurora's distributed relational storage architecture. |
Storage Gateway — Three Flavors
| Flavor |
Presents as |
Stores to |
Use when |
| File Gateway |
NFS/SMB network file share |
S3 |
Replace on-premises file servers |
| Volume Gateway |
iSCSI block storage that looks like a local disk to servers |
S3 + EBS snapshots |
Extend or back up on-premises block storage into AWS |
| Tape Gateway |
Virtual tape library that emulates traditional backup tapes |
S3 / Glacier |
Replace physical tape backup systems without changing backup software |
The Storage Gateway mental model:
Your on-premises servers think they're writing to local storage.
They're actually writing to AWS.
The gateway handles the translation invisibly.
| ⚠️ Common exam trap |
| EFS is a native cloud file system. File Gateway is a hybrid bridge between on-premises systems and S3. |
| 🧠 The key distinction |
|
File Gateway = shared files/folders (SMB/NFS). |
|
Volume Gateway = raw disks/block storage (iSCSI). |
|
Tape Gateway = virtual tapes for legacy backup software. |
Key Distinctions Q&A
| Question |
Answer |
| Need to back up AWS resources centrally? |
AWS Backup |
| Need servers to keep running if disaster hits? |
Elastic Disaster Recovery |
| Need to move data to AWS once or regularly? |
DataSync |
| Need on-premises servers to use AWS storage daily? |
Storage Gateway |
| No internet, massive data, physical shipment? |
Snowball Edge |
The trap: Elastic Disaster Recovery sounds like backup — it's not.
It replicates LIVE systems for failover, not periodic backup copies.
Reserved vs Dedicated — Completely Different Concepts
Reserved = a PRICING decision
You commit to 1 or 3 years → AWS gives you up to 72% discount.
Hardware is still shared with other AWS customers.
Dedicated = a HARDWARE decision
You get physically isolated servers.
Other AWS customers cannot run workloads on your hardware.
Exists for compliance requirements and software licensing.
They are independent — you can mix and match:
| Combination |
Means |
| Reserved + Shared hardware |
Normal Reserved Instance — discount only |
| Reserved + Dedicated hardware |
Commit AND get physical isolation |
| On-Demand + Dedicated hardware |
Dedicated Instance/Host, no commitment |
Dedicated Instance vs Dedicated Host
|
Dedicated Instance |
Dedicated Host |
| Hardware dedicated to you |
✅ |
✅ |
| You know WHICH server you're on |
❌ AWS picks |
✅ You choose |
| Visibility into sockets/cores |
❌ |
✅ |
| Bring your own license (BYOL) |
❌ |
✅ |
| Cost |
Lower |
Higher |
| Use when |
Need dedicated hardware for compliance |
Need specific server for BYOL licensing |
The one sentence: Reserved = discount for commitment.
Dedicated = physical isolation for compliance or licensing.
You can mix and match them.
Exam trigger: "existing server-bound software licenses" + "compliance" → Dedicated Host
Exam trigger: "dedicated hardware" without licensing mention → Dedicated Instance
Trigger: "existing server-bound software licenses" + "compliance" → Dedicated Host
| ⚠️ Common exam trap |
| Dedicated Hosts provide isolated AWS hardware in AWS data centers. AWS Outposts extends AWS infrastructure into YOUR on-premises environment. |
EC2 Instance Purchasing Decision Tree
| Scenario |
Choose |
| Short term, uninterruptible |
On-Demand |
| Long term 1-3 years, predictable |
Reserved |
| Fault-tolerant, can be interrupted |
Spot |
| Dedicated hardware, BYOL licensing |
Dedicated Host |
| Dedicated hardware, compliance only |
Dedicated Instance |
| Long-term compute across EC2 + Lambda + Fargate |
Compute Savings Plans |
| ⚠️ Common exam trap |
| Reserved Instances apply mainly to EC2. Compute Savings Plans also cover Lambda and Fargate with more flexibility. |
EC2 Launch Requirements
| Required |
Optional |
| Security Group |
Elastic IP |
| VPC and Subnet |
Key pair (if no other access method) |
| EBS Root Volume |
Additional EBS volumes |
| AMI |
Instance store volumes |
🚧 ELB vs Auto Scaling — The Most Common Scaling Mix-up
| Service |
Main job |
| Elastic Load Balancer (ELB) |
Distributes incoming traffic across targets |
| EC2 Auto Scaling |
Adds/removes EC2 instances based on demand |
| 💡 Mental model |
| ELB spreads traffic across servers. Auto Scaling changes how many servers exist. |
| ⚠️ Common troubleshooting clue |
| If traffic is not reaching instances behind a load balancer, first check the ELB Health Checks. Unhealthy targets receive no traffic. |
Lightsail vs Elastic Beanstalk
| Service |
Best for |
| Lightsail |
Simple VPS/WordPress hosting |
| Elastic Beanstalk |
Managed application deployment |
Trigger: "easiest WordPress deployment with minimal AWS knowledge" → Lightsail
AWS SDKs
Used for authenticated programmatic access to AWS from application code.
SDKs handle:
- request signing
- credential resolution
- IAM role integration
- automatic credential refresh
| ⚠️ Common exam trap |
| SDKs are for runtime application access. CloudFormation provisions infrastructure. |
Global Gaming / Low-Latency Architecture
| Problem |
Best Solution |
| High latency for players in other continents |
Deploy servers closer to users in additional regions |
| ⚠️ Common exam trap |
| CloudFront helps static content delivery, NOT real-time multiplayer server latency. |
Top comments (0)