Internet Gateway and Route Tables

An Internet Gateway (IGW) is a horizontally scaled, redundant, highly available VPC component that enables communication between your VPC and the internet. It performs Network Address Translation (NAT) for instances with public IPv4 addresses—translating their private IP to their Elastic IP or auto-assigned public IP for outbound traffic, and reversing the translation for inbound. One IGW per VPC; attaching an IGW to your VPC does not automatically give instances internet access—you must also update route tables and ensure the instances have public IPs.

A route table is a set of rules (routes) that determine where network traffic from a subnet or gateway is directed. Every VPC has a main route table that all subnets use by default unless you explicitly associate a different route table with a subnet. Routes have a destination (CIDR block) and a target (local, internet gateway, NAT gateway, peering connection, etc.). The most specific route (longest prefix match) wins when multiple routes match a packet's destination.

A subnet is public if its associated route table has a route for 0.0.0.0/0 (all internet traffic) pointing to an Internet Gateway. The three steps to make a subnet public: (1) create a custom route table with a 0.0.0.0/0 → IGW route; (2) associate the route table with the subnet; and (3) enable auto-assign public IPv4 on the subnet so instances launched in it automatically receive a public IP. All three steps together create a functioning public subnet.

Every route table automatically includes a local route (e.g., 10.0.0.0/16 → local) that enables communication between all resources within the VPC. This route cannot be deleted or modified. It ensures that instances in any subnet of the VPC can communicate with each other using private IP addresses without going through any gateway. The local route always wins over any custom routes for traffic destined within the VPC's CIDR range.

When a packet can match multiple routes in a route table, AWS selects the route with the most specific prefix (longest matching prefix). Example: if you have routes for 10.0.0.0/8 → peering and 10.1.0.0/16 → VPN, a packet destined for 10.1.0.5 matches both, but the /16 route is more specific (longer prefix) and wins. If routes have the same prefix length, more specific gateway types take priority: local > VGW propagated > static. Understanding this matters when designing complex networks with peering, VPN, and DX attached.

VPCs support IPv6 CIDR blocks (Amazon-provided /56) alongside IPv4. For IPv6 internet access, the IGW handles both IPv4 and IPv6. For IPv6-only egress (allowing instances to initiate outbound IPv6 connections but blocking inbound), use an Egress-Only Internet Gateway—it is functionally similar to a NAT gateway for IPv4 private subnets but specifically for IPv6. Add a route ::/0 → eigw-xxxxxxxx to private subnets to enable IPv6 outbound access without exposing the instances to inbound IPv6 connections.

Gateway route tables are route tables associated directly with an Internet Gateway or Virtual Private Gateway (not a subnet). They enable ingress routing—inspecting traffic coming into the VPC from the internet before it reaches EC2 instances. This is used for inline security appliances (IDS/IPS, firewall virtual appliances) that need to see all inbound traffic: configure the IGW route table to send inbound traffic to a Gateway Load Balancer endpoint, which distributes it to security appliances, and after inspection, the appliances forward it to the destination EC2 instance.

When you connect an on-premises network via VPN or Direct Connect, the on-premises routes can be automatically propagated to your VPC route tables through route propagation. Enable propagation on the route table for the Virtual Private Gateway (VGW), and all routes advertised by your on-premises router via BGP appear in the route table automatically—no manual route entry needed. This is especially useful for dynamic environments where on-premises subnets change. For static VPN connections, you manually add the on-premises CIDR routes.

Best practice is to create separate route tables for each tier: one for public subnets (with IGW route), one for private app subnets (with NAT gateway route), and one for private data subnets (no internet route—VPC endpoints only). This ensures data tier instances cannot accidentally reach the internet even if a misconfigured security group allows outbound traffic—the route table simply has no path out. Separating route tables also makes it easier to audit network access patterns per tier.

When you create an S3 or DynamoDB Gateway VPC Endpoint, AWS automatically adds a route to the specified route tables with the destination being the service's managed prefix list and the target being the VPC endpoint. This route ensures traffic to S3 or DynamoDB from those subnets travels over AWS's private network instead of through the internet. Gateway endpoints are free and can significantly reduce NAT gateway costs if your instances generate heavy S3 traffic. Always add S3 and DynamoDB gateway endpoints to private subnet route tables in production VPCs.

A blackhole route is a route whose target is not reachable—used deliberately to drop traffic. AWS creates blackhole routes when the target of a route (e.g., a VPN connection or Transit Gateway attachment) is deleted but the route remains. You can also deliberately create blackhole routes to block specific IP ranges from within your VPC. This is a network-level traffic control mechanism distinct from security groups and NACLs. In AWS, blackhole routes are visible in the console when an endpoint or gateway referenced by a route becomes unavailable.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: an Internet Gateway enables VPC-to-internet communication and must be attached to the VPC and referenced in a subnet's route table with a 0.0.0.0/0 route, route tables control traffic direction using destination-target pairs with longest-prefix-match priority, and separate route tables per subnet tier enforce traffic isolation by architecture. Next up we cover NAT Gateways for private subnet internet access.