Right, so you’ve got a VPC. It’s a private, walled garden for your AWS resources. But let’s be honest, a garden where nothing can talk to the outside world is just a very expensive, digital prison. We need a way to let some of our resources—like a public web server—reach out to the internet to, you know, download security patches or check if a new cat video has dropped. That’s the Internet Gateway’s job. Think of it as the one heavily fortified, highly monitored gate in the wall of your VPC. It’s not a server; it’s a scaled, redundant AWS-managed thing that sits at the edge of your network and handles the translation between your private IP addresses and the public ones the internet understands.

The most important thing to remember is this: an Internet Gateway (IGW) is a necessary but not sufficient condition for internet access. Attaching one to your VPC is like building the gate itself. But you haven’t told anyone they’re allowed to use it yet. For that, you need two more things: a route in a route table and a public IP address. We’ll get to the gritty details of that in a second.

The Crucial Difference: Outbound vs. Inbound

This is where people’s brains short-circuit, so pay attention. An Internet Gateway enables two distinct communication paths, and they are NOT symmetric.

  1. Outbound Initiated Connections: This is what we’re focusing on here. An instance in your VPC (like a web server) initiates a request to a public endpoint, say api.github.com. The IGW allows this and handles the Network Address Translation (NAT) for the response to find its way back. This is the most common use case.
  2. Inbound Initiated Connections: This is for when you want someone on the public internet to be able to initiate a connection to your instance, like a user hitting your website on port 80 or 443. The IGW also allows this, but it requires that your instance has a public IP (or an Elastic IP) assigned. The IGW maps that public IP to the instance’s private IP.

For pure outbound access—which is what things in a private subnet often need—you’ll use a NAT Gateway, which is a different beast we’ll cover next. The IGW is for your public-facing stuff.

It’s All About the Route Tables

I cannot stress this enough: an IGW attached to a VPC does absolutely nothing on its own. It’s a dormant piece of infrastructure. The magic happens in the route tables. A route table is basically a set of signposts that tell network traffic where to go based on its destination IP.

To enable internet access for a subnet, you must associate that subnet with a route table that has a route sending non-local traffic (0.0.0.0/0) to the Internet Gateway.

Here’s a classic example. Let’s create the IGW, attach it, and then build a custom route table for our public subnets. Don’t just use the default main route table; it’s a bad habit. Be explicit.

# Create the Internet Gateway
aws ec2 create-internet-gateway

# You'll get an output like: { "InternetGateway": { "InternetGatewayId": "igw-12345abcde67890fg", ... } }
# Attach it to your VPC (replace vpc-12345678 with your VPC ID)
aws ec2 attach-internet-gateway --internet-gateway-id igw-12345abcde67890fg --vpc-id vpc-12345678

# Create a new public route table for your VPC
aws ec2 create-route-table --vpc-id vpc-12345678

# You'll get: { "RouteTable": { "RouteTableId": "rtb-98765zyxw54321vu", ... } }
# Now for the crucial part: add the route that points to the internet
aws ec2 create-route --route-table-id rtb-98765zyxw54321vu --destination-cidr-block 0.0.0.0/0 --gateway-id igw-12345abcde67890fg

# Finally, associate this public route table with your public subnet (replace subnet-aaaaaaaa)
aws ec2 associate-route-table --route-table-id rtb-98765zyxw54321vu --subnet-id subnet-aaaaaaaa

Now, any instance launched in subnet-aaaaaaaa will use this route table. If it has a public IP, its traffic to 0.0.0.0/0 will be directed to the IGW.

The Public IP Address Requirement

Here’s the other half of the equation. For an instance to actually communicate through the IGW, it must have a public IP address. This is non-negotiable. The IGW performs a 1:1 NAT, mapping the instance’s private IP to this public IP for all outbound traffic. When you launch an EC2 instance, you must explicitly enable “Auto-assign Public IP” for the subnet or the instance itself at launch. If you forget, you’re out of luck. The traffic might be routed to the IGW, but the IGW has no idea which public IP to use for the translation, so it drops the packet. The fix is to attach an Elastic IP to the instance, but it’s cleaner to get it right at launch.

The Default VPC: A Blessing and a Curse

AWS creates a “Default VPC” for you with every account. This is a great learning tool because it has an IGW pre-attached and its main route table already has the 0.0.0.0/0 -> igw-xxx route. Every subnet in the default VPC also has auto-assign public IP enabled by default. This is why your first EC2 instance “just works” with internet access. It’s also why the default VPC is a horrifyingly bad place for anything remotely serious from a security perspective. We build custom VPCs to get away from this overly permissive setup. Don’t get used to it.

Common Pitfalls and the “Ping” Test

The number one support ticket starter is: “I attached an IGW and added the route, but my instance can’t reach the internet. Why?” Let’s troubleshoot like pros.

  1. Is the route table associated with the correct subnet? I’ve spent hours debugging only to find I associated the route table with the private subnet by mistake. Check the AWS console; it’s painfully obvious once you look.
  2. Does the instance have a public IP? Check the instance’s details. No public IPv4 address? That’s your problem. Attach an Elastic IP.
  3. Security Groups and NACLs: The IGW doesn’t care about these. But your instance’s OS and its Security Group do. For outbound internet access, your instance’s Security Group must allow outbound traffic to 0.0.0.0/0 (which the default does). The Network ACL for the public subnet must also allow outbound ephemeral ports (32768-65535) for return traffic.
  4. The ping Fallacy: ping uses ICMP, not TCP or UDP. Many security groups are created to only allow SSH and HTTP, which blocks ICMP. So if you can curl https://google.com but you can’t ping google.com, it’s not the IGW—it’s your Security Group blocking ICMP. Test with a protocol you know is allowed.

The Internet Gateway is elegantly simple in concept but requires precise configuration. Get the trio right—IGW attached, route pointing to it, public IP assigned—and it works flawlessly. Miss one, and you’re just staring at a timeout.