VPC and Network Architecture

When we spin up resources in the cloud, they don’t just float around in the open internet. They live inside a VPC (Virtual Private Cloud) — our own isolated network. Think of it like having our own private building inside a massive office complex. We control who gets in and who doesn’t.

What’s a VPC?

A VPC is a logically isolated section of the cloud where we launch resources. We define the IP range, create subnets, set up route tables, and control traffic flow.

Every cloud provider has this concept:

• AWS — VPC
• GCP — VPC Network
• Azure — Virtual Network (VNet)

Subnets: Public vs Private

A subnet is a slice of our VPC’s IP range. We split our VPC into subnets to separate resources.

Public subnet — has a route to the internet via an Internet Gateway. Resources here can have public IPs. We put load balancers and bastion hosts here.

Private subnet — no direct internet access. Databases and app servers live here. They can reach the internet outbound through a NAT Gateway (sitting in the public subnet), but nobody from the internet can reach them directly.

Key Networking Components

Internet Gateway (IGW) — the door between our VPC and the public internet. Attach it to the VPC, add a route, and public subnets can talk to the world.

NAT Gateway — lets private subnet resources access the internet (for updates, API calls) without exposing them. Traffic goes out but can’t come in.

Route Table — a set of rules that determine where network traffic goes. Each subnet is associated with a route table.

# Public subnet route table (conceptual)
Destination     Target
10.0.0.0/16     local          # traffic within VPC stays local
0.0.0.0/0       igw-123abc     # everything else goes to internet

# Private subnet route table
Destination     Target
10.0.0.0/16     local          # traffic within VPC stays local
0.0.0.0/0       nat-456def     # outbound internet goes through NAT

Security Groups vs NACLs

These are our two layers of firewall.

Security Groups — act at the instance level (attached to an EC2, RDS, etc.). They’re stateful — if we allow traffic in, the response is automatically allowed out.

# Security group for a web server
Inbound:
  Port 80 (HTTP)    from 0.0.0.0/0     # allow web traffic
  Port 443 (HTTPS)  from 0.0.0.0/0     # allow secure web traffic
  Port 22 (SSH)     from 10.0.1.0/24   # SSH only from public subnet

Outbound:
  All traffic       to 0.0.0.0/0       # allow all outbound

NACLs (Network Access Control Lists) — act at the subnet level. They’re stateless — we must explicitly allow both inbound and outbound traffic. Think of NACLs as the building’s front gate, and security groups as each apartment’s door lock.

The only difference between them: security groups are stateful (remember connections), NACLs are stateless (check every packet independently).

VPC Peering

Sometimes we need two VPCs to talk to each other — maybe our staging VPC needs to reach a shared database VPC. VPC peering creates a private network connection between them. Traffic stays on the cloud provider’s backbone and never touches the public internet.

In simple language, a VPC is our private network in the cloud. Public subnets face the internet, private subnets hide behind NAT. Security groups and NACLs are our bouncers. Once we understand this, every cloud architecture diagram starts making sense.