What is an internet gateway vs a NAT gateway in AWS

An internet gateway and a NAT gateway both connect your AWS Virtual Private Cloud (VPC — your own private slice of the AWS network, walled off from every other customer's) to the internet, but they do opposite jobs: an internet gateway lets instances with a public IP talk to the internet in both directions, while a NAT gateway lets instances that have no public IP reach out to the internet without ever being reachable from it. Here's the part almost nobody mentions: the internet gateway is quietly doing network address translation too — the exact job the "NAT Gateway" product is named after — every single time a public instance sends a packet out.

Jake found this out the expensive way. He'd set up a little inventory-tracking app for his phone shop — a small web server plus a database — and figured "internet gateway" and "NAT gateway" were just two names for the same on-ramp to the internet. He attached an internet gateway, called it done, and three weeks later his customer database showed up in a security scan tool as reachable from anywhere in the world. Nobody had broken in. He'd simply never separated "things the internet should see" from "things the internet should never see," and AWS had happily built exactly what he asked for.

The one-sentence difference (and the one everyone gets wrong)

An internet gateway is a two-way door. A NAT gateway is a one-way door with a peephole. That's the whole concept, and almost every confusing detail in AWS networking documentation is just an elaboration of that one sentence.

According to Amazon's own VPC documentation, an internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet, supporting both IPv4 and IPv6. It enables resources in your public subnets — EC2 instances, load balancers, anything with a public IPv4 address or an IPv6 address — to connect out to the internet, and it lets resources on the internet connect in to reach them. It never causes bandwidth constraints and there's no charge for the gateway itself; you only pay the ordinary EC2 data transfer charges for the traffic that flows through it.

A NAT gateway does something narrower on purpose. It lets instances in a private subnet — a subnet whose route table has no path to an internet gateway — start outbound connections to the internet or to other AWS services, while blocking every unsolicited inbound connection. The private instance never gets a public IP of its own. Instead, the NAT gateway translates its private address to the NAT gateway's own public address (or Elastic IP) on the way out, and translates the return traffic back on the way in — but only for connections the private instance actually started.

What an internet gateway actually does under the hood

An internet gateway (IGW) is attached to exactly one VPC at a time, and by itself it does nothing until your route tables point at it. If a subnet's route table has a route sending internet-bound traffic (0.0.0.0/0 for IPv4, ::/0 for IPv6) to the internet gateway, AWS calls that a public subnet. If a subnet's route table has no such route, it's a private subnet — even if every instance in it happens to have a public IP address, which is a trap we'll come back to.

Here's the detail that trips people up, and it's the counterintuitive reveal from the top of this post: for IPv4 traffic, the internet gateway itself performs network address translation. Your EC2 instance only ever knows its own private, internal IP address — something like 10.0.1.25. It has no idea it also has a public IPv4 address or an Elastic IP. When it sends a packet toward the internet, the internet gateway rewrites the source address to the instance's public or Elastic IP before the packet leaves the VPC, and rewrites the destination address back to the private IP on the way in. That's one-to-one NAT, done invisibly, on every packet, for every public instance — which means the word "NAT" in "NAT Gateway" describes a technique both products use, not a feature unique to one of them.

IPv6 works differently through an internet gateway, and it's worth explaining why. IPv6 addresses are globally unique by design — there's no such thing as a "private" IPv6 address the way 10.0.0.0/8 or 192.168.0.0/16 are private in IPv4. So an instance with an IPv6 address is public by default the moment it has any route to the internet; there's no address translation step needed, because the address the instance already has is the address the internet sees.

One more thing an internet gateway does that most explanations skip: it's the reason your default VPC "just works" the first time you launch an instance. Every AWS account's default VPC in every Region already comes with an internet gateway attached and a route table wired to it, plus automatic public IPv4 assignment for instances launched into the default subnet. A VPC you create yourself from scratch gets none of that — no internet gateway, no route to one, and no automatic public IPs. That's not a bug; it's AWS defaulting a hand-built VPC to "nothing can reach this from outside" until you deliberately open it up.

What a NAT gateway actually does under the hood

A NAT gateway is a managed network interface that AWS creates inside a subnet you choose, and gives a private IP address from that subnet's range. If you're creating a standard ("public") NAT gateway, you place it in a public subnet and associate an Elastic IP with it — that Elastic IP is the address the outside world will see for every private instance behind it. Then, in the route table of the private subnet you actually want to give internet access to, you add a route sending 0.0.0.0/0 to the NAT gateway's ID.

Ethan puts it to Jake this way: "Think of the NAT gateway as your shop's return-and-repair counter. A customer can hand something to the counter and the counter passes it along and brings the answer back. But nobody off the street can walk up to that counter and demand to see what's in the back room. The NAT gateway will only carry a conversation that started on the inside."

Technically, that "only carry conversations that started inside" behavior is what makes a NAT gateway stateful: it tracks which private instance opened which connection to which destination, so return traffic gets routed back to the correct instance, and traffic that wasn't invited never gets forwarded at all. A NAT gateway supports three protocols — TCP, UDP, and ICMP — and nothing else; if your workload genuinely needs a different protocol outbound, a NAT gateway won't carry it.

Public subnets, private subnets, and why the route table decides everything

Here's the fact that would have saved Jake his security scare: "public subnet" is not about whether instances have public IP addresses. It's purely about whether the route table has a route to an internet gateway. AWS's own documentation is explicit about this — an instance in a private subnet can't communicate with the internet even if it has a public IP address, because there's no route to the internet gateway carrying it there.

Here's what a genuinely stuck reader would ask next: does a subnet's route table need a route and an internet gateway attached to the VPC, or is one enough? Both. An unattached internet gateway routes nowhere; a route to an internet gateway that was never attached to the VPC won't even validate when you try to save it. AWS enforces the pairing at the API level — you attach the gateway to the VPC first, then the route table lets you reference it.

The default VPC vs. a VPC you build yourself

AWS's documentation lays out exactly what a default VPC gives you automatically that a custom VPC does not:

How to tell which gateway your subnet actually has

Before you build anything, check what's already there. This takes two minutes in the console:

1. Open the VPC console and go to Subnets. Click the subnet you care about, then open the Route table tab.
2. Look at the destination rows. If you see 0.0.0.0/0 pointing to a target ID that starts with igw-, that's a public subnet. If instead it points to a target starting with nat-, that's a private subnet with outbound-only internet access. If there's no 0.0.0.0/0 row at all pointing to either, the subnet has no internet path whatsoever.
3. Cross-check against the instances themselves: go to EC2 → Instances and look at the "Public IPv4 address" column. An instance can show a public IP and still sit in a private-routed subnet — remember, the route table is what actually decides reachability, not the presence of the address.
4. If you want to be certain rather than infer it, use VPC Reachability Analyzer from the VPC console — it will trace the actual path a packet would take from a source to a destination and tell you exactly which gateway, if any, it passes through.

Setting up an internet gateway from scratch

If you're building a custom VPC and you genuinely need a subnet the internet can reach — a public web server, a bastion host, a load balancer — here's the sequence:

1. Create the internet gateway. In the VPC console, go to Internet gateways → Create internet gateway. The only thing you can configure at creation is a name tag — there are no other settings, because an internet gateway is fully managed and has no operational knobs.
2. Attach it to your VPC. Select the new gateway, choose Actions → Attach to VPC, and pick the VPC. A VPC can only have one internet gateway attached at a time, and a given internet gateway can only be attached to one VPC.
3. Add the route. Go to the route table associated with the subnet you want to make public, and add a route: destination 0.0.0.0/0, target the internet gateway you just attached. For IPv6, add a second route with destination ::/0 pointing to the same gateway.
4. Make sure instances have a public address. An internet gateway route alone isn't enough — the instance also needs a public IPv4 address (auto-assign it at launch, or attach an Elastic IP afterward) or an IPv6 address from the subnet's range.
5. Open the right ports in the security group. The route gets traffic to the instance's front door; the security group decides whether that door is unlocked. HTTP/HTTPS for a web server, SSH or RDP scoped to your own IP for administration — never 0.0.0.0/0 on an admin port.

Setting up a NAT gateway for a private subnet

1. Confirm you have a public subnet already. A public NAT gateway must live in a public subnet — one with a working route to an internet gateway — because the NAT gateway itself needs internet access to forward the traffic it's carrying.
2. Allocate an Elastic IP (a static public IPv4 address you control) if you don't already have a spare one. This is the address the entire internet will see for every private instance behind this NAT gateway.
3. Create the NAT gateway. In the VPC console, go to NAT gateways → Create NAT gateway, choose the public subnet, choose "Public" as the connectivity type, and attach the Elastic IP from the previous step.
4. Wait for it to become "Available." Unlike an internet gateway, a NAT gateway takes a few minutes to provision — it's a managed instance under the hood, not a pure routing construct.
5. Update the private subnet's route table. Add a route: destination 0.0.0.0/0, target the new NAT gateway's ID (nat-…). Do this on the route table of the private subnet, not the public one the NAT gateway sits in.

NAT gateway vs. NAT instance vs. private NAT gateway

"NAT gateway" quietly covers three different things depending on the connectivity type you pick, and mixing them up causes real architecture mistakes.

The private NAT gateway is the one people forget exists, and it solves a real, costed problem: preserving private IPv4 addresses when two VPCs with overlapping IP ranges need to talk to each other, or running large workloads behind a small pool of allowlisted addresses that a partner has approved on their firewall. It's a NAT gateway that never sees the internet at all.

The newer option: regional NAT gateways

Everything above describes the classic, "zonal" NAT gateway that's lived in one Availability Zone since the product launched. In November 2025, AWS added a regional mode: a single NAT gateway that automatically expands and contracts across Availability Zones based on where your workloads actually are, with one ID referenced in your route tables instead of a separate gateway, subnet, and route table per AZ. You don't even need a public subnet to host it.

Regional mode has two configurations. In automatic mode, AWS manages IP allocation and expands the gateway to a new AZ on its own when it detects a network interface there. In manual mode, you control IP addressing and are responsible for expanding and contracting coverage yourself. Regional NAT gateways bill per AZ per hour at the same $0.045 rate as zonal ones — a gateway spanning three AZs for an hour bills three NAT-Gateway-hours — and the charge adjusts automatically if the gateway drops support for an AZ.

IPv6: why you don't need a NAT gateway at all

This confuses people coming from IPv4-only backgrounds: because IPv6 addresses are globally unique and public by default, there's no such thing as translating a "private" IPv6 address into a "public" one — the concept doesn't exist. So AWS built a separate, dedicated component for the equivalent job: the egress-only internet gateway.

An egress-only internet gateway is, in AWS's own words, a horizontally scaled, redundant, highly available VPC component that allows outbound-only communication over IPv6 from your instances to the internet, while preventing the internet from initiating an IPv6 connection with them. It's stateful — it forwards outbound traffic and routes the responses back — but it's IPv6-only. There's no charge for it, same as a regular internet gateway, though standard EC2 data transfer charges still apply.

If your VPC handles dual-stack traffic (both IPv4 and IPv6), you'll typically end up running three gateways side by side: an internet gateway for public IPv4/IPv6 subnets, a NAT gateway for private IPv4 outbound access, and an egress-only internet gateway for private IPv6 outbound access. None of the three substitutes for another.

There's also a middle path worth knowing about: a NAT gateway can perform NAT64, translating IPv6 traffic to IPv4 destinations. Combined with DNS64 on Route 53 Resolver, this lets IPv6-only workloads reach IPv4-only services — inside the same VPC, in a different VPC, on-premises, or on the internet — without you having to dual-stack every resource.

Edge case: VPCs, subnets, and cross-connections

Two routing rules catch people building anything beyond a single flat VPC. First, you cannot route traffic to a NAT gateway across a VPC peering connection — a NAT gateway will not accept traffic that originated on the other side of a peering link as its "outbound" source. However, traffic that a NAT gateway itself sends out over peering does support "return to sender": replies route straight back to the originating NAT gateway automatically, even without explicit return routes configured in the destination VPC — so if you don't want that, block the return traffic with a network ACL. Second, you cannot route traffic to a NAT gateway from AWS Site-to-Site VPN or Direct Connect through a virtual private gateway; if you need that path, route it through a transit gateway instead.

What this actually costs Jake's shop

Once Jake fixed his security exposure by moving his database into a private subnet, his very next question to Ethan was blunt: "So what's this going to cost me now?"

The internet gateway itself is free — AWS charges $0 for creating or attaching one, whether you send one packet through it or a petabyte. You only pay the standard EC2 data transfer rates for what actually flows.

The NAT gateway is not free, ever, from the moment it's created — even at zero traffic. Per AWS's own pricing page, you're charged for every "NAT Gateway-hour" the gateway is provisioned and available, at a rate of $0.045 per hour in US East (Ohio) — around $32.40 a month just for it to exist — plus $0.045 per gigabyte of data processed, regardless of that data's source or destination. Each partial hour bills as a full hour. On top of that, ordinary EC2 data transfer charges still apply for traffic that leaves AWS entirely.

Here's AWS's own worked example: an EC2 instance behind a NAT gateway sends a 1 GB file to an S3 bucket in the same Region and Availability Zone. That's $0.045 for the hourly charge, plus $0.045 for the 1 GB of data processing, plus $0 in data transfer because EC2-to-S3 in the same Region carries no transfer fee — $0.09 total. Send that same 1 GB to a destination outside AWS instead, and the standard internet data transfer charge stacks on top of the $0.045 processing fee.

Jake's honest, slightly embarrassed follow-up question was: "If I have three Availability Zones, do I really need three of these things?" Ethan's answer, in his own words: "You need three if you actually care about staying up when one zone has a bad day. If a single NAT gateway serves resources in multiple AZs and that NAT gateway's AZ goes down, everything routed through it loses internet access — including the AZs that were otherwise fine. One NAT gateway is a cost-saving shortcut with a real availability cost attached to it, and you should only take that shortcut on purpose, not by accident."

Here's what that shortcut actually costs in real numbers, using the same $0.045/hour and $0.045/GB US East (Ohio) rates from AWS's pricing page. Three NAT gateways, one per AZ, running the full month (730 hours), cost 3 × 730 × $0.045 = $98.55 in hourly charges alone before a single byte moves. Add a workload that pushes 600 GB a month through those gateways combined — a mix of software updates, API calls, and log shipping — and the data processing charge adds 600 × $0.045 = $27. If a third of that traffic (200 GB) actually leaves AWS for the public internet rather than staying inside AWS services, the standard EC2 data transfer rate stacks on top of the processing charge, not instead of it. Compare that to a single shared NAT gateway: the hourly charge drops to one-third, around $32.85 a month, but Ethan's warning about losing an entire AZ's internet access during an outage is the trade you're making for that savings. Jake's shop runs one modest web app, not a payments platform, so he and Ethan settled on a single NAT gateway for now — a decision Ethan was explicit about revisiting the day the shop's inventory system starts handling anything customers would notice going dark.

Common mistakes and what they look like when they happen

Every one of these is a real, repeatable failure pattern, and each one has a specific fingerprint you can recognize before you go digging.

"My instance has a public IP but can't reach the internet"

Fingerprint: outbound connections time out, but the instance shows a public IPv4 address in the console. Cause: the subnet's route table has no route to an internet gateway, so the address exists but nothing routes to it. This is the trap described earlier — public IP does not equal public subnet. Fix: check the route table (see the diagnostic steps above) and add the 0.0.0.0/0 route to the internet gateway if it's missing.

"My private instances suddenly can't reach the internet at all"

Fingerprint: outbound connections fail from every instance in a private subnet, all at once. Common causes, cheapest fix first: the NAT gateway's Elastic IP was released or disassociated; the NAT gateway was deleted (check for a stopped instance-launch pipeline that deletes and recreates infrastructure); the NAT gateway itself is in a "Failed" state, visible in the VPC console under NAT gateways; or the route in the private subnet's route table pointing at the NAT gateway was removed or edited to point somewhere else. NAT gateways don't silently degrade — they're either "Available" or they're not, so checking status in the console is the fastest triage step.

"Traffic from a peered VPC through my NAT gateway isn't working"

Fingerprint: instances in VPC A can reach the internet fine, but instances in peered VPC B trying to route through VPC A's NAT gateway can't. Cause: NAT gateways will not accept traffic arriving over a VPC peering connection as something to translate onward to the internet — that path (client → peering → NAT → internet) is explicitly unsupported. The only supported direction is client → NAT → peering → destination. Fix: give VPC B its own NAT gateway rather than trying to share VPC A's.

"NAT gateway costs spiked with no obvious cause"

Fingerprint: the hourly charge stayed flat but the data processing line item grew. Cause: growing volumes of AWS-service traffic (S3 downloads, container image pulls, API calls to other AWS services) routed through the NAT gateway instead of a free VPC endpoint. Fix: check Cost and Usage Reports broken out by the NAT gateway's resource ID, identify the destination services generating the most GB, and add Gateway or Interface VPC endpoints for the busiest ones.

"DNS lookups are slow or fail for private instances, but hardcoded IPs work fine"

Fingerprint: connecting straight to an IP address works instantly, but the same connection by hostname is slow or times out — and it only shows up in private subnets, never in public ones. Cause: someone configured the instance's resolver settings to point at a public DNS service like 8.8.8.8 instead of the VPC's own resolver. Amazon's own documentation places the built-in DNS resolver (the "Amazon DNS server," also called the Route 53 Resolver) at a fixed, predictable address: the base of the VPC's primary IPv4 CIDR block plus two — so a 10.0.0.0/16 VPC always resolves through 10.0.0.2, alongside the link-local address 169.254.169.253 that works the same way in every VPC. Queries to that built-in resolver travel privately inside the AWS network and never touch the NAT gateway or the internet at all. Point the resolver at anything else, and every DNS lookup becomes ordinary outbound traffic — subject to the NAT gateway's routing, its per-GB data processing charge, and normal internet latency. Fix: leave the DHCP option set on "AmazonProvidedDNS" unless you have a specific reason (like a private hosted zone with a different upstream) not to.

"The NAT gateway shows 'Available' but nothing routes through it for the first few minutes"

Fingerprint: you just created the NAT gateway, updated the route table immediately, and the very first connection attempts fail before quietly starting to work a short while later. Cause: a NAT gateway isn't a pure routing construct the way an internet gateway is — it's a managed resource that has to finish provisioning its underlying network interface before it can actually forward packets, even after the console marks it "Available." Route table changes themselves propagate almost immediately, so the gap you're seeing is the gateway itself still warming up, not a route problem. Fix: nothing to fix — just don't treat the first minute or two after creation as a real failure, and if problems persist past that, move on to checking the route table and Elastic IP association instead.

Limits and quotas you will eventually hit

These are documented AWS defaults, not guesses, and most are adjustable through a Service Quotas request if you actually need more:

The 55,000-connections-per-destination limit is the one that quietly breaks high-traffic applications. It's per source IPv4 address, per unique destination IP and port — so a fleet of instances behind a single NAT gateway all hammering the same external API endpoint can exhaust it even while overall bandwidth looks fine. AWS's documented fix is architectural: add more NAT gateway IP addresses, or split resources across additional subnets and NAT gateways, so the connection count is spread across more source addresses.

Worth flagging while we're on numbers: a NAT gateway supports traffic up to an 8500-byte maximum transmission unit (MTU — the largest single packet size a connection will carry). But AWS's own guidance is to keep your EC2 instances' MTU at 1500 bytes or lower when communicating over the internet through a public NAT gateway, specifically to avoid packet loss on the public internet side of that connection, even though the NAT gateway itself could technically carry larger packets on the private side.

Frequently asked questions

Can a VPC have both an internet gateway and a NAT gateway at the same time?

Yes, and this is the normal setup for any real application. The internet gateway serves your public subnet (web servers, load balancers), and the NAT gateway — which must sit inside that same public subnet — gives your private subnet (databases, backend workers) outbound-only access. They work together rather than as alternatives to each other; the NAT gateway can't function without an internet gateway already attached to the VPC.

Do I need a NAT gateway if all my instances have public IPs?

Not for outbound access — an internet gateway alone handles two-way traffic for instances with public IPs. You'd add a NAT gateway if you want some instances to reach the internet outbound while remaining completely unreachable from it, which requires taking their public IPs away and moving them to a private subnet in the first place. Having public IPs and wanting inbound protection are contradictory goals; a security group restricts ports, but it doesn't hide the instance's existence the way removing the public IP does.

What happens if I delete my internet gateway by accident?

Every route in every route table that pointed to it stops working immediately — public subnets lose both inbound and outbound internet access, and any NAT gateway that depended on that internet gateway for its own outbound path loses connectivity too, since a NAT gateway's public subnet needs a working internet gateway route to function. You can't delete an internet gateway while it's still attached to a VPC, which is a small safety net, but detaching-then-deleting is still fully possible if you're not paying attention.

Can a private subnet reach the internet without any gateway at all?

No. Without a route to an internet gateway, a NAT gateway, or a NAT instance, a subnet's internet-bound traffic has nowhere to go and simply fails — connections time out rather than being actively refused. The only exceptions are traffic to AWS services reachable via a VPC endpoint, which never needs to leave the AWS network at all.

Why does my NAT gateway cost money even though no traffic is flowing?

Because the hourly charge is for the gateway existing and being available, not for traffic passing through it. AWS's pricing page states the hourly charge always applies once the NAT gateway is provisioned, separate from the per-gigabyte data processing charge. If you're not using it, the only way to stop the hourly charge is to delete the NAT gateway.

Can I use one NAT gateway for multiple Availability Zones?

With a zonal (classic) NAT gateway, yes, but AWS explicitly warns against it for production: if resources in multiple AZs share one zonal NAT gateway and that gateway's AZ goes down, every AZ routed through it loses internet access, even the ones that were otherwise healthy. Either deploy one NAT gateway per AZ, or use the newer regional NAT gateway mode, which is built to span AZs by design.

Does a NAT gateway work with IPv6?

Yes, but not in the way you'd expect from IPv4. A NAT gateway handles IPv6 traffic by performing NAT64 — translating it to reach IPv4 destinations, typically paired with DNS64 on Route 53 Resolver. For straightforward outbound-only IPv6-to-IPv6 traffic, the dedicated tool is the egress-only internet gateway instead.

What is the difference between a NAT gateway and a NAT instance?

A NAT gateway is a fully managed AWS service — no patching, automatic redundancy within its AZ, bandwidth that scales to 100 Gbps automatically. A NAT instance is a regular EC2 instance you configure yourself to perform the same job, with bandwidth capped by whatever instance type you chose, and failover you have to script and manage. AWS recommends NAT gateways over NAT instances for exactly this reason: better availability, better bandwidth, less administration.

Can instances behind a NAT gateway receive inbound connections at all?

Only as replies to a connection they themselves started. A NAT gateway is stateful and tracks exactly that — it will let return traffic from a destination the private instance already contacted flow back in, but it will refuse any connection attempt that didn't originate on the private side. There's no way to configure a NAT gateway to accept unsolicited inbound connections; that's a fundamentally different job, which is what an internet gateway (plus a public IP) is for.

Why can't I attach an Elastic IP directly instead of using an internet gateway?

You can attach an Elastic IP to an instance in a private subnet, but without a route to an internet gateway, that address still routes nowhere — an Elastic IP is just an address, not a path. The internet gateway is what actually connects your VPC's route tables to the outside internet; the Elastic IP is what the outside internet uses to find a specific instance once that path exists.

Does a NAT gateway protect me from all inbound internet traffic, like a firewall?

It blocks unsolicited inbound connections from initiating through it — that's a real, meaningful protection — but it isn't a firewall in the broader sense. It doesn't inspect packet contents, doesn't filter based on rules you write, and doesn't protect against threats that arrive through a connection the private instance itself opened (for example, malware phoning home, or a compromised outbound API call). For that kind of inspection, you'd add something like AWS Network Firewall alongside the NAT gateway, not instead of it.

What is a private NAT gateway and how is it different from a public one?

A private NAT gateway routes traffic between VPCs or to an on-premises network through a transit gateway or virtual private gateway, and it never touches the public internet — you can't even associate an Elastic IP with one. A public NAT gateway does the opposite job: it specifically routes private-subnet traffic out to the internet. If you accidentally route a private NAT gateway's traffic toward an internet gateway, AWS's documentation confirms the internet gateway simply drops it.

How many NAT gateways can I create in one Availability Zone?

Five, by default, and this is an adjustable AWS quota — gateways in the pending, active, or deleting state all count toward it. Most workloads never come close to this ceiling, since one NAT gateway per AZ already covers the common high-availability pattern.

Is the internet gateway a single point of failure for my whole Region?

No — AWS describes the internet gateway as horizontally scaled, redundant, and highly available by design, and states it doesn't introduce availability risks or bandwidth constraints on your traffic. Unlike a zonal NAT gateway, there's no per-AZ failure mode to worry about with an internet gateway itself; it operates at the VPC level rather than being tied to a single Availability Zone.

Can I route traffic to a NAT gateway through VPC peering?

No — a NAT gateway will not accept traffic that arrives over a VPC peering connection as source traffic to translate onward. What is supported is the reverse direction: traffic that originated at the NAT gateway and travels out over peering to a destination VPC, which supports automatic "return to sender" behavior for the reply traffic. If you need peered VPCs to share outbound internet access, each VPC needs its own NAT gateway.

Should I use a regional NAT gateway or the older zonal one for a new VPC?

For a straightforward multi-AZ workload with no need for private NAT, the regional NAT gateway (available since November 2025) genuinely simplifies the architecture — one gateway ID instead of one per AZ, with automatic expansion as your workload spreads across zones. If you need private NAT for VPC-to-VPC or on-premises traffic that never touches the internet, stick with the zonal NAT gateway, since regional mode doesn't support that use case yet.

Revision note. Written September 2026, but This will need a fresh look whenever AWS extends regional NAT gateway support to private NAT, or changes per-GB pricing in your Region — so treat the dollar figures above as a snapshot, not a permanent quote. If you're the one staring at a route table at midnight trying to figure out why a subnet won't talk to the internet, we hope the diagnostic steps above get you there faster than we got there ourselves.