Networking - Dev Weekends

Module Overview

Estimated Time: 5-6 hours | Difficulty: Intermediate-Advanced | Prerequisites: Core Concepts

This module covers AWS networking from fundamentals to advanced architectures. You’ll learn to design secure, scalable, and highly available network topologies. What You’ll Learn:

VPC design and CIDR planning
Public and private subnet architectures
Security groups and NACLs for defense in depth
Load balancers (ALB, NLB) and routing
VPC connectivity (Peering, Transit Gateway, VPN)
Route 53 DNS and CloudFront CDN
Network troubleshooting techniques

VPC (Virtual Private Cloud)

A VPC is your isolated network in AWS. Every resource you launch runs inside a VPC. Think of a VPC as your own private office building inside a massive shared complex (the AWS data center). You control who enters, which floors connect to each other, and which rooms have windows to the outside world (the internet). Without a VPC, your resources would be sitting in a public parking lot.

VPC Architecture Deep Dive

┌────────────────────────────────────────────────────────────────────────┐
│                      Production VPC (10.0.0.0/16)                       │
│                        65,536 IP addresses                              │
├────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   ┌─────────────────────────────────────────────────────────────────┐  │
│   │                    Availability Zone 1 (us-east-1a)              │  │
│   │                                                                  │  │
│   │  ┌───────────────────────┐  ┌───────────────────────┐           │  │
│   │  │  PUBLIC SUBNET        │  │  PRIVATE SUBNET       │           │  │
│   │  │  10.0.1.0/24          │  │  10.0.10.0/24         │           │  │
│   │  │  (251 usable IPs)     │  │  (251 usable IPs)     │           │  │
│   │  │                       │  │                       │           │  │
│   │  │  ┌─────────────────┐  │  │  ┌─────────────────┐  │           │  │
│   │  │  │   NAT Gateway   │  │  │  │  App Server     │  │           │  │
│   │  │  │   (EIP)         │  │  │  │  (EC2)          │  │           │  │
│   │  │  └─────────────────┘  │  │  └─────────────────┘  │           │  │
│   │  │                       │  │                       │           │  │
│   │  │  ┌─────────────────┐  │  │  ┌─────────────────┐  │           │  │
│   │  │  │   Bastion Host  │  │  │  │   Database      │  │           │  │
│   │  │  │   (optional)    │  │  │  │   (RDS)         │  │           │  │
│   │  │  └─────────────────┘  │  │  └─────────────────┘  │           │  │
│   │  └───────────────────────┘  └───────────────────────┘           │  │
│   │                                                                  │  │
│   │  ┌───────────────────────┐                                      │  │
│   │  │  DATA SUBNET          │  (Optional - for databases only)     │  │
│   │  │  10.0.20.0/24         │                                      │  │
│   │  └───────────────────────┘                                      │  │
│   │                                                                  │  │
│   └─────────────────────────────────────────────────────────────────┘  │
│                                                                         │
│   ┌─────────────────────────────────────────────────────────────────┐  │
│   │                    Availability Zone 2 (us-east-1b)              │  │
│   │                         (Mirror of AZ1)                          │  │
│   │  ┌───────────────────────┐  ┌───────────────────────┐           │  │
│   │  │  PUBLIC: 10.0.2.0/24  │  │  PRIVATE: 10.0.11.0/24│           │  │
│   │  │  NAT Gateway          │  │  App Server (replica) │           │  │
│   │  └───────────────────────┘  └───────────────────────┘           │  │
│   │  ┌───────────────────────┐                                      │  │
│   │  │  DATA: 10.0.21.0/24   │                                      │  │
│   │  └───────────────────────┘                                      │  │
│   └─────────────────────────────────────────────────────────────────┘  │
│                                                                         │
│   ┌─────────────────────────────────────────────────────────────────┐  │
│   │                    Availability Zone 3 (us-east-1c)              │  │
│   │  (Similar structure for higher availability)                     │  │
│   └─────────────────────────────────────────────────────────────────┘  │
│                                                                         │
└────────────────────────────────────────────────────────────────────────┘

CIDR Planning Guide

