You’ve built a virtual private cloud. Your instances are running. Your code is clean. But right now, that EC2 instance is basically a laptop in a basement with no Wi-Fi. It’s isolated. To fix this, you need to define AWS Internet Gateway (IGW) not just as a checkbox in a console, but as the literal door to the public internet.
Honestly, it’s one of those things people overlook until their yum update fails or their web server won't load. It’s a horizontally scaled, redundant, and highly available VPC component. It doesn't have a bandwidth limit. It doesn't crash because of high traffic. It just sits there, translating private IP addresses to public ones.
What an Internet Gateway actually does
Think of it as a two-way street. It serves two main purposes. First, it provides a target in your VPC route tables for internet-bound traffic. Second, it performs network address translation (NAT) for instances that have been assigned public IPv4 addresses.
Without an IGW, your VPC is a walled garden.
When you attach an internet gateway to your VPC, you aren't "installing" software. You're enabling a logical hook into the AWS edge. It supports both IPv4 and IPv6. For IPv4, it maps the private address of your instance to its public counterpart. This is a one-to-one mapping. For IPv6, since those addresses are globally unique by design, the gateway just routes the traffic without needing NAT.
Why you can't just skip it
Some folks think they can get away with just a NAT Gateway. That's a mistake. A NAT Gateway actually needs an Internet Gateway to function. The NAT Gateway lives in a public subnet and sends traffic through the IGW.
If you're trying to define AWS Internet Gateway for a production environment, you have to understand the "Public Subnet" rule. A subnet is only "public" because its route table has an entry pointing 0.0.0.0/0 (all traffic) to the IGW ID (which usually starts with igw-).
If that route doesn't exist? Your subnet is private. Even if your instance has a public IP, the packets won't know how to leave the building.
Setting it up without breaking things
The process is deceptively simple, which is where people trip up. You create the gateway. You attach it to a VPC. Then—and this is the part most people forget—you update your route tables.
- Go to the VPC Dashboard.
- Hit "Create Internet Gateway." Give it a tag. Name it something obvious like
prod-igw. - Select the gateway and click "Actions" -> "Attach to VPC."
- Find your Route Table.
- Add a route for
0.0.0.0/0with the target being your new IGW.
It’s worth noting that you can only attach one Internet Gateway to a VPC at a time. AWS designed it this way because the IGW is already distributed. You don't need to create "backups" for it. AWS handles the underlying infrastructure redundancy. It's essentially "infinitely" scalable. If your traffic spikes from 10 Mbps to 10 Gbps, the IGW doesn't care. It scales invisibly.
Real-world nuances and the Egress-Only catch
If you're working with IPv6, things get a bit weirder. You might use an Egress-Only Internet Gateway. This is a specialized version. It allows your instances to reach out to the internet (for updates or API calls) but prevents the internet from initiating a connection back to them. It’s like a one-way mirror for your network.
Jeff Barr and the AWS team have documented this extensively over the years, and the consensus is clear: the IGW is your primary point of entry. However, it is not a firewall.
Don't confuse an IGW with a Security Group or a Network ACL. The gateway is just the door. The Security Group is the bouncer standing at the door. If you open the IGW but forget to allow port 80 or 443 in your Security Group, your website is still going to be "down" as far as the world is concerned.
💡 You might also like: Hanging Wall vs. Footwall: The Geology Basics Most People Mix Up
Common misconceptions about IGW performance
A lot of network engineers coming from the on-prem world ask about "throughput limits." They want to know the "instance size" of the gateway.
There isn't one.
Unlike a NAT Gateway, which has specific throughput limits (usually starting at 5 Gbps and scaling to 100 Gbps), the Internet Gateway is a managed service that scales natively. You aren't billed for the amount of data passing through the IGW itself, though you are billed for the Data Transfer Out (DTO) from your EC2 instances. This is a subtle but massive distinction for your monthly AWS bill.
Actionable steps for your VPC
Don't just read about it. Go check your setup.
- Audit your Route Tables: Ensure your public subnets actually have a route to an
igw-id. If they don't, your "public" IPs are useless. - Check your NACLs: Ensure your Network Access Control Lists allow traffic on ephemeral ports (1024-65535) to handle the return traffic from the IGW.
- Use IPv6 where possible: It simplifies the routing logic and avoids the need for complex NAT setups.
- Isolate Private Workloads: If a resource doesn't need to be reached from the outside, keep it in a private subnet and use a NAT Gateway or VPC Endpoints instead of an IGW route.
Understanding how to define AWS Internet Gateway is the difference between a secure, functional cloud architecture and a "leaky" one that costs too much and performs poorly. Get your routing right, and the rest of the stack usually falls into place.