AWS Architecture Guide

Internet Gateways, NAT Gateways, and Public Versus Private Paths

Goal

This section explains how AWS network paths become public, outbound-only, or fully private.

The vocabulary can mislead readers here because both internet gateways and NAT gateways sound like "internet connectivity." They are related, but they answer different design questions.

The Short Version

AWS describes an internet gateway as a highly available VPC component that allows communication between your VPC and the internet. AWS describes a NAT gateway as a NAT service that lets instances in a private subnet connect outward while preventing unsolicited inbound connections from external services.

That leads to the architecture mental model:

Public and private are traffic-path outcomes, not just subnet labels.

An internet gateway enables public internet reachability when routing and addressing also allow it. A NAT gateway gives private resources outbound access without making them direct public entry points.

What Makes a Path Public

A workload is not public merely because it lives in a "public subnet" on a diagram. It becomes publicly reachable when the relevant path exists:

  • the subnet route table points internet-routable traffic toward an internet gateway

  • the resource has the needed public addressing characteristics

  • security rules allow the traffic

In other words, public reachability is created by a combination of route, address, and policy.

That is useful because it keeps us from thinking in shortcuts. If a workload should never accept direct internet traffic, the design should make that impossible through path choices, not just team intention.

What a NAT Gateway Does

A public NAT gateway is for outbound access from private subnets. AWS notes that instances in private subnets can connect to the internet through a public NAT gateway, but cannot receive unsolicited inbound connections from the internet through it.

That distinction matters a lot. A NAT gateway is not a second type of public entry point. It is a way to let private resources initiate connections out when they need updates, external APIs, or other approved destinations.

AWS also supports private NAT gateways for connectivity to other VPCs or on-premises networks without using public internet paths. The broader lesson is that NAT is about source translation for outbound-style flows, not about accepting public inbound traffic.

A Practical Path Model

Internet
  -> Internet gateway -> Public entry subnet
Private app subnet -> NAT gateway -> Internet gateway -> Internet
Private data subnet -> Local or private paths only

This design says:

  • the public entry tier exists because something must receive legitimate external traffic

  • the application tier may need controlled outbound internet access but should not be directly reachable from the internet

  • the data tier should stay on internal paths only

That is far more useful than simply saying "one public subnet and two private subnets."

When to Avoid Broad Egress

Many early AWS environments send nearly every private subnet through NAT because it is quick. Sometimes that is fine. Often it is lazy design.

A better question is:

Which workloads truly need internet egress, and which should use private service paths or no external path at all?

That question becomes even more important in regulated, enterprise, or platform-heavy environments where teams want clearer control over outbound dependencies.

Example: Application Tier Versus Database Tier

Imagine an application service that must call a third-party payment API and download package updates during maintenance windows. That service may justify controlled outbound access.

Now imagine the database tier. It usually does not need direct internet access at all. Giving it the same egress path just because it lives in the same VPC is a weak design habit.

This is why good network diagrams tell a traffic story. The story should say who can enter, who can go out, and who never needs either kind of public path.

Common Mistakes

  • Assuming a NAT gateway makes a subnet public.

  • Giving every private workload a default outbound path without asking whether it is needed.

  • Putting sensitive internal systems on paths that are broader than their actual job requires.

  • Explaining public and private only through subnet names instead of route behavior.

If Someone Asks You

What is the architectural difference between an internet gateway and a NAT gateway?

A good answer is:

An internet gateway supports direct communication between a VPC and the internet when routing and addressing allow it. A NAT gateway is mainly for outbound connectivity from private resources, so those resources can initiate connections out without becoming directly reachable for unsolicited inbound traffic.

What You Should Remember

Public and private are traffic-path outcomes. The key design question is which workloads need inbound, outbound, or no internet path at all.

Questions to Check Your Understanding

  1. Why does a NAT gateway not make a private workload a public entry point?

  2. What combination of decisions makes a resource publicly reachable?

  3. Which kinds of workloads should usually have no internet route at all?