Search for a command to run...
Securely enabling outbound internet access from private subnets in AWS using NAT Gateway.
A software engineer who likes to explore new technologies, problem-solving, build projects, and have a keen interest in Web development.
No comments yet. Be the first to comment.
How a 3-line Prisma query fired 1,847 database queries per request — and how we found, fixed, and prevented it from ever coming back.
When building backend systems, especially SaaS applications, handling background jobs correctly is critical. Whether it's sending emails, processing payments, or scheduling reminders, choosing the rig
Guide to Zero-Interruptions Deployment for Node.js on AWS EC2
Clearing the Confusion Around JavaScript Function Arguments
When we work with objects and arrays in JavaScript, we often need to copy data. But copying in JavaScript is not always as simple as it looks. Depending on the method you use, you may end up with shared references which can cause unexpected changes i...
Delivering modern apps securely in AWS often requires placing critical resources inside private subnets — for example, EC2 app servers, Lambda functions, or RDS databases.
But here’s the challenge:
These resources can’t directly access the internet.
And yet, they often need outbound connectivity (e.g., downloading packages, calling third-party APIs).
This blog explains how we solved that problem at scale using NAT Gateway.
Private Subnet Isolation
By design, private subnets cannot route traffic to the Internet Gateway.
EC2 or Lambda inside them had no internet access.
Broken External Calls
Our workloads needed outbound internet:
EC2 instances → install security patches.
Lambdas → call Firebase/FCM APIs.
Without internet, everything failed.
Direct IGW Not an Option
Attaching Internet Gateway directly to private subnet would expose resources.
Security rules prevented that.
We deployed a NAT Gateway in the public subnet of our VPC.
NAT Gateway gets an Elastic IP.
It can reach the internet via the Internet Gateway.
Private subnet instances send traffic → NAT Gateway → Internet.
Inbound traffic from the internet is blocked.
For each private subnet, we updated the route table:
Default route 0.0.0.0/0 → NAT Gateway.
Internal traffic (10.0.0.0/16) still routes locally within the VPC.
This gave private resources outbound internet access while keeping them hidden.
We launched an EC2 in the private subnet and verified connectivity:
ping google.com
sudo yum update -y
curl https://api.github.com
Outbound requests succeeded.
Inbound requests from internet were blocked — exactly what we wanted.
+-----------------------+
| Internet |
+-----------+-----------+
|
(Internet Gateway)
|
+-----------+-----------+
| Public Subnet |
| NAT Gateway + EIP |
+-----------+-----------+
|
Route to NAT Gateway
|
+-----------+-----------+
| Private Subnet |
| EC2 / Lambda / RDS |
+-----------------------+
By introducing a NAT Gateway, we achieved:
Secure isolation: Private subnets remain unreachable from the internet.
Controlled outbound: Instances can fetch updates, call APIs, or access S3.
Scalability: Fully managed by AWS (no manual patching or scaling).
Today, our workloads run inside private subnets with:
Private, low-latency access to databases inside the VPC.
Outbound internet connectivity for external APIs via NAT Gateway.
This simple design pattern is a must-know for any AWS-based architecture where you want security + flexibility.