DEV Community

Cover image for AWS NAT Gateway: Giving Private Subnets Safe Internet Access
Rajesh
Rajesh

Posted on

AWS NAT Gateway: Giving Private Subnets Safe Internet Access

#aws #cloud #networking #devops

Why do we need a NAT Gateway?

In the last session, we created a custom VPC with a private subnet to lock down backend databases and application servers. Nobody on the internet could reach them.

Network isolation is great for security, but it creates a real problem:

  • How does your private EC2 server download security updates (apt update or dnf update)?
  • How does it download packages or call external APIs like Stripe, Twilio, or GitHub?

If you attach an Internet Gateway directly to the private subnet, it is no longer private—anyone on the internet can scan your ports.

A NAT Gateway solves this problem. It allows private servers to reach out to the internet, while completely blocking the internet from starting connections back into your private servers.

1. What is NAT (Network Address Translation)?

Think of an office with a receptionist:

  • When an employee wants to call a client, the receptionist dials out using the office main phone number.
  • The client outside only sees the office company number, never the employee's personal desk extension.
  • When the client replies on that same call, the receptionist connects them back to the employee.
  • But if someone outside tries to call an employee directly without an active outbound call, the receptionist blocks the call. 
[ Private Subnet ]                         [ Public Subnet ]                 [ Internet ]
  Private EC2 (10.0.2.15)                   NAT Gateway (Elastic IP)          GitHub / External API
          │                                         │                                │
          │── Outbound: dnf update ────────────────►│── Outbound: Source = NAT EIP ─►│
          │                                         │                                │
          │◄── Inbound Reply ───────────────────────│◄── Inbound Reply ──────────────│
          │                                         │                                │
          │                                         │◄── Outside Inbound Probe ──────│ (Blocked ✗)
Enter fullscreen mode Exit fullscreen mode

How the packets travel:

  1. Your private EC2 (10.0.2.15) wants to download software from the internet.
  2. The private route table sends 0.0.0.0/0 to the NAT Gateway.
  3. The NAT Gateway replaces the private IP (10.0.2.15) with its own Elastic IP. It keeps track of this in its connection table.
  4. The packet goes through the Internet Gateway (IGW) out to the internet.
  5. When the website sends the data back, the NAT Gateway checks its table, swaps the destination IP back to 10.0.2.15, and hands the data to your private server.

Any outside connection coming in that was not started by your private server is immediately dropped.

2. Internet Gateway (IGW) vs. NAT Gateway

Both handle internet traffic, but they do completely different jobs:

What to look at Internet Gateway (IGW) NAT Gateway
Traffic Direction Inbound and Outbound (Two-way) Outbound only + replies come back
Used by Public subnets Private subnets
Needs a Public IP on EC2? Yes No (EC2 only needs a private IP)
IP Translation 1 to 1 (One public IP for one EC2) Many to 1 (Many private EC2s share 1 NAT Elastic IP)
Where do you put it? Attached to the whole VPC Sits inside a Public Subnet
Scaling Automatic Automatic (up to 100 Gbps)
Cost Free Hourly charge + per-GB data fee

3. How the Route Tables Work

For a NAT Gateway to work, you need two route tables set up like this:

Public Subnet Route Table (Where NAT Gateway lives)
Destination     Target
10.0.0.0/16     local
0.0.0.0/0       igw-0abc123  (Internet Gateway)

Private Subnet Route Table
Destination     Target
10.0.0.0/16     local
0.0.0.0/0       nat-0def456  (NAT Gateway)
Enter fullscreen mode Exit fullscreen mode

The #1 Mistake: You must create your NAT Gateway inside a Public Subnet. If you place it inside a private subnet, the NAT Gateway cannot reach the Internet Gateway, and nothing will connect.

4. NAT Gateway vs. NAT Instance

Before AWS had managed NAT Gateways, engineers launched a small EC2 instance running Linux to do the job:

  • AWS NAT Gateway (Managed): Works out of the box, auto-scales up to 100 Gbps, and AWS handles all patching and hardware redundancy inside the AZ.
  • NAT Instance (EC2 you manage): Cheaper for quick student tests, but you have to disable Source/Destination Check, configure the Linux firewall yourself, and if that single EC2 instance stops or crashes, your whole private subnet loses internet access.

What is a Private NAT Gateway?

When creating a NAT Gateway in the AWS console, you will see two options:

  • Public: Has an Elastic IP. Used to give private subnets internet access.
  • Private: Has no Elastic IP. It is used when connecting two private networks (like on-premises to AWS via Transit Gateway) that have overlapping IP addresses. It cannot reach the internet.

5. High Availability (HA) & Saving Money

