Introduction
In Day 13, I explored how Amazon S3 changed the way I think about storage - versioning, lifecycle policies, encryption, and automation taught me that data durability is the backbone of cloud systems.
But as my sandbox grew into a multi-instance setup, I faced a new reality:
S3 alone cannot solve all storage needs.
Some data must live with compute.
Some must be shared across servers.
Some must be queried.
Some must be protected.
And some must be delivered globally with low latency.
This realization pushed me into a deeper AWS chapter: EBS, EFS, FSx, RDS, DynamoDB, Route 53, and CloudFront.
Each one filled a gap I didn't even know existed - until the day I faced a real problem. Let me take you through that journey.
1. When My EC2 Lost Its Data - The EBS Lesson
One day, I rebooted my EC2 instance… and my application files were gone.
I had forgotten the most basic AWS truth:
"EC2 storage disappears unless you attach persistent volumes."
That's when I discovered EBS (Elastic Block Store) - block storage volumes that live independently of the EC2 instance.
What I learned about EBS:
- Persistent even if the EC2 is stopped
- Can be detached & attached to any EC2
- Great for OS boot volumes, DBs, or app data
Hands-on Commands:
Key Lesson: Compute and storage must be decoupled for reliability.
2. When Multiple EC2s Needed Shared Storage - Enter EFS
Soon, I deployed two EC2 instances behind a load balancer.
But then something broke:
- One instance had updated config files
- The other still used old ones
- My app behaved inconsistently
That's when I needed shared file storage → Amazon EFS
Why EFS was a game changer:
- Multiple EC2s can read/write the same files
- Perfect for web servers, content directories, shared uploads
- Auto-scaling storage
- Pay only for what you use
Mount EFS:
EFS solved consistency issues instantly. No more "it works on server 1, but not server 2."
3. Snapshots & Disaster Recovery - EBS Snapshots
Later, I needed safe backups before making risky changes.
That's when I learned the magic of:
- Snapshots are incremental & stored in S3 internally
- If anything breaks: restore → create new volume → attach
"Always protect your state before making changes."
4. High-Performance File Systems - FSx
AWS FSx came next. At first, I ignored it - until I learned it powers:
- High-performance workloads
- Machine learning pipelines
- Windows application file shares
- Data-intensive HPC workloads
Use EFS for Linux. Use FSx for anything heavy-duty.
5. When My App Needed a Database That Wouldn't Crash - RDS
I deployed MySQL on EC2 once. Bad idea.
Maintenance, backups, failover… all on me.
Then I discovered RDS - AWS-managed SQL databases.
RDS gives you:
- Automated backups
- Multi-AZ replication
- Auto patching
- Read replicas
- Monitoring
- Snapshots
- Encryption
Launching RDS:
Suddenly, my backend was stable, consistent, and safe.
6. When Performance Outgrew SQL - DynamoDB Saved Me
A scenario happened:
My app needed:
- Millisecond reads
- Millions of requests
- No downtime
- No maintenance
Enter DynamoDB - serverless NoSQL at massive scale.
DynamoDB strengths:
- Auto-scaling read/write
- Global tables
- TTL for auto-expiry
- On-demand pricing
- Zero maintenance
DynamoDB made my backend "infinitely scalable" without touching servers.
7. When My App Needed a Domain - Route 53
Next problem: I needed a custom domain for my app.
Route 53 gave me:
- DNS records
- Traffic routing
- Health checks
- Failover routing
- Latency-based routing
Now my app wasn't just functional - it had an online identity.
8. When I Needed Global Speed - CloudFront Saved My Bandwidth
Last issue: My images, CSS files, and videos loaded slowly across regions.
CloudFront fixed everything.
CloudFront advantages:
- Distributes content globally
- Reduces latency
- Caches static files
- Secures content with HTTPS
- Integrates with S3, EC2, and Load Balancers
- DDoS protection via AWS Shield
Now my system felt "global." Users anywhere experienced fast performance.
Final Architecture (Day 14 Vision)
| Layer | Service | Purpose |
|---|---|---|
| CDN | CloudFront | Global CDN Delivery |
| DNS/Domain | Route 53 | Domain & Routing |
| Load Balancer | ELB | Distributes Traffic |
| Web Servers | EC2 (EFS) | Compute/Shared Filesystem |
| Database | RDS / DynamoDB | Managed DB / NoSQL at Scale |
| Storage | S3, EBS, FSx/EFS | Object/Block/File Storage |
What I Learned (Deep DevOps Mindset)
- Don't trust EC2 storage - use EBS
- Don't duplicate files across instances - use EFS
- Don't run SQL manually - use RDS
- Don't force SQL for all workloads - use DynamoDB
- Don't expose raw S3 - use CloudFront
- Don't buy domains elsewhere - Route 53 is built for AWS
- Don't skip backups - use Snapshots
This blog wasn't just content - it was an evolution in the way I think about designing cloud systems.
"DevOps isn't about tools - it's about building systems that don't break when life gets busy."
What's Next (Day 15 - Serverless + Observability)
Coming up next:
| Theme | Topics |
|---|---|
| Serverless | AWS Lambda, Triggers, Events, Destinations |
| Monitoring | CloudWatch Metrics & Logs, Dashboards, Alarms |
| Alerts | Amazon SNS, SQS message queues |
This is where automation becomes truly event-driven and intelligent.
Top comments (0)