Recap: Why VPC Matters?
After launching my first EC2 instance and configuring Jenkins, I realized something critical—AWS by default places instances in a shared public network (default VPC). But in a real-world production setup, you don’t want your resources open to the internet without strict security controls.
This is where AWS Virtual Private Cloud (VPC) comes in.
A Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you can launch resources like EC2 instances, databases, and load balancers. It allows you to define your own virtual network, including IP address ranges, subnets, route tables, and gateways.
Key Components of a VPC
Here’s a breakdown of the main components and how they work together:
Subnets:
Public Subnet: Resources in this subnet can communicate with the internet (e.g., web servers).
Private Subnet: Resources in this subnet cannot directly access the internet (e.g., databases).
Route Tables:
Define how traffic is routed within the VPC.
Each subnet is associated with a route table.
Internet Gateway (IGW):
Allows communication between resources in the VPC and the internet.
Attached to the VPC and used by public subnets.
NAT Gateway:
Allows resources in private subnets to access the internet (e.g., for updates) without exposing them to inbound traffic.
Located in a public subnet.
Security Groups:
Act as virtual firewalls for instances, controlling inbound and outbound traffic.
Stateful: Allow return traffic automatically.
Network ACLs (NACLs):
Act as a firewall for subnets, controlling inbound and outbound traffic at the subnet level.
Stateless: Require explicit rules for return traffic.
Application Load Balancer (ALB):
Distributes incoming traffic across multiple targets (e.g., EC2 instances) in public or private subnets.
Bastion Host:
A secure server in a public subnet used to access instances in private subnets via SSH.
Route 53:
AWS’s DNS service, used to route traffic to resources (e.g., EC2 instances, load balancers) and register domain names.
How Everything Links Up
Vpc in a lame man theory
Step 1: Entering the City (Route 53 & Load Balancer)
The first stop? Route 53, Cloudville’s GPS system. It takes the user’s request and figures out where to send it—should it go to the North theater or the South theater?
Now that the request has a direction, it moves towards Cloudville’s city gates—the Load Balancer. Think of this as a border control checkpoint. It doesn’t just allow random traffic inside; instead, it checks the health of movie theaters (EC2 instances) and assigns the best one for the request.
But before the request is allowed to continue, it needs a public identity—a Public IP address assigned by the Load Balancer so it can be tracked properly.
Step 2: Navigating Security (NACL, Security Groups, and Routing)
Now, here’s the tricky part: Cloudville doesn’t let just anyone waltz into its private areas. The real action happens inside a private subnet, away from the outside world.
But wait! There’s a NACL (Network Access Control List) standing guard. This acts like a strict security officer at the gate, checking every request and blocking anything suspicious before it gets deeper inside.
If the request passes the NACL, it’s still not free to roam yet. It needs directions! That’s where the Route Table steps in—it’s the city's navigation system, guiding requests to their final destinations.
Step 3: Reaching the Private Server (Bastion Host & NAT Gateway)
Now, we’ve got a small problem. The server (EC2 instance) is inside a private subnet—meaning it doesn’t have direct access to the internet. The Route Table knows where to send the request, but since the server has only a private IP address, it cannot communicate directly with the outside world.
Enter the Bastion Host—Cloudville’s secret identity maker. Instead of exposing the real private server, the Bastion Host acts as a middleman, generating a new public-facing IP address to mask the private server’s real identity.
With this, the request is safely passed through, reaching the EC2 instance. Boom! The movie starts streaming!
Step 4: Servers Talking Back to the Internet (NAT Gateway & IGW)
Now, what if the private server needs to talk to the internet? Maybe it needs to download security updates or fetch an image for the website.
Here’s the thing—private subnets can’t talk directly to the outside world (that’s the whole point of security!). Instead, they need a NAT Gateway—think of it as a secure post office. The private server sends a letter to the NAT Gateway, which then forwards it using a public IP address.
On the other hand, for anything in the public subnet, the Internet Gateway (IGW) handles all communication freely—acting like the main highway to and from Cloudville.
If you’ve worked with VPC, what’s one thing you wish you knew earlier? Do you see anything missing or incorrect in my setup? Let’s discuss in the comments!
Top comments (0)