Amazon VPC Networking: NAT Gateway, VPN, and Direct Connect

You’ve built a VPC, launched instances, and everything works—until your private subnet needs to download a security patch. That’s when you realize: no internet access. Cue the NAT Gateway. But that’s just the start. In production, you’ll also need to connect your data center to AWS, and choosing between VPN and Direct Connect can make or break your latency budget. I’ve seen teams burn thousands on misconfigured VPNs or overprovisioned Direct Connect circuits. This article cuts through the noise: when to use NAT Gateway, how to size it, and the real trade-offs between VPN and Direct Connect. No fluff, just the patterns that survive production.

VPC Networking: The Foundation

A VPC is your private network in AWS. It's not just a sandbox—it's the backbone of your infrastructure. Every subnet, route table, and gateway you configure directly impacts latency, cost, and security. Start with a clear CIDR block (e.g., 10.0.0.0/16) and plan for growth. Avoid overlapping with on-premises ranges if you'll connect via VPN or Direct Connect. Use public subnets for internet-facing resources and private subnets for databases and internal services. Always tag subnets for environment (prod, staging) and purpose (public, private). This discipline prevents routing chaos later.

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "prod-vpc"
  }
}

resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index)
  availability_zone = element(data.aws_availability_zones.available.names, count.index)
  map_public_ip_on_launch = true
  tags = {
    Name = "prod-public-${count.index}"
  }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index + 10)
  availability_zone = element(data.aws_availability_zones.available.names, count.index)
  tags = {
    Name = "prod-private-${count.index}"
  }
}

Internet Gateway: The Front Door

An Internet Gateway (IGW) is a horizontally scaled, redundant component that allows communication between your VPC and the internet. It's not a NAT device—it's a target for routes. Attach one IGW per VPC, then add a route in your public subnet's route table pointing 0.0.0.0/0 to the IGW. Without it, public instances can't reach the internet or be reached from it. IGWs are free, but data transfer costs apply. For high availability, ensure public subnets span at least two AZs. The IGW itself is fully managed and never a bottleneck.

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "prod-igw"
  }
}

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 = "prod-public-rt"
  }
}

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

NAT Gateway: Outbound Access for Private Subnets

A NAT Gateway enables instances in private subnets to initiate outbound traffic to the internet (e.g., for software updates) while preventing inbound connections from the internet. It's managed, scales automatically, and supports up to 45 Gbps. Place it in a public subnet with an Elastic IP. Each AZ should have its own NAT Gateway for high availability—a single NAT Gateway is a single point of failure. Costs include hourly charges and data processing fees. For cost-sensitive workloads, consider a NAT Instance (EC2) but accept the operational overhead. Always route private subnet traffic (0.0.0.0/0) to the NAT Gateway in the same AZ to avoid cross-AZ data transfer charges.

resource "aws_eip" "nat" {
  count = 2
  domain = "vpc"
  tags = {
    Name = "prod-nat-eip-${count.index}"
  }
}

resource "aws_nat_gateway" "main" {
  count         = 2
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
  tags = {
    Name = "prod-nat-${count.index}"
  }
}

resource "aws_route_table" "private" {
  count  = 2
  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 = "prod-private-rt-${count.index}"
  }
}

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

VPC Peering: Direct Connectivity Between VPCs

VPC Peering connects two VPCs using AWS's internal network, with no bandwidth bottleneck and no single point of failure. It's not transitive—if VPC A peers with B and B peers with C, A cannot reach C via B. You must establish full mesh peering or use a Transit Gateway. Peering works across accounts and regions (inter-region peering). Add routes in both VPCs' route tables to direct traffic to the peering connection. Security groups and NACLs still apply. Use VPC Peering for simple, low-latency connections between a few VPCs. For many VPCs, Transit Gateway is more manageable.

resource "aws_vpc_peering_connection" "peer" {
  vpc_id      = aws_vpc.main.id
  peer_vpc_id = aws_vpc.secondary.id
  auto_accept = true
  tags = {
    Name = "prod-to-secondary"
  }
}

resource "aws_route" "peer_from_main" {
  route_table_id            = aws_route_table.private[0].id
  destination_cidr_block    = aws_vpc.secondary.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.peer.id
}

resource "aws_route" "peer_from_secondary" {
  route_table_id            = aws_vpc.secondary.main_route_table_id
  destination_cidr_block    = aws_vpc.main.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.peer.id
}

AWS Transit Gateway: Hub-and-Spoke Networking

Transit Gateway (TGW) acts as a central hub connecting VPCs, VPNs, and Direct Connect. It supports transitive routing, so one TGW can replace a mesh of VPC Peering connections. Attach VPCs, VPN tunnels, and Direct Connect virtual interfaces to the TGW. Use route tables within TGW to control traffic flow—for example, isolate development VPCs from production. TGW supports multicast and inter-region peering. Costs include hourly attachment fees and data processing. For large-scale networks, TGW simplifies management and reduces operational overhead.

