NAT Gateway vs VPC Endpoints: Which Path Should Your Private AWS Traffic Take?

Private subnets are a fundamental best practice in AWS. By placing EC2 instances, containers and databases within these subnets, you prevent the internet from initiating connections to them, thereby reducing security risks. However, private workloads still require access to various resources such as operating system repositories, third-party APIs, and AWS services like Amazon S3.

AWS provides multiple methods to facilitate this access, but they are not interchangeable. This article explores three such tools: NAT Gateway for outbound access from private subnets, S3 Gateway Endpoint for cost-effective, route-table-based access to S3 within a VPC, and S3 Interface Endpoint (AWS PrivateLink) for private S3 access that can extend beyond the VPC, for instance to on-premises networks.

By the end, readers should be able to evaluate requirements and select the appropriate method, along with an explanation of the rationale behind the choice.

Note that technical statements in this article are derived from official AWS documentation and blog posts listed in the references section. Pricing may vary and differs by region, so the focus is on the cost model and directing readers to the relevant AWS pricing pages rather than quoting fixed numbers. Additionally, console labels may change over time, so it's essential to verify current labels when using these services.

Before diving into the comparisons, let's clarify some key terms. A VPC represents a private, isolated network within AWS, defined by one or more CIDR ranges. Public subnets are those with route tables pointing to an Internet Gateway (IGW), allowing outbound internet access. Private subnets lack direct routes to an IGW, and their resources utilize private IP addresses exclusively.

A route table is a collection of rules determining where traffic exits a subnet, with the most specific matching route taking precedence. The IGW connects public subnets to the internet, handling the mapping between public IPv4 addresses and private ones for resources with public addresses.

Two primary components are involved in outbound traffic from private subnets: NAT Gateway and S3 Gateway Endpoint. A NAT Gateway provides network address translation for resources in private subnets, allowing them to send outbound traffic while maintaining private IPv4 addresses. The NAT Gateway translates the source IP addresses of outgoing packets and reverses the process for incoming replies.

There are two connectivity types for NAT Gateways: public and private. Public NAT Gateways, the default option, offer outbound internet access but require an Elastic IP and a route to an Internet Gateway for internet access. Private NAT Gateways, on the other hand, do not provide internet access but translate addresses for communication with other private networks, such as when dealing with overlapping CIDR ranges.

An EC2 instance in a private subnet can access AWS services through three main paths. First, it can route traffic through a NAT Gateway to the service's public endpoint. Second, it can utilize an S3 Gateway Endpoint, which requires a specific route in the subnet's route table. Third, it can use an S3 Interface Endpoint (AWS PrivateLink), which enables private S3 access and can extend beyond the VPC, for example, to on-premises networks.

A flowchart illustrates these three exit paths from a private subnet, with the route table and DNS for the interface endpoint determining which path is used.

A NAT Gateway performs network address translation for resources in private subnets, ensuring that instances retain their private IPv4 addresses. The NAT Gateway substitutes the source address of outgoing packets and translates replies back to their original destinations. In terms of connectivity, there are two options: public and private NAT Gateways.

Public NAT Gateways, the default choice, enable outbound internet access from private subnets and require connectivity to other VPCs or on-premises networks, using an Elastic IP associated at creation. Public NAT Gateways must be paired with an Internet Gateway and are exclusively used for internet access, with no unsolicited inbound connections allowed.

Private NAT Gateways, in contrast, do not grant internet access and are designed to translate addresses for communication with other private networks, such as in scenarios where CIDR ranges overlap.

NAT Gateways come in two variants: classic (zonal) and regional. Classic NAT Gateways operate within a single Availability Zone, with a common design involving one NAT Gateway per AZ to ensure resilience. This configuration also prevents traffic from crossing AZs just to reach NAT, which could incur additional data transfer costs.

AWS also offers regional NAT Gateways, which span across all Availability Zones where workloads are hosted, simplifying routing but not supporting private connectivity. As always, it's crucial to consult the documentation for the current Region availability and limits before making a decision.

NAT Gateways are ideally suited for downloading operating system updates and packages from public repositories, calling third-party SaaS APIs, and any destination on the public internet that lacks a private path. However, it's essential to be aware of the associated costs and limits. NAT Gateways are billed based on time and data processed, which means heavy traffic to AWS services through NAT can lead to increased expenses.

Furthermore, NAT Gateways support only outbound traffic and cannot be employed to publish services. While S3 access through NAT Gateways is possible, it's not a means to expose services to the internet.