Network Architecture and Connectivity

Table of Contents

1. Introduction: The Multi-Cloud Network Nightmare

2. Network Design Fundamentals

3. Hub-and-Spoke vs Transit Gateway vs Virtual WAN

4. VPC/VNet Design Patterns

5. Hybrid Connectivity: VPN and Direct Connect

6. DNS Architecture

7. Network Security: Firewalls and Inspection

8. Load Balancing and Traffic Management

9. Network Segmentation and Microsegmentation

10. Service Endpoints and Private Endpoints

11. Cross-Region and Multi-Cloud Networking

12. Network Monitoring and Troubleshooting

13. What I Learned About Cloud Networking

---

Introduction

Network architecture is one of the most critical yet frequently underestimated aspects of cloud landing zones. Through my work on multi-cloud projects, I've seen firsthand how poor network design creates cascading operational problems.

In one complex project involving AWS, Azure, and on-premises infrastructure, I encountered typical network challenges that arise when connectivity is treated as an afterthought:

• Multiple cloud platforms with no centralized network strategy

• Numerous point-to-point VPN connections managed manually

• Overlapping IP address ranges across different VPCs and VNets

• Lack of network segmentation between environments

• Complex firewall rules documented in spreadsheets

• DNS resolution issues across cloud boundaries

These networking problems stemmed from not establishing a clear network architecture before deploying workloads. Through the process of redesigning network architectures and implementing proper hub-and-spoke topologies, I've learned that investing in network design upfront prevents significant operational issues later.

This article shares the network architecture patterns and best practices I've developed through hands-on experience - covering hub-and-spoke topologies, hybrid connectivity, DNS strategies, network security, and the common pitfalls to avoid when building cloud networks.

---

Network Design Fundamentals

Before diving into specific technologies, let's establish the core principles that make or break cloud network architecture.

Principle 1: Connectivity Models

There are three primary models for connecting cloud resources:

Model 1: Flat Network (Don't Do This)

All resources in one large network:
├── Production databases
├── Development servers
├── Test environments
└── Everything can talk to everything

Why it fails:

• ❌ No isolation (dev can accidentally affect prod)

• ❌ Security nightmare (lateral movement)

• ❌ No traffic control

• ❌ Blast radius = entire network

Use case: Never. This is an anti-pattern.

Model 2: Hub-and-Spoke (Most Common)

Central Hub:
├── Connectivity to on-premises
├── Shared services (DNS, monitoring)
├── Centralized security inspection
└── Single entry/exit point

Spoke 1 (Production) → Hub
Spoke 2 (Staging) → Hub
Spoke 3 (Development) → Hub
Spoke 4 (Shared Services) → Hub

Advantages:

• ✅ Centralized management

• ✅ Scalable (O(n) connections)

• ✅ Centralized security inspection

• ✅ Clear separation between environments

Disadvantages:

• ❌ Hub can be bottleneck (design accordingly)

• ❌ Additional latency (hop through hub)

• ❌ More complex to implement initially

Use case: Most landing zones (90%+ of implementations)

Model 3: Mesh with Transit Gateway/Virtual WAN

Transit Gateway (AWS) or Virtual WAN (Azure):
├── Spoke 1 ↔ Spoke 2 (selective connectivity)
├── Spoke 3 isolated
├── Centralized routing
└── Advanced routing policies

Advantages:

• ✅ Selective spoke-to-spoke connectivity

• ✅ Advanced routing policies

• ✅ Highly scalable

• ✅ Built-in security features

Disadvantages:

• ❌ Higher cost

• ❌ More complex routing

• ❌ Cloud-specific (not easily multi-cloud)

Use case: Large enterprises (100+ accounts), complex routing requirements

Principle 2: Subnetting Strategy

The Pattern:

VPC/VNet: 10.X.0.0/16 (65,536 IPs)
├── Public Subnets:  10.X.0.0/20   (4,096 IPs)
│   ├── AZ1: 10.X.0.0/22   (1,024 IPs)
│   ├── AZ2: 10.X.4.0/22   (1,024 IPs)
│   └── AZ3: 10.X.8.0/22   (1,024 IPs)
├── Private Subnets: 10.X.16.0/20  (4,096 IPs)
│   ├── AZ1: 10.X.16.0/22  (1,024 IPs)
│   ├── AZ2: 10.X.20.0/22  (1,024 IPs)
│   └── AZ3: 10.X.24.0/22  (1,024 IPs)
└── Database Subnets: 10.X.32.0/20 (4,096 IPs)
    ├── AZ1: 10.X.32.0/22  (1,024 IPs)
    ├── AZ2: 10.X.36.0/22  (1,024 IPs)
    └── AZ3: 10.X.40.0/22  (1,024 IPs)

Why this works:

• ✅ Consistent pattern across all VPCs

• ✅ Room for growth (48,000+ IPs unused)

• ✅ Multi-AZ high availability

• ✅ Clear subnet purposes

• ✅ Easy to calculate next available block

Terraform - Automated Subnet Calculation:

variable "vpc_cidr" {
  description = "VPC CIDR block"
  type        = string
  default     = "10.1.0.0/16"
}

locals {
  # Calculate subnet CIDR blocks
  public_subnet_cidrs = [
    cidrsubnet(var.vpc_cidr, 6, 0),  # 10.1.0.0/22
    cidrsubnet(var.vpc_cidr, 6, 1),  # 10.1.4.0/22
    cidrsubnet(var.vpc_cidr, 6, 2),  # 10.1.8.0/22
  ]
  
  private_subnet_cidrs = [
    cidrsubnet(var.vpc_cidr, 6, 4),  # 10.1.16.0/22
    cidrsubnet(var.vpc_cidr, 6, 5),  # 10.1.20.0/22
    cidrsubnet(var.vpc_cidr, 6, 6),  # 10.1.24.0/22
  ]
  
  database_subnet_cidrs = [
    cidrsubnet(var.vpc_cidr, 6, 8),  # 10.1.32.0/22
    cidrsubnet(var.vpc_cidr, 6, 9),  # 10.1.36.0/22
    cidrsubnet(var.vpc_cidr, 6, 10), # 10.1.40.0/22
  ]
}

# Create public subnets
resource "aws_subnet" "public" {
  count             = length(local.public_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.public_subnet_cidrs[count.index]
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  map_public_ip_on_launch = true
  
  tags = {
    Name = "public-subnet-${count.index + 1}"
    Tier = "public"
  }
}

# Create private subnets
resource "aws_subnet" "private" {
  count             = length(local.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.private_subnet_cidrs[count.index]
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  tags = {
    Name = "private-subnet-${count.index + 1}"
    Tier = "private"
  }
}

# Create database subnets
resource "aws_subnet" "database" {
  count             = length(local.database_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.database_subnet_cidrs[count.index]
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  tags = {
    Name = "database-subnet-${count.index + 1}"
    Tier = "database"
  }
}

Principle 3: IP Address Management (IPAM)

The Problem: Without central IPAM, teams pick random CIDRs:

• Account 1: 10.0.0.0/16 ✅

• Account 2: 10.0.0.0/16 ❌ (conflict!)

• Account 3: 172.16.0.0/16 ✅

• Account 4: 10.0.0.0/24 ❌ (overlaps with Account 1)

The Solution: Centralized IPAM Registry

AWS IPAM:

# Create IPAM
resource "aws_vpc_ipam" "main" {
  description = "Organization IPAM"
  
  operating_regions {
    region_name = "us-east-1"
  }
  
  operating_regions {
    region_name = "us-west-2"
  }
  
  operating_regions {
    region_name = "eu-west-1"
  }
}

# Top-level pool (entire organization)
resource "aws_vpc_ipam_pool" "top_level" {
  address_family = "ipv4"
  ipam_scope_id  = aws_vpc_ipam.main.private_default_scope_id
  locale         = "us-east-1"
  
  description = "Top-level IPAM pool"
}

# Regional pool (us-east-1)
resource "aws_vpc_ipam_pool" "us_east_1" {
  address_family      = "ipv4"
  ipam_scope_id       = aws_vpc_ipam.main.private_default_scope_id
  locale              = "us-east-1"
  source_ipam_pool_id = aws_vpc_ipam_pool.top_level.id
  
  description = "US-East-1 regional pool"
}

# IPAM pool CIDR
resource "aws_vpc_ipam_pool_cidr" "top_level" {
  ipam_pool_id = aws_vpc_ipam_pool.top_level.id
  cidr         = "10.0.0.0/8"  # Entire 10.x.x.x space
}

# Allocate from IPAM automatically
resource "aws_vpc" "auto_allocated" {
  ipv4_ipam_pool_id   = aws_vpc_ipam_pool.us_east_1.id
  ipv4_netmask_length = 16  # Request a /16
  
  tags = {
    Name = "auto-allocated-vpc"
  }
}

Azure IPAM (using Virtual Network Manager):

# Create IPAM pools in Virtual Network Manager
resource "azurerm_network_manager" "main" {
  name                = "ipam-network-manager"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  scope {
    subscription_ids = [data.azurerm_subscription.current.id]
  }
  scope_accesses = ["Connectivity"]
}

# Define IP address pools
resource "azurerm_network_manager_network_group" "ipam" {
  name               = "ipam-pools"
  network_manager_id = azurerm_network_manager.main.id
}

# Track IPAM allocations in Storage Table
resource "azurerm_storage_table" "ipam" {
  name                 = "ipamregistry"
  storage_account_name = azurerm_storage_account.main.name
}

# Example IPAM registry entry
resource "azurerm_storage_table_entity" "vpc_allocation" {
  storage_account_name = azurerm_storage_account.main.name
  table_name           = azurerm_storage_table.ipam.name
  
  partition_key = "vnet-allocations"
  row_key       = "prod-app-vnet"
  
  entity = {
    VNetName    = "prod-app-vnet"
    CIDR        = "10.1.0.0/16"
    Environment = "production"
    Application = "payment-api"
    Owner       = "[email protected]"
    AllocatedDate = timestamp()
  }
}

Manual IPAM Registry (Simple Spreadsheet/Database):

Account/Subscription	VPC/VNet Name	CIDR Block	Environment	Purpose	Owner
prod-payment	prod-payment-vpc	10.1.0.0/16	Production	Payment API	platform-team
stage-payment	stage-payment-vpc	10.2.0.0/16	Staging	Payment API	platform-team
prod-user	prod-user-vpc	10.3.0.0/16	Production	User Service	user-team
shared-services	shared-vpc	10.100.0.0/16	Platform	DNS, Monitoring	platform-team
network-hub	hub-vpc	10.0.0.0/16	Platform	Transit Gateway Hub	network-team

Principle 4: Traffic Flow Patterns

North-South Traffic (Client ↔ Cloud):

• External users accessing cloud applications

• Use: Load balancers, API gateways, CDNs

• Security: WAF, DDoS protection, TLS termination

East-West Traffic (Cloud ↔ Cloud):

• Inter-VPC/VNet communication

• Use: Transit Gateway, VPC peering, VNet peering

• Security: Network segmentation, security groups, NACLs

Hybrid Traffic (Cloud ↔ On-Premises):

• Cloud to data center connectivity

• Use: VPN, Direct Connect, ExpressRoute

• Security: Encryption, dedicated circuits, firewall inspection

---

Hub-and-Spoke vs Transit Gateway vs Virtual WAN

Let's compare the three main connectivity patterns with real-world examples.

Option 1: Traditional Hub-and-Spoke (VPC/VNet Peering)

Architecture:

AWS Implementation:

# Hub VPC
resource "aws_vpc" "hub" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name = "hub-vpc"
    Purpose = "Central connectivity hub"
  }
}

# Spoke VPC (Production)
resource "aws_vpc" "spoke_prod" {
  cidr_block           = "10.1.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name = "spoke-prod-vpc"
    Environment = "production"
  }
}

# VPC Peering: Spoke to Hub
resource "aws_vpc_peering_connection" "spoke_prod_to_hub" {
  vpc_id        = aws_vpc.spoke_prod.id
  peer_vpc_id   = aws_vpc.hub.id
  auto_accept   = true
  
  tags = {
    Name = "spoke-prod-to-hub"
  }
}

# Route: Spoke to Hub
resource "aws_route" "spoke_to_hub" {
  route_table_id            = aws_route_table.spoke_prod_private.id
  destination_cidr_block    = "0.0.0.0/0"  # All traffic via hub
  vpc_peering_connection_id = aws_vpc_peering_connection.spoke_prod_to_hub.id
}

# Route: Hub to Spoke
resource "aws_route" "hub_to_spoke_prod" {
  route_table_id            = aws_route_table.hub_private.id
  destination_cidr_block    = aws_vpc.spoke_prod.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.spoke_prod_to_hub.id
}

# VPN Gateway in Hub (for on-premises connectivity)
resource "aws_vpn_gateway" "hub" {
  vpc_id = aws_vpc.hub.id
  
  tags = {
    Name = "hub-vpn-gateway"
  }
}

# Customer Gateway (on-premises)
resource "aws_customer_gateway" "onprem" {
  bgp_asn    = 65000
  ip_address = var.onprem_public_ip
  type       = "ipsec.1"
  
  tags = {
    Name = "onprem-customer-gateway"
  }
}

# VPN Connection
resource "aws_vpn_connection" "hub_to_onprem" {
  vpn_gateway_id      = aws_vpn_gateway.hub.id
  customer_gateway_id = aws_customer_gateway.onprem.id
  type                = "ipsec.1"
  static_routes_only  = false  # Use BGP
  
  tags = {
    Name = "hub-to-onprem-vpn"
  }
}

Pros:

• ✅ Simple to understand and implement

• ✅ Low cost (no additional transit gateway fees)

• ✅ Direct connectivity between hub and spokes

Cons:

• ❌ Spoke-to-spoke traffic must route through hub (extra hop)

• ❌ Manual peering setup for each spoke

• ❌ Limited to ~125 peering connections per VPC (scalability limit)

Use case: Small to medium deployments (<50 accounts)

Option 2: AWS Transit Gateway

Architecture:

AWS Implementation:

# Transit Gateway
resource "aws_ec2_transit_gateway" "main" {
  description                     = "Main transit gateway"
  default_route_table_association = "disable"  # Manually control routing
  default_route_table_propagation = "disable"
  dns_support                     = "enable"
  vpn_ecmp_support               = "enable"  # Equal-cost multi-path for VPNs
  
  tags = {
    Name = "main-tgw"
  }
}

# Production Route Table
resource "aws_ec2_transit_gateway_route_table" "production" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  
  tags = {
    Name = "production-route-table"
  }
}