┌────────────────────────────────────────────────────────────────────────┐
│                      CIDR Planning Best Practices                       │
├────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   CIDR NOTATION QUICK REFERENCE:                                       │
│   ─────────────────────────────                                         │
│   /16 = 65,536 IPs  (10.0.0.0 - 10.0.255.255)   ← VPC size            │
│   /20 = 4,096 IPs   (10.0.0.0 - 10.0.15.255)    ← Large subnet        │
│   /24 = 256 IPs     (10.0.0.0 - 10.0.0.255)     ← Standard subnet     │
│   /28 = 16 IPs      (10.0.0.0 - 10.0.0.15)      ← Small subnet        │
│                                                                         │
│   AWS RESERVES 5 IPs per subnet:                                       │
│   • .0   = Network address                                             │
│   • .1   = VPC router                                                  │
│   • .2   = DNS server                                                  │
│   • .3   = Reserved for future                                         │
│   • .255 = Broadcast (reserved)                                        │
│                                                                         │
│   So /24 (256 IPs) → 251 usable                                        │
│      /28 (16 IPs)  → 11 usable                                         │
│                                                                         │
│   RECOMMENDED VPC CIDR RANGES:                                         │
│   ────────────────────────────                                         │
│   10.0.0.0/8     (Class A - 16M IPs) - Private                        │
│   172.16.0.0/12  (Class B - 1M IPs)  - Private                        │
│   192.168.0.0/16 (Class C - 65K IPs) - Private                        │
│                                                                         │
│   MULTI-ENVIRONMENT EXAMPLE:                                           │
│   ─────────────────────────────                                        │
│   Production:  10.0.0.0/16                                             │
│   Staging:     10.1.0.0/16                                             │
│   Development: 10.2.0.0/16                                             │
│   (No overlap = can peer VPCs later)                                   │
│                                                                         │
└────────────────────────────────────────────────────────────────────────┘

VPC with Terraform

# Complete VPC setup with Terraform
resource "aws_vpc" "main" {
  # /16 gives 65,536 IPs -- generous enough for growth, but don't go larger
  # than you need. Common mistake: using /16 for every VPC and then running
  # out of non-overlapping ranges when you need to peer them later.
  cidr_block           = "10.0.0.0/16"
  # Both DNS settings are required for services like RDS that use DNS-based
  # endpoints. Forgetting these causes mysterious "host not found" errors.
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name        = "production-vpc"
    Environment = "production"
  }
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  
  tags = {
    Name = "production-igw"
  }
}

# Public Subnets (one per AZ)
resource "aws_subnet" "public" {
  count                   = 3
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.${count.index + 1}.0/24"
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
  
  tags = {
    Name = "public-${data.aws_availability_zones.available.names[count.index]}"
    Tier = "public"
  }
}

# Private Subnets (one per AZ)
resource "aws_subnet" "private" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  tags = {
    Name = "private-${data.aws_availability_zones.available.names[count.index]}"
    Tier = "private"
  }
}

# NAT Gateway (one per AZ for HA)
# Cost warning: Each NAT Gateway costs ~$32/month ($0.045/hr) PLUS $0.045/GB
# of data processed. For a production environment pushing 1 TB/month through
# NAT, that is ~$45 in processing fees alone per NAT gateway. With 3 NAT
# gateways for HA, budget ~$230/month just for NAT.
#
# Cost tip for dev/staging: Use a single NAT Gateway (count=1) or even a
# t3.micro NAT instance (~$7/month) to save $60-200/month per environment.
resource "aws_eip" "nat" {
  count  = 3
  domain = "vpc"
}

resource "aws_nat_gateway" "main" {
  count         = 3
  allocation_id = aws_eip.nat[count.index].id
  # NAT Gateways live in public subnets (they need internet access via IGW)
  # but serve private subnets. This trips up beginners who place them in
  # private subnets and wonder why outbound traffic fails.
  subnet_id     = aws_subnet.public[count.index].id
  
  tags = {
    Name = "nat-${count.index + 1}"
  }
}

# Route Tables
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
  
  tags = {
    Name = "public-rt"
  }
}

