SysPad › Lessons › networking lessons › Internet Gateway
How Internet Gateway works
The VPC front door: lets resources in public subnets reach and be reached from the internet. Horizontally scaled and redundant by design - no bandwidth limit, no availability risk, and no charge. Private subnets egress via NAT Gateway instead.
Every VPC diagram has a little box at the top that costs nothing, has no knobs, and cannot fail, and yet without it the entire network is a sealed room. The Internet Gateway is the least dramatic component in AWS and the one that defines the words "public" and "private" for everything else.
What you will learn
- What actually makes a subnet "public"?
- Why does the IGW have no bandwidth limit, no HA setup, and no price?
- How do IGW and NAT Gateway split the job?
- Why does an instance in a public subnet still need a public IP?
The front door of the VPC
An Internet Gateway attaches to a VPC and does two things: routes traffic between the VPC and the internet, and performs the one-to-one NAT between an instance's private address and its public IP. A subnet whose route table sends 0.0.0.0/0 to the IGW IS a public subnet; that route is the entire definition.
Not a box, so nothing to size
The IGW is horizontally scaled, redundant, and highly available by design: AWS publishes no bandwidth cap for it, you deploy no pairs, configure no failover, and pay nothing. It is routing infrastructure, not an appliance.
⚓ In a SysPad simulation the IGW passes traffic untouched: no cost, no saturation. Its job on the canvas is to make the VPC story readable, exactly like on the AWS console.
IGW vs NAT Gateway
The IGW is two-way: the internet can initiate connections to public instances. A NAT Gateway is one-way: private-subnet instances can reach OUT (updates, APIs) but nothing can reach in, and it charges per hour and per GB. The standard pattern: load balancer in public subnets, everything else private behind NAT.
If the subnet is public, why does my instance still need a public IP?
The IGW translates between a specific private address and a specific public one. No public address on the instance means nothing to translate to, so no inbound path, even in a public subnet. This is the classic "I made it public, why can't I SSH in" checklist item (along with security groups).
Flashcards
- A teammate says "just move the instance to the public subnet so users can reach it." What THREE things must actually be true for inbound traffic to arrive?
- Subnet route 0.0.0.0/0 → IGW (that is what public means), a public IP on the instance, and a security group allowing the port. Any one missing looks identical from the outside: timeout.
- The capacity-planning sheet has a row for "Internet Gateway throughput." What goes in it?
- Nothing: AWS scales the IGW transparently with no published bandwidth limit and no HA setup on your side. Instance NIC limits and NAT gateways are where egress math actually happens.
- Private-subnet workers need to call a third-party API. Someone proposes adding an IGW route to their subnet. What just happened?
- Their subnet became public (that route is the definition), exposing every instance with a public IP to inbound internet. The right tool for private egress is a NAT Gateway: out only.
Sources
Open the SysPad canvas · Official Internet Gateway documentation