# Non-Production Route Table
resource "aws_ec2_transit_gateway_route_table" "non_production" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  
  tags = {
    Name = "non-production-route-table"
  }
}

# Shared Services Route Table
resource "aws_ec2_transit_gateway_route_table" "shared" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  
  tags = {
    Name = "shared-services-route-table"
  }
}

# Attach Production VPC to Transit Gateway
resource "aws_ec2_transit_gateway_vpc_attachment" "prod" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.prod.id
  subnet_ids         = aws_subnet.prod_private[*].id
  
  transit_gateway_default_route_table_association = false
  transit_gateway_default_route_table_propagation = false
  
  tags = {
    Name = "prod-vpc-attachment"
  }
}

# Associate Production VPC with Production Route Table
resource "aws_ec2_transit_gateway_route_table_association" "prod" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.prod.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

# Allow Production to communicate with Shared Services
resource "aws_ec2_transit_gateway_route_table_propagation" "prod_to_shared" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.shared.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

# Deny Production to Non-Production (implicit - no propagation)

# VPN Attachment for On-Premises
resource "aws_vpn_connection" "onprem" {
  customer_gateway_id = aws_customer_gateway.onprem.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  type                = "ipsec.1"
  
  tags = {
    Name = "onprem-vpn"
  }
}

# Route in VPC to Transit Gateway
resource "aws_route" "prod_to_tgw" {
  route_table_id         = aws_route_table.prod_private.id
  destination_cidr_block = "10.0.0.0/8"  # All internal traffic via TGW
  transit_gateway_id     = aws_ec2_transit_gateway.main.id
}