resource "aws_route_table" "private" {
  count  = 3
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main[count.index].id
  }
  
  tags = {
    Name = "private-rt-${count.index + 1}"
  }
}

Subnets

Subnets divide your VPC into smaller networks. Each subnet exists in a single AZ.

Public vs Private Subnets

Type	Internet Access	Use Case
Public	Has route to Internet Gateway	Web servers, bastion hosts
Private	No direct internet access	Databases, app servers

┌─────────────────────────────────────────────────────────────────┐
│                        Internet Access                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│                         ┌───────────┐                            │
│                         │  Internet │                            │
│                         └─────┬─────┘                            │
│                               │                                  │
│                         ┌─────▼─────┐                            │
│                         │  Internet │                            │
│                         │  Gateway  │                            │
│                         └─────┬─────┘                            │
│                               │                                  │
│   ┌───────────────────────────┼───────────────────────────────┐ │
│   │                     VPC   │                                │ │
│   │                           │                                │ │
│   │   ┌───────────────────────▼──────────────────────────┐     │ │
│   │   │              Public Subnet                        │     │ │
│   │   │   Route: 0.0.0.0/0 → Internet Gateway            │     │ │
│   │   │                                                   │     │ │
│   │   │   ┌──────────┐    Public IP                       │     │ │
│   │   │   │   EC2    │◄──────────                         │     │ │
│   │   │   └──────────┘                                    │     │ │
│   │   └──────────────────────────────────────────────────┘     │ │
│   │                           │                                │ │
│   │   ┌───────────────────────▼──────────────────────────┐     │ │
│   │   │              Private Subnet                       │     │ │
│   │   │   Route: 0.0.0.0/0 → NAT Gateway (for outbound)  │     │ │
│   │   │                                                   │     │ │
│   │   │   ┌──────────┐    No public IP                    │     │ │
│   │   │   │   RDS    │                                    │     │ │
│   │   │   └──────────┘                                    │     │ │
│   │   └──────────────────────────────────────────────────┘     │ │
│   │                                                            │ │
│   └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Gateways

Internet Gateway (IGW)

Allows resources with public IPs to access the internet.

NAT Gateway

Allows private subnet resources to access the internet (outbound only).

┌────────────────────────────────────────────────────────────────┐
│                    NAT Gateway Pattern                          │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│                         Internet                                │
│                            │                                    │
│                    ┌───────▼───────┐                           │
│                    │Internet Gateway│                           │
│                    └───────┬───────┘                           │
│                            │                                    │
│   ┌────────────────────────┼────────────────────────────────┐  │
│   │ Public Subnet          │                                 │  │
│   │                 ┌──────▼──────┐                          │  │
│   │                 │ NAT Gateway │                          │  │
│   │                 │ (with EIP)  │                          │  │
│   │                 └──────┬──────┘                          │  │
│   └────────────────────────┼────────────────────────────────┘  │
│                            │                                    │
│   ┌────────────────────────┼────────────────────────────────┐  │
│   │ Private Subnet         │                                 │  │
│   │                 ┌──────▼──────┐                          │  │
│   │                 │    EC2      │  Can reach internet      │  │
│   │                 │  (private)  │  (for updates, APIs)     │  │
│   │                 └─────────────┘  Cannot be reached       │  │
│   └─────────────────────────────────────────────────────────┘  │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

NAT Gateway costs: ~$0.045/hour + data processing charges. Consider NAT instances for dev environments to save costs.

Security Groups Deep Dive

Virtual firewalls for EC2 instances. Stateful - return traffic is automatically allowed. Think of a security group as a bouncer at a club: if you are on the guest list (inbound rule), you get in, and you can leave freely (return traffic). A NACL, by contrast, is like airport security — it checks you on the way in AND on the way out, independently.

Security Group Architecture

