In my previous blog Day-11 ,I explored how to build scalable and cost-effective AWS infrastructure using Load Balancers, Auto Scaling Groups, and Launch Templates - the foundation of resilience in cloud compute.
But soon, I faced a realization:
Scaling applications means nothing if your network isn't designed to support it.
So in this chapter, I decided to go deeper - to understand how AWS networking actually works behind the scenes, how instances talk to each other securely, and how data travels safely in and out of the cloud.
What I'll Cover in Day 12
- Virtual Private Cloud (VPC)
- Subnets (Public and Private)
- Internet Gateway (IGW)
- NAT Gateway
- Route Tables
- Elastic IPs
- Security Groups vs NACLs
The Real Problem
It started with a small frustration.
I launched an EC2 instance in my new custom environment... and it refused to connect to the Internet.
No updates. No pings. No outgoing traffic.
That's when I discovered my first real DevOps truth:
"In AWS, nothing connects by default - you build the roads yourself."
Step 1: Designing My Own Virtual Private Cloud (VPC)
A VPC (Virtual Private Cloud) is your own private slice of AWS networking.
Think of it as your company's private data center inside the cloud - completely isolated until you decide what connects to what.
I created a custom VPC:
- Name: MY-VPC
- CIDR Block: 10.0.0.0/22
- Region: ap-south-1 (Mumbai)
This became my cloud playground - the foundation for all my future deployments.
Step 2: Public and Private Subnets
The first rule of networking - not everything should be exposed to the Internet.
So I divided my VPC into two subnets:
| Subnet Type | CIDR Block | Purpose |
|---|---|---|
| Public Subnet | 10.0.0.0/24 | Hosts Internet-facing resources (Load Balancer, Bastion) |
| Private Subnet | 10.0.1.0/24 | Hosts application and database servers |
Each subnet was mapped to a different Availability Zone - ensuring fault tolerance.
"Subnets are the boundaries that define your exposure."
Step 3: Route Tables and Internet Gateway
Once I had my subnets, it was time to connect them properly.
Public Route Table:
- Destination: 0.0.0.0/0
- Target: Internet Gateway (IGW)
Private Route Table:
- Destination: Local traffic only (10.0.0.0/22)
- Target: None (isolated network)
Then, I created an Internet Gateway and attached it to my VPC - the bridge between my cloud and the outside world.
Lesson Learned:
Without a route or gateway, your instance is alive but stranded.
Step 4: Launching EC2 in the Custom VPC
This time, I launched my EC2 instance in the public subnet of my custom VPC and allowed HTTP/HTTPS traffic through the security group.
A quick ping 8.8.8.8 returned success.
That one reply packet was more than a test - it was my first working AWS network.
Step 5: Adding NAT Gateway for Private Subnets
Next challenge:
My private EC2 instances needed to download system updates but still remain unreachable from outside.
Solution: NAT Gateway
Here's what I did:
- Created a NAT Gateway in the public subnet.
- Allocated an Elastic IP to give it a static public address.
- Updated the Private Route Table:
- Destination: 0.0.0.0/0
- Target: NAT Gateway
Now, my private servers could reach the Internet outbound (for updates, API calls) while staying invisible to inbound traffic.
"A NAT Gateway is like a one-way mirror - you can see out, but no one can see in."
Step 6: Elastic IP - Stable Connectivity
Public IPs in AWS are dynamic - they change when you stop/start instances.
But real-world servers need consistency (for whitelisting, SSH, or API calls).
That's where Elastic IPs come in.
They're static, reassignable IPs you can attach to NAT Gateways or EC2s.
I attached one EIP to my NAT and another to my Bastion EC2.
Now, even after reboots, I had predictable, reliable connectivity.
Step 7: Security Groups vs Network ACLs
To secure my environment, I used AWS's two-tier firewall model:
| Feature | Security Groups | Network ACLs |
|---|---|---|
| Scope | Instance-level | Subnet-level |
| Stateful | Yes (remembers connections) | No (must allow return traffic manually) |
| Default Behavior | Deny inbound, allow outbound | Allow all |
| Use Case | Fine-tuned port access | Broader subnet security |
For my setup:
- Security Group: Allowed inbound HTTP/HTTPS + SSH.
- NACL: Blocked everything except ports 22 and 80.
Together, they formed a layered defense system - something every DevOps engineer should think about from Day 1.
Step 8: My Final Architecture
Key Components:
- Public Subnet - Internet-facing
- Private Subnet - Internal workloads
- NAT Gateway + EIP - Outbound access only
- Security Groups + NACLs - Layered security
Step 9: My Practical Takeaway
This project changed how I think about the cloud.
I stopped focusing on individual instances - and started seeing the architecture as a living system.
Key insights:
- Isolation is intentional, not accidental.
- Every subnet and route is a design decision.
- Networking is where security and scalability truly begin.
"In DevOps, understanding networks isn't optional - it's the difference between deploying and designing."
What's Next (Day 13 - AWS S3 Essentials)
Now that I've built a secure and scalable network for compute, it's time to move to the next core AWS service - storage.
In Day 13, I'll dive deep into Amazon S3 (Simple Storage Service) - learning how to store, manage, and secure data efficiently in the cloud.
Here's what I'll cover next:
- S3 Buckets and Objects - the basic building blocks of cloud storage
- Regions and Data Distribution - where and how data physically lives
- S3 Storage Classes - balancing performance and cost
- S3 Versioning - tracking and recovering previous data states
- S3 Access Control - IAM policies and bucket permissions
- Buckets and Keys - organizing and addressing data
- S3 Consistency Models - how AWS ensures data reliability
- Object Lifecycle Management - automating archival and deletion
- S3 Encryption - securing data at rest and in transit
"Compute gives life to your application, Networking connects it, and Storage ensures it remembers."
Stay tuned for Day 13, where I explore S3 - the backbone of cloud storage and how DevOps engineers use it for reliability, versioning, and automation.
Top comments (0)