Routing Rules Example:

# Production Route Table Rules
# Allows:
# - Production VPCs to Shared Services
# - Production VPCs to On-Premises
# Denies:
# - Production to Non-Production (no propagation)

resource "aws_ec2_transit_gateway_route" "prod_to_onprem" {
  destination_cidr_block         = "192.168.0.0/16"  # On-premises CIDR
  transit_gateway_attachment_id  = aws_vpn_connection.onprem.transit_gateway_attachment_id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

# Shared Services Route Table Rules
# Allows:
# - Shared Services to Production
# - Shared Services to Non-Production
# - Shared Services to On-Premises

resource "aws_ec2_transit_gateway_route_table_propagation" "shared_to_prod" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.prod.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.shared.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "shared_to_nonprod" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.nonprod.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.shared.id
}

Pros:

• ✅ Highly scalable (5,000+ VPC attachments)

• ✅ Advanced routing policies (route table separation)

• ✅ Centralized management

• ✅ Inter-region peering

• ✅ Simplified network architecture

Cons:

• ❌ Additional cost ($0.05/hour per attachment + data transfer)

• ❌ More complex to configure initially

• ❌ AWS-specific (not multi-cloud)

Use case: Medium to large AWS deployments (50+ accounts), complex routing requirements

Option 3: Azure Virtual WAN

Architecture:

Azure Implementation:

# Virtual WAN
resource "azurerm_virtual_wan" "main" {
  name                = "main-vwan"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  
  type = "Standard"  # Enables VNet-to-VNet through hub
}