┌────────────────────────────────────────────────────────────────────────┐
│                    Defense in Depth with Security Groups                │
├────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   Internet                                                              │
│       │                                                                 │
│       ▼                                                                 │
│   ┌─────────────────────────────────────────────────────────────────┐  │
│   │  SG: alb-sg                                                      │  │
│   │  Inbound:  443 from 0.0.0.0/0                                   │  │
│   │  Outbound: All to web-sg                                        │  │
│   │                                                                  │  │
│   │  ┌─────────────────────────────────────────────────────────┐    │  │
│   │  │           Application Load Balancer                      │    │  │
│   │  └─────────────────────────────────────────────────────────┘    │  │
│   └─────────────────────────────────────────────────────────────────┘  │
│                               │                                         │
│                               ▼                                         │
│   ┌─────────────────────────────────────────────────────────────────┐  │
│   │  SG: web-sg                                                      │  │
│   │  Inbound:  8080 from alb-sg (reference SG, not IP!)             │  │
│   │  Inbound:  22 from bastion-sg (SSH)                             │  │
│   │  Outbound: 3306 to db-sg                                        │  │
│   │  Outbound: 6379 to cache-sg                                     │  │
│   │  Outbound: 443 to 0.0.0.0/0 (for external APIs)                 │  │
│   │                                                                  │  │
│   │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │  │
│   │  │   Web EC2    │  │   Web EC2    │  │   Web EC2    │          │  │
│   │  └──────────────┘  └──────────────┘  └──────────────┘          │  │
│   └─────────────────────────────────────────────────────────────────┘  │
│                               │                                         │
│                               ▼                                         │
│   ┌─────────────────────────────────────────────────────────────────┐  │
│   │  SG: db-sg                                                       │  │
│   │  Inbound:  3306 from web-sg ONLY                                │  │
│   │  Outbound: None needed (stateful)                               │  │
│   │                                                                  │  │
│   │  ┌────────────────────────────────────────────────────────────┐ │  │
│   │  │                    RDS MySQL                                │ │  │
│   │  └────────────────────────────────────────────────────────────┘ │  │
│   └─────────────────────────────────────────────────────────────────┘  │
│                                                                         │
│   KEY PRINCIPLES:                                                       │
│   ✅ Reference security groups, not IP addresses                       │
│   ✅ Principle of least privilege                                       │
│   ✅ Separate SG per tier (web, app, db)                               │
│   ✅ Never open 0.0.0.0/0 except for ALB inbound                       │
│                                                                         │
└────────────────────────────────────────────────────────────────────────┘

Security Group with Terraform

# ALB Security Group
resource "aws_security_group" "alb" {
  name        = "alb-sg"
  description = "Security group for Application Load Balancer"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "HTTPS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP for redirect"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    description     = "To web servers"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web.id]
  }

  tags = {
    Name = "alb-sg"
  }
}

# Web Server Security Group
resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Security group for web servers"
  vpc_id      = aws_vpc.main.id

  ingress {
    description     = "From ALB"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    # Referencing the ALB security group instead of an IP range is the key
    # best practice here. If the ALB IPs change (they do, frequently), this
    # rule still works. It also means only traffic FROM the ALB is allowed --
    # not traffic from any IP that happens to use port 8080.
    security_groups = [aws_security_group.alb.id]
  }

  egress {
    description     = "To database"
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.db.id]
  }

  egress {
    description = "HTTPS for external APIs"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-sg"
  }
}

# Database Security Group
resource "aws_security_group" "db" {
  name        = "db-sg"
  description = "Security group for RDS"
  vpc_id      = aws_vpc.main.id

  ingress {
    description     = "MySQL from web servers"
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.web.id]
  }

  # No egress rule explicitly needed -- security groups are stateful, so
  # response traffic to the web servers' MySQL queries is automatically allowed.
  # Common mistake: Adding "allow all outbound" to every security group out of
  # habit. For a database, there is rarely a reason it needs to initiate outbound
  # connections. Keeping egress locked down limits blast radius if the DB is
  # compromised.
  
  tags = {
    Name = "db-sg"
  }
}

Security Groups vs NACLs

