💾 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 Replication: Read Replica vs Multi-AZ vs Cross-Region Read Replica
| Feature | Main Purpose | Can serve reads? | Replication style | Exam trigger |
|---|---|---|---|---|
| Read Replica | Scale read-heavy workloads | Yes | Usually asynchronous | “Improve read performance” / “offload reporting queries” |
| Multi-AZ DB instance | High availability and automatic failover | No, not in the classic DB instance setup | Synchronous standby replication | “Survive AZ failure” / “automatic failover” |
| Cross-Region Read Replica | Read scaling in another Region + disaster recovery option | Yes | Asynchronous across Regions | “Read closer to users in another Region” / “DR across Regions” / “migration” |
⚠️ Common exam trap
Read Replicas improve read throughput by letting applications send read-only traffic to replica instances.
Multi-AZ improves availability by maintaining a standby copy for failover. In the classic RDS Multi-AZ DB instance setup, the standby is not used for read scaling.
Cross-Region Read Replicas can support both read scaling in another Region and disaster recovery, but failover is not the same automatic in-Region failover behavior as Multi-AZ.
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)