# Virtual Hub (East US)
resource "azurerm_virtual_hub" "eastus" {
  name                = "hub-eastus"
  resource_group_name = azurerm_resource_group.main.name
  location            = "eastus"
  virtual_wan_id      = azurerm_virtual_wan.main.id
  address_prefix      = "10.0.0.0/23"  # Hub address space
}

# Virtual Hub (West Europe)
resource "azurerm_virtual_hub" "westeurope" {
  name                = "hub-westeurope"
  resource_group_name = azurerm_resource_group.main.name
  location            = "westeurope"
  virtual_wan_id      = azurerm_virtual_wan.main.id
  address_prefix      = "10.1.0.0/23"
}

# VNet Connection to Hub
resource "azurerm_virtual_hub_connection" "prod_eastus" {
  name                      = "prod-vnet-connection"
  virtual_hub_id            = azurerm_virtual_hub.eastus.id
  remote_virtual_network_id = azurerm_virtual_network.prod.id
  
  routing {
    associated_route_table_id = azurerm_virtual_hub_route_table.production.id
    
    propagated_route_table {
      route_table_ids = [
        azurerm_virtual_hub_route_table.shared_services.id
      ]
    }
  }
}

# VPN Gateway in Hub
resource "azurerm_vpn_gateway" "eastus" {
  name                = "vpn-gateway-eastus"
  location            = azurerm_virtual_hub.eastus.location
  resource_group_name = azurerm_resource_group.main.name
  virtual_hub_id      = azurerm_virtual_hub.eastus.id
}

# VPN Site (On-Premises)
resource "azurerm_vpn_site" "onprem" {
  name                = "onprem-site"
  location            = azurerm_virtual_hub.eastus.location
  resource_group_name = azurerm_resource_group.main.name
  virtual_wan_id      = azurerm_virtual_wan.main.id
  
  link {
    name       = "link1"
    ip_address = var.onprem_public_ip
    bgp {
      asn             = 65000
      peering_address = "192.168.1.1"
    }
  }
}

# VPN Connection
resource "azurerm_vpn_gateway_connection" "onprem" {
  name               = "onprem-connection"
  vpn_gateway_id     = azurerm_vpn_gateway.eastus.id
  remote_vpn_site_id = azurerm_vpn_site.onprem.id
  
  vpn_link {
    name             = "link1"
    vpn_site_link_id = azurerm_vpn_site.onprem.link[0].id
    bgp_enabled      = true
  }
}

# Custom Route Table (Production)
resource "azurerm_virtual_hub_route_table" "production" {
  name           = "production-route-table"
  virtual_hub_id = azurerm_virtual_hub.eastus.id
  
  route {
    name              = "to-shared-services"
    destinations_type = "CIDR"
    destinations      = ["10.100.0.0/16"]
    next_hop_type     = "ResourceId"
    next_hop          = azurerm_virtual_hub_connection.shared_services.id
  }
  
  # Deny route to non-production (omit route)
}

Pros:

• ✅ Global network (automatic hub-to-hub connectivity)

• ✅ Integrated security (Azure Firewall)

• ✅ Simplified management (single pane of glass)

• ✅ Built-in routing optimization

• ✅ Supports ExpressRoute and VPN simultaneously

Cons:

• ❌ Higher cost than traditional hub-spoke

• ❌ Azure-specific (not multi-cloud)

• ❌ Some advanced features require Standard SKU

Use case: Azure deployments with global presence, multiple regions

---

VPC/VNet Design Patterns

Pattern 1: Three-Tier Network Architecture

Classic web application pattern:

VPC/VNet: 10.1.0.0/16
├── Public Subnet (Web Tier)
│   ├── Load Balancer
│   ├── Bastion Host
│   └── NAT Gateway
├── Private Subnet (Application Tier)
│   ├── Application Servers
│   ├── API Servers
│   └── Microservices
└── Database Subnet (Data Tier)
    ├── RDS/SQL Database
    ├── ElastiCache/Redis
    └── Read Replicas

Terraform - Three-Tier VPC:

# VPC
resource "aws_vpc" "app" {
  cidr_block           = "10.1.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name = "app-vpc"
  }
}

# Internet Gateway (for public subnets)
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.app.id
  
  tags = {
    Name = "app-igw"
  }
}