A NAT Gateway is redundant inside one Availability Zone (AZ), but it does not protect you across multiple AZs.

Multi-AZ Setup (Production)

If you run workloads in both AZ-a and AZ-b:

  • Put one NAT Gateway in AZ-a (public subnet).
  • Put one NAT Gateway in AZ-b (public subnet).
  • Point private subnets in AZ-a to NAT Gateway A, and private subnets in AZ-b to NAT Gateway B.
  • This prevents an outage in one AZ from cutting off your entire backend, and avoids cross-AZ data transfer fees. 
      Availability Zone A                       Availability Zone B
┌─────────────────────────────────┐       ┌─────────────────────────────────┐
│ [Public Subnet A]               │       │ [Public Subnet B]               │
│  NAT Gateway A (EIP A)          │       │  NAT Gateway B (EIP B)          │
│       ▲                         │       │       ▲                         │
│ [Private Subnet A]              │       │ [Private Subnet B]              │
│  App EC2 (Routes to NAT A)      │       │  App EC2 (Routes to NAT B)      │
└─────────────────────────────────┘       └─────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

How to avoid surprise bills:

NAT Gateways charge an hourly uptime fee plus a per-GB fee for all data passing through them:

  1. Use free VPC Gateway Endpoints for S3 & DynamoDB: S3 Gateway Endpoints are 100% free. If your private servers pull gigabytes of files or backups from S3 through a NAT Gateway, you pay data processing on every gigabyte. Adding a Gateway Endpoint routes that traffic directly to S3 within AWS at zero cost.
  2. Delete it when done with labs: Always delete your NAT Gateway and release the Elastic IP when you finish testing.

Hands-On Practice & Console Walkthrough

Here is the step-by-step walkthrough to set up a NAT Gateway and give your private EC2 instance outbound internet access.

Step 1: Create the NAT Gateway

  1. Go to VPC Console → click NAT Gateways → click Create NAT gateway.
  2. Name tag: lab-nat-gw.
  3. Subnet: Select your public subnet (public-subnet-1a).
  4. Connectivity type: Select Public.
  5. Elastic IP allocation ID: Click Allocate Elastic IP.
  6. Click Create NAT gateway. It takes about 1–2 minutes for the status to turn from Pending to Available.

![NAT Gateway Created in Public Subnet](

Fig 1: NAT Gateway created in public-subnet-1a with an allocated Elastic IP.

Step 2: Route the Private Subnet to the NAT Gateway

  1. Go to Route tables → select your private route table (private-rt).
  2. Open the Routes tab → click Edit routes → Add route:
    • Destination: 0.0.0.0/0
    • Target: Select NAT Gateway → pick lab-nat-gw.
  3. Click Save changes.

![Private Route Table Pointing to NAT Gateway](

Fig 2: Routing all outbound internet traffic (0.0.0.0/0) to the NAT Gateway.

Step 3: Test from the Private Instance

Log into your private EC2 instance (using AWS Systems Manager Session Manager or jumping through your public EC2):

# 1. Check your public IP from the private instance:
curl -s https://checkip.amazonaws.com
Enter fullscreen mode Exit fullscreen mode

Output:

13.234.112.45
Enter fullscreen mode Exit fullscreen mode

It prints the NAT Gateway's Elastic IP, not the EC2 private IP!

# 2. Test downloading packages:
sudo dnf update -y
Enter fullscreen mode Exit fullscreen mode

Packages now download and install with no problem through the NAT Gateway.

Step 4: Verify Outside Inbound Traffic is Blocked

From your local computer terminal, try reaching the private instance through the NAT Gateway's Elastic IP:

curl --max-time 5 http://13.234.112.45
ssh -i key.pem [email protected]
Enter fullscreen mode Exit fullscreen mode

Result:
Both commands time out. Nobody on the internet can connect directly to your private instance through the NAT Gateway.

Step 5: Clean Up (Avoid Surprise Bills!)

NAT Gateways charge money every hour they run. Once you finish:

  1. Go to NAT Gateways → select lab-nat-gw → Actions → Delete NAT gateway.
  2. Go to Route tables → edit your private route table and delete the 0.0.0.0/0 -> nat route.
  3. Go to Elastic IPs → select the allocated Elastic IP → Actions → Release Elastic IP addresses.

Wrap-up

Today's big takeaway was solving the private subnet internet problem:

  • Private subnets stay private, but can still download packages and call external APIs.
  • Always put your NAT Gateway in a public subnet with an Internet Gateway route.
  • For production, run one NAT Gateway per Availability Zone.
  • Use free S3 Gateway Endpoints to save money on data transfer fees.

Top comments (0)