As I’m beginning to explore AWS services theoretically, I wanted to start looking beyond “what does this service do?” and understand why it exists in the first place. And for the first topic, I had one very important criterion: it had to start with N.
Because, well… N for Naveenya, N for NAT Gateway. 😌
NAT is all about networking.
It stands for Network Address Translation, and we’ve probably all come across the concept at some point if we’ve ever scratched our heads over “how exactly are these two VMs communicating?” or wondered how a machine without a public IP can still access the internet.
That second question is exactly where NAT Gateway becomes interesting.
Imagine a college campus. Hundreds of students are inside, and they need to occasionally step outside to buy something, access a resource, or grab coffee. But you probably don’t want random people from outside walking straight into every classroom. So, there’s a controlled entrance and exit. Students can go out, but outsiders don’t automatically get access to individual classrooms.
A private subnet works somewhat like those classrooms.
The instances inside it may need to reach the outside world, but there is no reason for those instances themselves to be directly exposed to the public internet.
That is the problem a NAT Gateway helps solve.
A NAT Gateway is placed in a public subnet and provides a path for resources in private subnets to initiate outbound connections to the internet. The private instance sends its traffic to the NAT Gateway, the NAT Gateway translates the private source IP into its public-facing IP, and the traffic then travels through an Internet Gateway to the internet.
The flow is essentially:
Private EC2 → Route Table → NAT Gateway → Internet Gateway → Internet
When the response comes back, the NAT Gateway translates the traffic back toward the private instance. The important part here is that the private instance initiated the connection. The internet doesn't suddenly get a direct route into that instance.
This is also why NAT Gateway should not be thought of as simply “a thing that gives private machines internet.” It provides outbound connectivity while keeping those resources without direct public internet reachability.
So, why not simply give every EC2 instance a public IP?
Well, technically, you could. But that defeats the purpose of having private resources in the first place. Consider a research server, database, or GPU instance. It might need to download Python packages, pull datasets, access external APIs, or retrieve model weights. None of that necessarily means it should be sitting directly on the public internet with a public IP.
This is where the private-public subnet distinction starts becoming useful.
A private instance can remain inside its private subnet while using the NAT Gateway as its controlled exit point. The route table essentially tells it: “For internet-bound traffic, don't go directly outside; send it here.”
And AWS didn't stop at simply providing the functionality. NAT Gateway is a fully managed service, which means AWS takes care of the underlying infrastructure, scaling, and availability instead of making you maintain an EC2 instance configured as a NAT instance.
That difference matters more than it initially sounds.
Before managed NAT Gateways, organisations could use NAT instances, which meant having another server to configure, patch, monitor, scale, and troubleshoot. With a managed NAT Gateway, that operational burden is largely moved to AWS.
Another interesting detail is that NAT isn't limited to public internet access. AWS also provides private NAT Gateway functionality for routing traffic toward other private networks, such as another VPC or an on-premises environment, without sending that traffic through the public internet.
For my own academic context, the clearest use case is a research or GPU cluster. Imagine EC2 instances running GNN training jobs. These machines could contain datasets, research code, model checkpoints, and experiment outputs. Keeping them in a private subnet makes sense. At the same time, those instances might need to install dependencies, download datasets, communicate with external services, or send experiment telemetry.
The workflow becomes:
Private GPU Instance → NAT Gateway → Internet Gateway → External Resource
The GPU instance stays private while still being able to reach outward.
Of course, there is a price for this convenience. NAT Gateway has both an hourly charge and data-processing charges, so workloads moving large amounts of data through it can become expensive. Architecture therefore isn't simply about asking “Will this work?” It also means asking “Is this the right path for this traffic?” That is where concepts such as VPC endpoints, routing strategies, and cost optimisation start entering the conversation.
There is also an Availability Zone consideration. A NAT Gateway is associated with a specific Availability Zone, so highly available multi-AZ architectures require deliberate planning around NAT Gateway placement and routing. In production environments, architects commonly consider NAT Gateways across multiple AZs rather than allowing a single component to become an unnecessary dependency.
And one final distinction is important: NAT Gateway is not a firewall. It helps prevent unsolicited inbound connections through the NAT path, but proper security still depends on mechanisms such as security groups and network ACLs.
What I like about NAT Gateway is that the underlying idea is actually quite simple.
Private resources need the internet → they send outbound traffic to the NAT Gateway → NAT Gateway translates the traffic → Internet Gateway carries it outside.
A small networking concept, but one that quietly sits underneath many real cloud architectures.
So, my first AWS deep dive started with a little personal branding gimmick:
N for Naveenya.
N for NAT Gateway.
But somewhere between private subnets, route tables, Elastic IPs, and outbound traffic, it stopped being just an AWS service to memorise.
It became a reminder that good cloud architecture is often about controlling how things are allowed to communicate.
And honestly, that feels like a pretty good place to begin.
DEEP DIVE - AWS #01 ☁️
One service at a time.
One concept at a time.
One rabbit hole at a time.
References:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
Top comments (0)