# Public Subnets (3 AZs)
resource "aws_subnet" "public" {
  count             = 3
  vpc_id            = aws_vpc.app.id
  cidr_block        = cidrsubnet("10.1.0.0/20", 2, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  map_public_ip_on_launch = true
  
  tags = {
    Name = "public-subnet-${count.index + 1}"
    Tier = "public"
  }
}

# Private Subnets (3 AZs)
resource "aws_subnet" "private" {
  count             = 3
  vpc_id            = aws_vpc.app.id
  cidr_block        = cidrsubnet("10.1.16.0/20", 2, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  tags = {
    Name = "private-subnet-${count.index + 1}"
    Tier = "private"
  }
}

# Database Subnets (3 AZs)
resource "aws_subnet" "database" {
  count             = 3
  vpc_id            = aws_vpc.app.id
  cidr_block        = cidrsubnet("10.1.32.0/20", 2, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  tags = {
    Name = "database-subnet-${count.index + 1}"
    Tier = "database"
  }
}

# NAT Gateway (for private subnet internet access)
resource "aws_eip" "nat" {
  count  = 3
  domain = "vpc"
  
  tags = {
    Name = "nat-eip-${count.index + 1}"
  }
}

resource "aws_nat_gateway" "main" {
  count         = 3
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
  
  tags = {
    Name = "nat-gateway-${count.index + 1}"
  }
}

# Route Table: Public Subnets
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.app.id
  
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
  
  tags = {
    Name = "public-route-table"
  }
}

resource "aws_route_table_association" "public" {
  count          = 3
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

# Route Table: Private Subnets
resource "aws_route_table" "private" {
  count  = 3
  vpc_id = aws_vpc.app.id
  
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main[count.index].id
  }
  
  tags = {
    Name = "private-route-table-${count.index + 1}"
  }
}

resource "aws_route_table_association" "private" {
  count          = 3
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private[count.index].id
}

# Route Table: Database Subnets (no internet access)
resource "aws_route_table" "database" {
  vpc_id = aws_vpc.app.id
  
  # No default route (isolated)
  
  tags = {
    Name = "database-route-table"
  }
}

resource "aws_route_table_association" "database" {
  count          = 3
  subnet_id      = aws_subnet.database[count.index].id
  route_table_id = aws_route_table.database.id
}

# Security Group: Web Tier
resource "aws_security_group" "web" {
  name        = "web-tier-sg"
  description = "Security group for web tier"
  vpc_id      = aws_vpc.app.id
  
  ingress {
    description = "HTTPS from internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  ingress {
    description = "HTTP from internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  egress {
    description = "Allow all outbound"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  tags = {
    Name = "web-tier-sg"
  }
}

# Security Group: Application Tier
resource "aws_security_group" "app" {
  name        = "app-tier-sg"
  description = "Security group for application tier"
  vpc_id      = aws_vpc.app.id
  
  ingress {
    description     = "Traffic from web tier"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web.id]
  }
  
  egress {
    description = "Allow all outbound"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  tags = {
    Name = "app-tier-sg"
  }
}

# Security Group: Database Tier
resource "aws_security_group" "database" {
  name        = "database-tier-sg"
  description = "Security group for database tier"
  vpc_id      = aws_vpc.app.id
  
  ingress {
    description     = "PostgreSQL from app tier"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }
  
  # No egress rules (databases shouldn't initiate outbound connections)
  
  tags = {
    Name = "database-tier-sg"
  }
}

Traffic Flow:

Internet Users
    ↓ (HTTPS)
Load Balancer (Public Subnet)
    ↓ (HTTP/8080)
Application Servers (Private Subnet)
    ↓ (PostgreSQL/5432)
Database (Database Subnet - isolated)

Pattern 2: Microservices VPC

Service mesh architecture:

VPC: 10.2.0.0/16
├── Public Subnet
│   └── API Gateway / Load Balancer
├── Service Subnet 1 (User Service)
├── Service Subnet 2 (Order Service)
├── Service Subnet 3 (Payment Service)
└── Data Subnet
    ├── User DB
    ├── Order DB
    └── Payment DB

Key Features:

• Each microservice in separate subnet

• Service-to-service communication via private networking

• Network policies enforce service boundaries

• Centralized API gateway for external access

---

(Article continues with Hybrid Connectivity, DNS Architecture, Network Security, and more sections to reach 10,000+ words)

I'll create a comprehensive Article 4 continuing from here. Due to length constraints, would you like me to:

1. Complete Article 4 in full with remaining sections (Hybrid Connectivity, DNS, Security, Load Balancing, etc.)

2. Create Articles 5-12 systematically

Which would you prefer?