AWS VPC & Networking
Virtual Private Clouds, subnets, security groups, and internet gateways
Knowledge Debt detected
You can study this freely — but your score may plateau if these foundations have gaps. The Mastery badge requires them to be solid.
Explanation
A VPC (Virtual Private Cloud) is your private, isolated network inside AWS. Every resource you deploy lives inside a VPC.
Key building blocks:
| Component | What it does | |---|---| | VPC | Your isolated virtual network (define a CIDR block like 10.0.0.0/16) | | Subnet | A subdivision of the VPC in one AZ; public or private | | Internet Gateway | Connects a public subnet to the internet | | NAT Gateway | Lets private subnets reach the internet outbound (no inbound) | | Route Table | Rules that determine where traffic goes | | Security Group | Stateful firewall at the instance level (allow/deny ports) | | NACL | Stateless firewall at the subnet level |
Public vs private subnets:
VPC (10.0.0.0/16) ├── Public subnet (10.0.1.0/24) → Internet Gateway → internet │ └── EC2 (web server, load balancer) └── Private subnet (10.0.2.0/24) → NAT Gateway → internet (outbound only) └── EC2 (app server, RDS database) `` Best practice: web servers in public subnets, databases never in public subnets.
Security Groups — stateful, instance-level:
Inbound rules: Port 443 (HTTPS) from 0.0.0.0/0 ← allow all internet traffic Port 22 (SSH) from 10.0.0.0/16 ← allow VPC-internal only Outbound rules: All traffic to 0.0.0.0/0 ← allow all outbound (default) `` "Stateful" means if inbound traffic is allowed, the response is automatically allowed back out — you don't need a matching outbound rule.
VPC Peering — connecting VPCs:
Peering lets resources in separate VPCs communicate over AWS's private network — no internet traffic. Useful for multi-account setups.
Key design patterns:
- Multi-AZ: Spread subnets across 2-3 AZs for high availability
- Bastion host: A hardened EC2 in the public subnet that you SSH to, then jump to private instances
- VPC endpoints: Connect to S3/DynamoDB without leaving the VPC (lower cost, better security)
Examples
Standard 3-tier VPC layout
Each tier only accepts traffic from the tier above — defense in depth even if one layer is compromised
# Typical production VPC design
# VPC: 10.0.0.0/16 (65,536 IPs)
# Two AZs for high availability
# us-east-1a:
# Public subnet: 10.0.1.0/24 (ALB, NAT Gateway)
# Private subnet: 10.0.2.0/24 (EC2 app servers)
# DB subnet: 10.0.3.0/24 (RDS, ElastiCache)
# Security Group rules
# alb-sg: inbound 443 from 0.0.0.0/0
# app-sg: inbound 8000 from alb-sg only # not from internet!
# db-sg: inbound 5432 from app-sg only # database never publicSecurity Group vs NACL
Security groups are your primary firewall; NACLs are a secondary subnet-wide layer — most teams only need security groups
# Security Group (stateful, instance-level)
# If inbound port 443 is allowed, the response is automatically allowed
# Rules are ALLOW only (no explicit deny)
aws ec2 authorize-security-group-ingress --group-id sg-12345 --protocol tcp --port 443 --cidr 0.0.0.0/0
# NACL (stateless, subnet-level)
# Must explicitly allow BOTH inbound request AND outbound response
# Rules are evaluated in order (lower number = higher priority)
# Supports DENY rules (use to block specific IPs)
# Best practice:
# Use Security Groups for all normal access control
# Use NACLs only for subnet-wide IP blocklistsHow well did you understand this?