resource "aws_ec2_transit_gateway" "main" {
  description = "prod-tgw"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
  tags = {
    Name = "prod-tgw"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "main" {
  subnet_ids         = aws_subnet.private[*].id
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.main.id
  tags = {
    Name = "prod-tgw-attach"
  }
}

resource "aws_ec2_transit_gateway_route_table" "prod" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  tags = {
    Name = "prod-tgw-rt"
  }
}

resource "aws_ec2_transit_gateway_route" "default" {
  destination_cidr_block = "0.0.0.0/0"
  transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.main.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.prod.id
}

Site-to-Site VPN: Secure On-Premises Connection

AWS Site-to-Site VPN creates encrypted tunnels between your VPC and on-premises network. It uses IPsec, supports dynamic routing (BGP) or static routes, and provides two tunnels for high availability. Each VPN connection requires a Virtual Private Gateway (VGW) or Transit Gateway on the AWS side, and a customer gateway (CGW) representing your on-premises router. BGP is preferred for automatic failover and route propagation. VPN is limited by internet bandwidth and latency—for high-throughput or low-latency needs, use Direct Connect. Monitor tunnel status with CloudWatch and set up alarms for tunnel down events.

resource "aws_vpn_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "prod-vgw"
  }
}

resource "aws_customer_gateway" "main" {
  bgp_asn    = 65000
  ip_address = "203.0.113.12"
  type       = "ipsec.1"
  tags = {
    Name = "prod-cgw"
  }
}

resource "aws_vpn_connection" "main" {
  vpn_gateway_id      = aws_vpn_gateway.main.id
  customer_gateway_id = aws_customer_gateway.main.id
  type                = "ipsec.1"
  static_routes_only  = false
  tags = {
    Name = "prod-vpn"
  }
}

resource "aws_vpn_connection_route" "on_prem" {
  destination_cidr_block = "192.168.0.0/16"
  vpn_connection_id      = aws_vpn_connection.main.id
}

AWS Direct Connect: Dedicated Private Connectivity

Direct Connect provides a dedicated, private network connection from your on-premises data center to AWS. It bypasses the internet, offering lower latency, higher bandwidth (up to 100 Gbps), and more consistent performance. You order a cross-connect at a Direct Connect location, then create a virtual interface (VLAN) to your VPC or Transit Gateway. Use a private VIF for VPC access or a public VIF for AWS public services (e.g., S3). Direct Connect is not encrypted by default—add IPsec VPN over the connection for encryption. Costs include port hours and data transfer out. For redundancy, order two connections to different locations.

resource "aws_dx_connection" "main" {
  name      = "prod-dx"
  bandwidth = "1Gbps"
  location  = "EqDC2"
}

resource "aws_dx_private_virtual_interface" "main" {
  connection_id    = aws_dx_connection.main.id
  name             = "prod-dx-vif"
  vlan             = 100
  address_family   = "ipv4"
  bgp_asn          = 65000
  amazon_address   = "169.254.10.1/30"
  customer_address = "169.254.10.2/30"
  dx_gateway_id    = aws_dx_gateway.main.id
}

resource "aws_dx_gateway" "main" {
  name            = "prod-dxgw"
  amazon_side_asn = "64512"
}

resource "aws_dx_gateway_association" "main" {
  dx_gateway_id         = aws_dx_gateway.main.id
  associated_gateway_id = aws_ec2_transit_gateway.main.id
}

Routing and Security: Putting It All Together

With multiple connectivity options, routing becomes complex. Use route tables, prefix lists, and route propagation to manage traffic. For VPCs with VPN or Direct Connect, enable route propagation on the VGW or TGW to automatically add routes. Use network ACLs (NACLs) for stateless filtering at the subnet level and security groups for stateful filtering at the instance level. NACLs are evaluated before security groups. For hybrid networks, ensure your on-premises routes don't conflict with VPC routes. Use AWS Transit Gateway route tables to isolate environments. Monitor with VPC Flow Logs to detect anomalies.

resource "aws_network_acl" "public" {
  vpc_id = aws_vpc.main.id
  egress {
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
    protocol   = "-1"
  }
  ingress {
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 80
    to_port    = 80
    protocol   = "tcp"
  }
  tags = {
    Name = "prod-public-nacl"
  }
}

resource "aws_flow_log" "main" {
  log_destination      = aws_s3_bucket.flow_logs.arn
  log_destination_type = "s3"
  traffic_type         = "ALL"
  vpc_id               = aws_vpc.main.id
  tags = {
    Name = "prod-flow-log"
  }
}