Tools: How Traffic Leaves a Private Subnet in AWS

What Makes a Subnet “Private” ## The Role of the NAT Gateway ## Why Private Subnets Cannot Receive Inbound Internet Traffic ## Fully Isolated Private Subnets ## Using VPC Endpoints Instead of the Internet ## End-to-End Traffic Flow Examples ## Common Routing Patterns for Private Subnets ## Conclusion Understanding how traffic leaves a private subnet is an important part of AWS networking. Private subnets are often described as “not connected to the internet,” yet instances inside them can still download updates, call external APIs, or access managed AWS services. This behavior is fully intentional and driven by routing decisions inside the VPC. In this article, we’ll walk through how outbound traffic from a private subnet actually works, step by step, without jumping straight into complex architectures. A subnet in AWS is considered private not because of a special flag, but because of its routing behavior. A private subnet simply does not have a route that sends internet-bound traffic directly to an Internet Gateway (IGW). Most private subnets have a route table that looks like this: This small difference in routing has a big impact. Without a direct route to an IGW, resources in the subnet cannot accept inbound connections from the internet, even if security groups allow it. The most common way for traffic to leave a private subnet is through a NAT Gateway. A NAT Gateway acts as a controlled exit point for outbound traffic while preventing unsolicited inbound access. The key idea is simple. Private instances never talk to the internet directly. They send traffic to the NAT Gateway, which then communicates with the internet on their behalf. A typical setup looks like this: The NAT Gateway performs network address translation, replacing the private source IP with its own public IP. Responses from the internet return to the NAT Gateway, which then forwards them back to the original private instance. From the instance’s perspective, it can reach the internet, but it is never directly exposed. Even though private instances can send outbound requests, they cannot be reached from the internet. This is because: This design is intentional. It ensures that private subnets remain protected by default while still being useful for tasks like software updates, external API calls, or license validation. Not all private subnets need outbound access. Some are intentionally fully isolated. In these cases, the route table contains only the local VPC route. With no default route at all, instances in these subnets cannot leave the VPC. This pattern is common for database tiers, internal batch jobs, and highly sensitive workloads. Isolation at the routing level provides a strong security boundary even before security groups or network ACLs are considered. Another way traffic can leave a private subnet, without actually leaving the AWS network, is through VPC endpoints. With gateway or interface endpoints: In this case, the private subnet still does not have internet access, but it can communicate with specific AWS services efficiently and securely. Seeing the full flow helps connect the pieces. Outbound internet access from a private subnet Accessing S3 through a VPC endpoint These flows show that private does not mean cut off. It means controlled and intentional. As environments grow, consistent routing patterns help avoid confusion: These practices make troubleshooting and scaling much easier over time. Traffic leaving a private subnet in AWS follows clear and deliberate rules. Whether it exits through a NAT Gateway, stays within AWS via a VPC endpoint, or does not leave the VPC at all depends entirely on routing decisions. Once you understand that private subnets are defined by how traffic flows, not by hidden restrictions, designing secure and predictable networks becomes much easier. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - A local route for VPC-to-VPC communication (for example, 10.0.0.0/16 local) - A default route (0.0.0.0/0) pointing to a NAT Gateway, or no default route at all - Private subnet route table: 0.0.0.0/0 pointing to a NAT Gateway - NAT Gateway placed in a public subnet - The public subnet has a route to the IGW - They do not have public IP addresses - There is no route from the IGW back to their subnet - The NAT Gateway only allows response traffic for connections initiated from inside the VPC - Traffic to services like Amazon S3 or DynamoDB stays within AWS - No NAT Gateway or internet access is required - Routing remains private and predictable - An application in a private subnet makes an HTTP request to an external API. - The route table sends traffic to the NAT Gateway. - The NAT Gateway forwards the request through the IGW. - The response returns to the NAT Gateway. - The NAT Gateway sends it back to the private instance. - An instance sends traffic to the S3 service. - The route table matches the endpoint route. - Traffic stays inside the AWS network. - No NAT Gateway or IGW is involved. - Use separate route tables for private subnets with NAT access and fully isolated subnets - Place NAT Gateways in dedicated public subnets - Avoid mixing IGW and NAT routes in the same route table - Name route tables clearly to reflect their purpose