AWS Networking: NAT Gateways vs. NAT Instances

Learning Objectives

After studying this guide, you should be able to:

Differentiate between the managed NAT Gateway service and self-managed NAT instances.
Explain the cost implications of choosing a NAT Gateway versus a NAT instance for specific workloads.
Identify the configuration requirements for NAT devices, including route table targets and source/destination checks.
Design a high-availability NAT architecture across multiple Availability Zones.

Key Terms & Glossary

NAT (Network Address Translation): A method of remapping one IP address space into another by modifying network address information in the IP header while in transit.
PAT (Port Address Translation): A type of NAT where multiple devices on a local network can be mapped to a single public IP address using different ports.
EIP (Elastic IP): A static, IPv4 address designed for dynamic cloud computing, required for NAT Gateways.
Source/Destination Check: An EC2 security feature that ensures the instance is either the source or the destination of any traffic it sends or receives. This must be disabled for NAT instances.
NAT64/DNS64: Protocols allowing IPv6-only resources to communicate with IPv4-only resources, supported by NAT Gateways.

The "Big Idea"

In a secure AWS environment, backend servers (like databases) reside in Private Subnets to prevent direct exposure to the internet. However, these servers often need to download updates or patches. A NAT (Network Address Translation) device acts as a controlled bridge: it allows outbound traffic from private resources to the internet while blocking unsolicited inbound connections. Choosing between a NAT Gateway and a NAT Instance is a balance between AWS-managed convenience/scaling and customer-managed cost-control/flexibility.

Formula / Concept Box

Feature	NAT Gateway (Managed)	NAT Instance (Self-Managed)
Management	Managed by AWS (Patching, Scaling)	Managed by Customer (AMI, OS, Security)
Scaling	Highly available & scales to 50 Gbps	Manual; depends on EC2 instance type
Security Groups	Not Supported (Uses NACLs only)	Required (Applied to the ENI)
Public IP	Requires an Elastic IP (EIP)	Requires an Elastic IP or Public IP
Cost Model	Hourly rate + Data Processing per GB	Hourly EC2 rate + Data Transfer fees
Use Case	Production environments, High traffic	Small labs, Port forwarding, Bastion host usage

Hierarchical Outline

I. NAT Gateway (The Modern Standard)
- A. High Availability: Operates within a single AZ but is redundantly designed by AWS.
- B. Configuration: Must be placed in a Public Subnet with a route to an IGW.
- C. Scaling: Starts at 5 Gbps and scales automatically up to 50 Gbps.
II. NAT Instance (The Legacy/Flexible Option)
- A. Definition: A standard EC2 instance running a NAT-optimized Linux AMI.
- B. Source/Destination Check: Must be disabled to allow the instance to forward traffic for others.
- C. Flexibility: Supports Port Forwarding and can double as a Bastion Host.
III. Cost Optimization Strategies
- A. Data Processing: NAT Gateways charge per GB processed; high-volume data transfers can become very expensive.
- B. Multi-AZ Design: To save costs, one might share a NAT Gateway, but this incurs inter-AZ data transfer charges and risks a single point of failure.

Visual Anchors

Traffic Flow Architecture

Loading Diagram...

Comparing Scaling & Management

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Definition-Example Pairs

NAT Gateway Architecture: Designing one NAT Gateway per Availability Zone (AZ).
- Real-world Example: A banking application with three subnets across three AZs deploys three NAT Gateways. This ensures that if AZ-A goes down, the instances in AZ-B and AZ-C still have internet access via their respective local NAT Gateways.
NAT Instance Customization: Using a NAT device for specific network protocols not supported by managed services.
- Real-world Example: A developer needs to perform Port Forwarding to reach a specific legacy application inside a private subnet. Since NAT Gateways do not support port forwarding, they deploy a small t3.micro NAT Instance with a custom iptables configuration.

Worked Examples

Problem: Route Table Configuration

You have a VPC with a Public Subnet (CIDR 10.0.1.0/24) and a Private Subnet (CIDR 10.0.2.0/24). You have created a NAT Gateway in the Public Subnet with ID nat-0123456. How do you configure the route tables?

Step-by-Step Breakdown:

Public Route Table: Ensure the route table associated with the Public Subnet has a default route (0.0.0.0/0) pointing to the Internet Gateway (e.g., igw-abc123). This allows the NAT Gateway to reach the internet.
Private Route Table: Locate the route table associated with the Private Subnet.
Create Route: Add a new route with Destination 0.0.0.0/0 and Target nat-0123456.
Verification: An instance in the Private Subnet can now ping a public DNS (like 8.8.8.8) because its traffic is routed to the NAT Gateway, which performs the translation and forwards it to the IGW.

Checkpoint Questions

What is the maximum bandwidth supported by a single AWS NAT Gateway?
Why must "Source/Destination Check" be disabled on a NAT Instance but not a NAT Gateway?
If you have instances in two different Availability Zones using a single NAT Gateway in AZ-1, what happens if AZ-1 experiences an outage?
Which device allows for the use of Security Groups to control traffic: NAT Gateway or NAT Instance?

[!TIP] Exam Tip: If a question asks for a "highly available, managed solution" for NAT, the answer is always NAT Gateway. If it asks for "cost-effective for small traffic" or "port forwarding," consider NAT Instance.

[!WARNING] Remember that NAT Gateways are charged per hour even if no traffic is sent. For a small hobby project, a NAT Instance on a t3.nano might be significantly cheaper than the ~$32/month base cost of a NAT Gateway.