Your VPC is divided into public and private subnets. But how does it actually connect to the internet? This is where two components with similar names but different functions come in: the Internet Gateway and the NAT Gateway. It's common to confuse them, so let's make them crystal clear with analogies.

The Internet Gateway is the component that connects your VPC to the internet. It allows traffic to enter and exit between your network and the outside world. Without it, your VPC is completely isolated from the internet.

Analogy: The Internet Gateway is the main gate of your property that opens onto the public street. Visitors (users accessing your website) come in through it, and your shipments go out. Without that gate, no one from outside can enter and you can't go out.

Key features:

• There is one per VPC (it's a component at the VPC level).
• It is bidirectional: allows inbound and outbound traffic.
• Only public subnets use it (remember: a subnet is public precisely because it has a route to the IGW).
• It is free and highly available (managed by AWS).

Important: having an Internet Gateway does not mean everything in your VPC is exposed. Only resources in public subnets, with a public IP and a route rule to the IGW, are accessible. Security Groups (Chapter 4) still control what specific traffic is allowed.

Here is the component that solves the problem we raised in the previous subchapter: how do you allow private resources to go out to the internet (to download updates, call an external API…) without letting the internet come in to them?

The NAT Gateway (Network Address Translation Gateway) does exactly that: it is a one-way exit door for private subnets.

Analogy: The NAT Gateway is like a back door with a doorman who only lets people out, not in. Your employees (private resources) can go out to run errands (download updates, call external services) and return with what they went to get. But no one from the street can use that door to come in. The initiative always starts from inside.

How it works in practice:

1. A server in the private subnet wants to download an update.
2. Its request goes out through the NAT Gateway (which is in a public subnet).
3. The NAT Gateway uses the Internet Gateway to reach the internet.
4. The response comes back the same way to the private server.
5. But the internet cannot initiate a connection to that private server. It only responds to what the server requested.

Real example: Your database is in a private subnet (well protected). Once a month it needs to download security patches from the internet. Thanks to the NAT Gateway, it can do so securely: it goes out to get the patches, but remains unreachable from outside. The best of both worlds: protected but able to update.

Unlike the Internet Gateway (free), the NAT Gateway costs money: you pay for every hour it is active and for every GB of data that passes through it. In large architectures, it can become a surprise on your bill.

Practical tip: The NAT Gateway is one of the frequent causes of unexpected VPC costs. For high availability you need one per AZ, which multiplies the cost. There are cheaper alternatives for certain cases (like a self-managed "NAT instance", or using VPC endpoints to talk to AWS services without going through NAT, which we’ll see in subchapter 6.5). Keep it on your radar when optimizing costs (Chapter 25).

Putting together everything we've covered in this chapter:

• The Internet Gateway (IGW) is the main bidirectional door between your VPC and the internet. Used by public subnets. It's free.
• The NAT Gateway is a one-way exit: lets private resources go out to the internet (to update, etc.) but prevents the internet from coming in. Placed in a public subnet. Paid.
• The mental rule: IGW = inbound and outbound (public); NAT = outbound only (protected private).
• Watch the cost of the NAT Gateway: per hour + per data, and you need one per AZ for high availability.

In the next subchapter we’ll look at the "traffic rules" that make all this work: Route Tables (which path traffic follows) and Network ACLs (a subnet-level firewall).