In an AWS VPC, an instance in a private subnet can download OS package updates from the internet, yet nothing on the internet can open a connection to it. What does the internet gateway do, what does the NAT gateway add, and which of them makes that asymmetry possible?

## Two devices, two jobs A VPC has no internet connectivity of any kind until you create an **internet gateway** and attach it to the VPC. The internet gateway (IGW) is a VPC-level object — one per VPC, not one per subnet and not one per Availability Zone. AWS runs it as a horizontally scaled, redundant component, so it is not a box you size, patch, or worry about failing over; there is no bandwidth knob and no instance behind it. The IGW does two things. It provides the target that a route table can point `0.0.0.0/0` at, and it performs **one-to-one network address translation** between an instance's private address and the public IPv4 address associated with it — either an auto-assigned public IPv4 address or an Elastic IP. That translation is why the instance's own operating system never sees its public address: as far as the guest is concerned it only ever has the private VPC address, and the IGW rewrites the header on the way out and back. Crucially, an IGW is **symmetric**. If a subnet routes to it and an instance in that subnet has a public IPv4 address, that instance can reach the internet *and* the internet can reach it (subject to the instance's own firewalling). There is nothing directional about it. ## Where NAT comes in Most workloads should not have a public address at all. Application servers, batch workers, and databases still need to call *out* — package repositories, license servers, third-party APIs, AWS public service endpoints. That outbound-only requirement is what a **NAT gateway** exists for. A NAT gateway is a managed, zonal appliance that you create **in a public subnet** and give an Elastic IP. Private subnets then send their default route to it. When an instance in a private subnet opens a connection, the NAT gateway rewrites the packet's source address (and source port) to its own, records the mapping, and forwards the packet on toward the internet gateway. The reply comes back addressed to the NAT gateway's Elastic IP, is matched against the recorded mapping, and is rewritten back toward the originating instance. The security property falls straight out of that design: **the mapping only exists because an inside host created it**. An unsolicited packet arriving from the internet at the NAT gateway's address matches no entry and is dropped. This is a byproduct of address translation, not a firewall — the NAT gateway does not inspect, filter, or let you write rules, and you cannot attach a security group to it. ## Why the NAT gateway lives in a *public* subnet This is the detail candidates most often get wrong. The NAT gateway is not magic — its own translated traffic still has to reach the internet, and the only way out of a VPC is the internet gateway. So the subnet holding the NAT gateway must be one whose route table sends `0.0.0.0/0` to the IGW. Placing a NAT gateway in the same private subnet whose default route points at that gateway produces a routing loop and no egress at all. A useful mental picture of the full path for an outbound request from a private instance: ``` private instance (10.0.11.20) -> private subnet route table: 0.0.0.0/0 -> nat-0abc... -> NAT gateway in public subnet (source rewritten to its Elastic IP) -> public subnet route table: 0.0.0.0/0 -> igw-0def... -> internet ``` The reply retraces it in reverse, and each hop reverses its own translation. ## The variants worth knowing There is also a **private NAT gateway** (`--connectivity-type private`), which has no Elastic IP and no internet path at all. It exists to translate addresses for traffic heading to other VPCs or on-premises networks — typically when CIDR ranges overlap and you need traffic to arrive from a single known address. Same translation mechanism, different destination. For IPv6 the answer is different again, because IPv6 addresses in a VPC are globally routable and there is no address scarcity to solve. The outbound-only device there is an **egress-only internet gateway**, which provides the same "outbound plus replies, nothing inbound" behaviour without any address translation for conservation purposes. ## What an interviewer is testing They want to hear that you know the IGW is a VPC-wide, always-on, symmetric door; that the NAT gateway is a subnet-placed, zonal, stateful, outbound-only translator; that the second depends on the first; and that neither is a security control. The follow-up is almost always about NAT gateway placement per Availability Zone and what it costs — because that is where the design and the bill actually get decided.