┌────────────────────────────────────────────────────────────────────────┐
│                    Security Groups vs NACLs                             │
├────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   Feature            │ Security Group      │ NACL                      │
│   ───────────────────┼─────────────────────┼─────────────────────────  │
│   Level              │ Instance (ENI)      │ Subnet                    │
│   State              │ Stateful            │ Stateless                 │
│   Rules              │ Allow only          │ Allow AND Deny            │
│   Evaluation         │ All rules checked   │ Rules in order (by #)     │
│   Default            │ Deny all in         │ Allow all                 │
│   Applies to         │ Instances you assign│ All instances in subnet   │
│   Return traffic     │ Automatic           │ Must explicitly allow     │
│                                                                         │
│   WHEN TO USE EACH:                                                    │
│   ─────────────────                                                    │
│   Security Groups: Primary defense, fine-grained instance control      │
│   NACLs: Subnet-level blocking, deny specific IPs, compliance         │
│                                                                         │
│   NACL EXAMPLE - Block specific IP:                                    │
│   ┌────────────────────────────────────────────────────────────────┐  │
│   │ Rule # │ Type   │ Protocol │ Port │ Source      │ Allow/Deny  │  │
│   │────────┼────────┼──────────┼──────┼─────────────┼─────────────│  │
│   │ 50     │ Custom │ TCP      │ ALL  │ 1.2.3.4/32  │ DENY        │  │
│   │ 100    │ HTTPS  │ TCP      │ 443  │ 0.0.0.0/0   │ ALLOW       │  │
│   │ 110    │ HTTP   │ TCP      │ 80   │ 0.0.0.0/0   │ ALLOW       │  │
│   │ *      │ ALL    │ ALL      │ ALL  │ 0.0.0.0/0   │ DENY        │  │
│   └────────────────────────────────────────────────────────────────┘  │
│                                                                         │
│   ⚠️ Don't forget outbound rules for NACLs! (ephemeral ports 1024-65535)│
│                                                                         │
└────────────────────────────────────────────────────────────────────────┘

Load Balancing

Distribute traffic across multiple targets.

Load Balancer Types

Type	Layer	Use Case
ALB (Application)	Layer 7 (HTTP/HTTPS)	Web apps, microservices
NLB (Network)	Layer 4 (TCP/UDP)	Gaming, IoT, low latency
GLB (Gateway)	Layer 3	Firewalls, IDS/IPS
CLB (Classic)	Layer 4/7	Legacy (avoid)

Application Load Balancer (ALB)

┌────────────────────────────────────────────────────────────────┐
│                    ALB Architecture                             │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Client Request                                                │
│        │                                                        │
│        ▼                                                        │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │              Application Load Balancer                   │  │
│   │                                                          │  │
│   │   Listener (Port 443)                                    │  │
│   │        │                                                 │  │
│   │        ▼                                                 │  │
│   │   ┌─────────────────────────────────────────────────┐   │  │
│   │   │              Routing Rules                       │   │  │
│   │   │                                                  │   │  │
│   │   │  /api/*    → Target Group: API Servers          │   │  │
│   │   │  /static/* → Target Group: Static (S3)          │   │  │
│   │   │  /*        → Target Group: Web Servers          │   │  │
│   │   │                                                  │   │  │
│   │   └─────────────────────────────────────────────────┘   │  │
│   └─────────────────────────────────────────────────────────┘  │
│                     │              │              │             │
│              ┌──────┴───┐   ┌──────┴───┐   ┌──────┴───┐        │
│              │ Target   │   │ Target   │   │ Target   │        │
│              │ Group 1  │   │ Group 2  │   │ Group 3  │        │
│              └──────────┘   └──────────┘   └──────────┘        │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

ALB Features

Path-based routing: /api/* → API servers
Host-based routing: api.example.com → API, www.example.com → Web
SSL termination: HTTPS offloading
Health checks: Automatic target monitoring
Sticky sessions: Cookie-based affinity

Route 53

AWS DNS service with health checking and traffic routing.

Routing Policies

Policy	Use Case
Simple	Single resource
Weighted	A/B testing, gradual rollouts
Latency	Route to lowest latency region
Failover	Active-passive DR
Geolocation	Route by user location
Geoproximity	Route by geographic distance
Multi-value	Return multiple healthy IPs

┌────────────────────────────────────────────────────────────────┐
│                  Route 53 Failover Routing                      │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│   DNS Query: api.example.com                                    │
│                   │                                             │
│                   ▼                                             │
│           ┌──────────────┐                                      │
│           │   Route 53   │                                      │
│           │ Health Check │                                      │
│           └──────┬───────┘                                      │
│                  │                                              │
│         ┌────────┴────────┐                                     │
│         │                 │                                     │
│         ▼                 ▼                                     │
│   ┌───────────┐    ┌───────────┐                               │
│   │  Primary  │    │ Secondary │                               │
│   │ us-east-1 │    │ us-west-2 │                               │
│   │  (active) │    │ (standby) │                               │
│   └───────────┘    └───────────┘                               │
│                                                                 │
│   If primary fails health check → Route to secondary            │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

CloudFront (CDN)

Content Delivery Network for low-latency content delivery.

┌────────────────────────────────────────────────────────────────┐
│                    CloudFront Distribution                      │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│   User (Europe)                  User (Asia)                    │
│        │                              │                         │
│        ▼                              ▼                         │
│   ┌─────────────┐              ┌─────────────┐                 │
│   │ Edge (EU)   │              │ Edge (Asia) │                 │
│   │ Paris       │              │ Tokyo       │                 │
│   └──────┬──────┘              └──────┬──────┘                 │
│          │                            │                         │
│          │      Cache Miss?           │                         │
│          └──────────┬─────────────────┘                         │
│                     │                                           │
│                     ▼                                           │
│             ┌──────────────┐                                    │
│             │   Origin     │                                    │
│             │ (S3 or ALB)  │                                    │
│             │  us-east-1   │                                    │
│             └──────────────┘                                    │
│                                                                 │
│   Benefits:                                                     │
│   • Low latency (edge caching)                                  │
│   • DDoS protection                                             │
│   • SSL/TLS termination                                         │
│   • Origin protection                                           │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

VPC Peering & Transit Gateway

Connect VPCs together.

VPC Peering

┌─────────────────┐         ┌─────────────────┐
│   VPC A         │         │   VPC B         │
│ 10.0.0.0/16     │◄───────►│ 10.1.0.0/16     │
│                 │ Peering │                 │
└─────────────────┘         └─────────────────┘

• 1-to-1 connection
• Non-transitive (A↔B, B↔C doesn't mean A↔C)
• Cross-region supported

Transit Gateway

                    ┌─────────────────┐
                    │ Transit Gateway │
                    └────────┬────────┘
               ┌─────────────┼─────────────┐
               │             │             │
        ┌──────▼──────┐ ┌────▼────┐ ┌──────▼──────┐
        │   VPC A     │ │  VPC B  │ │   VPC C     │
        │ 10.0.0.0/16 │ │10.1.0.0 │ │ 10.2.0.0/16 │
        └─────────────┘ └─────────┘ └─────────────┘

• Hub-and-spoke model
• Transitive routing
• Connect VPCs, VPNs, Direct Connect

🎯 Interview Questions

Q1: How would you design a VPC for a 3-tier web application?

Architecture:

VPC: 10.0.0.0/16 (65,536 IPs)
Subnets (across 3 AZs):
- Public: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24
- Private (App): 10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24
- Private (DB): 10.0.20.0/24, 10.0.21.0/24, 10.0.22.0/24
Components:
- ALB in public subnets
- NAT Gateway per AZ (for HA)
- App servers in private subnets
- RDS Multi-AZ in DB subnets
Security:
- alb-sg: 443 from 0.0.0.0/0
- web-sg: 8080 from alb-sg
- db-sg: 3306 from web-sg
Routing:
- Public: 0.0.0.0/0 → IGW
- Private: 0.0.0.0/0 → NAT Gateway

Q2: What's the difference between Security Groups and NACLs?

Security Groups:

Operate at instance level
Stateful (return traffic auto-allowed)
Allow rules only
All rules evaluated
Primary security layer

NACLs:

Operate at subnet level
Stateless (must allow return traffic)
Allow AND Deny rules
Rules evaluated in order
Secondary layer for compliance

Best Practice: Use both for defense in depth. Security groups for fine-grained control, NACLs for subnet-level blocking.

Q3: When would you use ALB vs NLB?

Use ALB when:

HTTP/HTTPS traffic
Need path-based routing (/api, /static)
Need host-based routing (api.example.com)
WebSocket support
Container-based apps with dynamic ports

Use NLB when:

TCP/UDP traffic
Need ultra-low latency (<100ms)
Need static IP/Elastic IP
Gaming, IoT, financial apps
Need to preserve source IP

Cost Note: NLB is cheaper at high throughput

Q4: How do you troubleshoot EC2 connectivity issues?

Systematic approach:

Security Groups: Check inbound/outbound rules

aws ec2 describe-security-groups --group-ids sg-xxx

NACLs: Check subnet NACL rules (inbound AND outbound)

Route Tables: Verify route to destination exists

aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-xxx"

Internet Gateway: For public access, ensure IGW attached
NAT Gateway: For private subnet outbound, check NAT
VPC Flow Logs: Enable to see accepted/rejected traffic
Instance level: Check OS firewall (iptables, Windows Firewall)

Q5: How do you connect multiple VPCs?

Options:

VPC Peering:
- 1-to-1 connection
- Non-transitive
- Good for fewer than 10 VPCs
- No single point of failure
Transit Gateway:
- Hub-and-spoke model
- Transitive routing
- Scales to 5,000+ VPCs
- Centralized management
- ~ $0.05/GB +$ 0.05/attachment/hour
PrivateLink:
- Expose service to other VPCs
- One-way access
- No IP overlap concerns

Recommendation:

Fewer than 5 VPCs: VPC Peering
5+ VPCs: Transit Gateway

🧪 Hands-On Lab: Build a Secure 3-Tier VPC

Objective: Create a production-ready VPC with proper network segmentation

Create VPC with CIDR 10.0.0.0/16

Enable DNS hostnames and DNS support

Create Subnets

3 public (10.0.1-3.0/24), 3 private app (10.0.10-12.0/24), 3 private DB (10.0.20-22.0/24)

Create Internet Gateway

Attach to VPC, create public route table with 0.0.0.0/0 → IGW

Create NAT Gateways

One per AZ in public subnets, create private route tables

Create Security Groups

alb-sg, web-sg, db-sg with proper chaining

Deploy ALB + EC2 + RDS

Test connectivity between tiers

Enable VPC Flow Logs

Send to CloudWatch Logs for network monitoring

Networking Best Practices Summary

Key Takeaways:

Always use at least 2 AZs for high availability
Place only load balancers in public subnets
Use security group chaining (reference SGs, not IPs)
Plan CIDR blocks to avoid overlap for future peering
Use NAT Gateway per AZ for HA
Enable VPC Flow Logs for troubleshooting
Use Transit Gateway for 5+ VPCs

Next Module

Security

Master IAM, KMS, encryption, and security best practices

​Module Overview

​VPC (Virtual Private Cloud)

​VPC Architecture Deep Dive

​CIDR Planning Guide

​VPC with Terraform

​Subnets

​Public vs Private Subnets

​Gateways

​Internet Gateway (IGW)

​NAT Gateway

​Security Groups Deep Dive

​Security Group Architecture

​Security Group with Terraform

​Security Groups vs NACLs

​Load Balancing

​Load Balancer Types

​Application Load Balancer (ALB)

​ALB Features

​Route 53

​Routing Policies

​CloudFront (CDN)

​VPC Peering & Transit Gateway

​VPC Peering

​Transit Gateway

​🎯 Interview Questions

​🧪 Hands-On Lab: Build a Secure 3-Tier VPC

​Networking Best Practices Summary

​Next Module

Security

Module Overview

VPC (Virtual Private Cloud)

VPC Architecture Deep Dive

CIDR Planning Guide

VPC with Terraform

Subnets

Public vs Private Subnets

Gateways

Internet Gateway (IGW)

NAT Gateway

Security Groups Deep Dive

Security Group Architecture

Security Group with Terraform

Security Groups vs NACLs

Load Balancing

Load Balancer Types

Application Load Balancer (ALB)

ALB Features

Route 53

Routing Policies

CloudFront (CDN)

VPC Peering & Transit Gateway

VPC Peering

Transit Gateway

🎯 Interview Questions

🧪 Hands-On Lab: Build a Secure 3-Tier VPC

Networking Best Practices Summary

Next Module