NAT Gateway and Private Subnets

Resources in private subnets have only private IP addresses and no route to an Internet Gateway, so they cannot initiate outbound connections to the internet. But they often need to reach the internet: to download OS patches, pull Docker images, call third-party APIs, or update software. The solution is to route private subnet traffic through a device that has internet access and performs NAT (Network Address Translation), hiding the private IPs behind a public IP. AWS provides two options: NAT Gateway (managed) and a self-managed NAT Instance (legacy).

A NAT Gateway is a fully managed, highly available service that enables instances in private subnets to initiate outbound connections to the internet while blocking unsolicited inbound traffic. It lives in a public subnet, has an Elastic IP, and automatically scales up to 100 Gbps bandwidth. You never need to patch, scale, or manage the underlying infrastructure. The NAT Gateway translates the private source IP of outbound packets to its own EIP, then returns responses to the original private IP.

After creating a NAT Gateway, add a route to the private subnet's route table: destination 0.0.0.0/0 → NAT Gateway ID. This tells all internet-bound traffic from private subnet instances to go to the NAT Gateway, which then forwards it through the Internet Gateway to the internet. The route table still has the local VPC route (e.g., 10.0.0.0/16 → local) for internal traffic. Without this route entry, private subnet instances still have no internet access even with a NAT Gateway deployed.

A NAT Gateway is AZ-specific—it only handles traffic from subnets in the same AZ. For high availability, deploy one NAT Gateway per AZ and create AZ-specific private route tables: the private route table in AZ-a routes 0.0.0.0/0 to the NAT-GW in AZ-a; the private route table in AZ-b routes to the NAT-GW in AZ-b. This avoids inter-AZ data transfer charges and ensures that if AZ-a fails, the instances in AZ-b (with their own NAT) continue to have internet access.

A NAT Instance is a self-managed EC2 instance running a NAT AMI—the legacy approach before NAT Gateways existed. NAT Instances require you to: disable source/destination check on the EC2 instance, manage bandwidth and scaling, patch the OS, and handle failures. They are cheaper for very low-bandwidth use cases and can be used as bastion hosts. NAT Gateways are the recommended choice for production: fully managed, automatically scaled, 99.99% availability SLA within an AZ, and no patching required. The exam has historically tested this comparison.

NAT Gateway pricing has two components: an hourly charge per NAT Gateway (approximately $0.045/hour in us-east-1, around $32/month), and a per-GB data processing charge (~$0.045/GB in us-east-1). For workloads that transfer large amounts of data through NAT (e.g., pulling large container images, bulk downloads), the data processing cost can dominate. Optimise NAT costs by: routing S3 and DynamoDB traffic through VPC Gateway Endpoints (bypasses NAT entirely, free), and routing AWS API calls through VPC Interface Endpoints instead of through NAT.

Database instances in private subnets should not route through the NAT Gateway—they have no business initiating connections to the internet. Databases only need to receive connections from the application tier (within the VPC) and potentially reach AWS services like S3 (for exports/imports) via a VPC endpoint. For database patching and updates, RDS is a managed service so you don't apply OS patches directly. For self-managed databases on EC2, use Systems Manager Patch Manager, which can patch via SSM without internet access if you have the SSM VPC endpoint configured.

NAT Gateway provides stateful outbound-only NAT: it allows initiated outbound connections and their responses, but blocks all unsolicited inbound traffic. It is not a firewall—it does not inspect or filter traffic content. For outbound traffic filtering (e.g., allow only specific destination domains or IPs from private subnets), you need additional controls: AWS Network Firewall deployed in the VPC, or a third-party firewall appliance behind a Gateway Load Balancer. Security groups and NACLs still apply to instances in private subnets regardless of NAT.

In addition to public NAT Gateways (with EIPs for internet access), AWS supports private NAT Gateways without an EIP. Private NAT Gateways are used to translate private IP addresses for traffic between VPCs or between a VPC and on-premises networks when CIDR ranges overlap. For example, if VPC-A (10.0.0.0/16) needs to communicate with an on-premises network that also uses 10.0.0.0/16, a private NAT Gateway in VPC-A translates the source IPs to a non-overlapping range before routing through a Transit Gateway to on-premises.

Monitor NAT Gateway health and performance through CloudWatch metrics. Key metrics: ActiveConnectionCount (current active TCP connections through the NAT), BytesInFromDestination / BytesInFromSource (data transfer in both directions), PacketDropCount (dropped packets—indicates bandwidth limits or errors), and ErrorPortAllocation (the NAT exhausted port allocations—may indicate port exhaustion from too many connections). Each NAT Gateway supports up to 55,000 simultaneous connections per unique destination; beyond that, connections may be dropped.

Not all private subnet workloads need a NAT Gateway. Consider the access pattern: if instances only need to communicate with other VPC resources and AWS services accessible via VPC endpoints (S3, DynamoDB, SSM, ECR, Secrets Manager), you can eliminate the NAT Gateway entirely—saving ~$32/month per AZ plus data processing charges. This is the ideal pattern for fully private microservices that use VPC Interface Endpoints for all AWS service access. Evaluate each service your instances call and check if a free Gateway Endpoint or paid Interface Endpoint can replace NAT.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: NAT Gateways enable outbound internet access for private subnet instances by translating their private IPs to an Elastic IP, you must add a 0.0.0.0/0 route in the private subnet route table pointing to the NAT Gateway, and deploy one NAT Gateway per AZ to achieve high availability and avoid cross-AZ data charges. Next up we compare Network ACLs and Security Groups for layered VPC defence.