Most AWS architecture diagrams casually drop a NAT Gateway into private subnets and move on.
It works. It's easy. It's familiar.
But it also breaks one of the most powerful security boundaries AWS gives you: network isolation.
Sometimes the goal isn't lowest cost. Sometimes the goal is removing the risk entirely.
The Mental Model Most Teams Start With
The common pattern is a public subnet with an Internet Gateway, private subnets for workloads, a NAT Gateway for outbound traffic, and Security Groups restricting inbound access.
This gives the appearance of isolation:
Our resources are in private subnets.
But if those resources can reach the public internet through NAT, they are not isolated - they are simply non-routable from the outside. That distinction matters.
What NAT Gateway Actually Does
A NAT Gateway provides outbound internet access from private subnets by translating private IP addresses to a public address.
From a routing perspective:
Private Subnet → NAT Gateway → Internet Gateway → Internet
Your workloads can now talk to AWS public service endpoints, third-party APIs, package repositories - essentially anything on the internet.
That flexibility is why NAT is so popular.
It's also why it can become a security liability.
The Hidden Security Problem with NAT
If a workload is compromised, a NAT Gateway becomes the exit door. An attacker can reach command-and-control infrastructure, exfiltrate data to external endpoints, pull down additional tooling, and pivot to scanning targets outside your network. The NAT Gateway doesn't distinguish between legitimate outbound traffic and malicious activity - it just routes.
At that point you're relying entirely on IAM controls, application security, and egress filtering - which many environments never fully implement.
NAT turns your "private subnet" into a system with outbound internet access.
That may be acceptable. But sometimes it isn't.
What True Isolation Looks Like
An isolated VPC design removes the NAT Gateway entirely. There is no route to the internet - not even outbound. Workloads reach AWS services through VPC Endpoints, talk to each other through internal load balancers and private APIs, and that's it. The network boundary becomes a hard wall, not a filter.
Even if an attacker gains execution inside your workload, they cannot reach the internet.
That's a different security posture entirely.
This approach also strengthens compliance alignment and reduces blast radius if credentials leak. Endpoint policies in particular deserve attention here - they let you restrict not just which AWS services a VPC can reach, but which resources within those services. A policy on an S3 endpoint can limit access to specific buckets. A KMS endpoint policy can restrict which keys are accessible. NAT has no equivalent mechanism.
You're not just restricting inbound traffic - you're eliminating outbound risk.
When NAT Gateway Is Still the Right Choice
NAT is not wrong. It's just a different tradeoff.
If your workloads need general internet access - third-party APIs, OS package updates, external licensing servers, or dynamic outbound destinations - NAT is the straightforward answer. It's also simpler operationally, and for many workloads, simplicity wins.
When You Should Prefer VPC Endpoints
If your workloads only talk to AWS services, the question isn't whether endpoints are worth the complexity - it's whether you can justify giving those workloads internet access they don't need. For multi-tenant SaaS, sensitive data workloads, or anything with compliance requirements, the answer is usually no.
This pattern is increasingly common across financial platforms, healthcare systems, enterprise SaaS, and internal microservice platforms - anywhere the cost of a breach outweighs the convenience of a NAT Gateway.
A Hybrid Pattern That Works Well
Many architectures use both. Core services run in endpoint-only subnets with no route to the internet, while components that genuinely need external access - a webhook processor, a third-party integration layer - live in NAT-enabled subnets.
This preserves isolation where it matters while avoiding endpoint sprawl everywhere. The key is making the boundary intentional: workloads don't end up in NAT subnets by default, they end up there because they have a documented reason to reach the internet.
Cost Comparison - NAT Gateway vs VPC Endpoints
At first glance, NAT Gateways and VPC Endpoints look like a straightforward pricing decision. Typical pricing (varies slightly by region):
| Component | Hourly Cost (per AZ) | Data Processing |
|---|---|---|
| NAT Gateway | ~$0.045/hr | ~$0.045 per GB |
| Interface VPC Endpoint | ~$0.01/hr | ~$0.01 per GB |
| Gateway Endpoint (S3/DynamoDB) | $0 | $0 |
Worth noting: Gateway Endpoints for S3 and DynamoDB are completely free - no hourly charge, no data processing fee. These are two of the highest-traffic AWS services in most architectures, and there's no reason not to use them regardless of your security posture.
A NAT Gateway can serve all outbound destinations, while Interface Endpoints are created per service and per Availability Zone. That distinction changes the economics quickly.
For example, consider a workload deployed across two Availability Zones that needs access to several AWS services such as Secrets Manager, SQS, CloudWatch Logs, STS, and KMS. It's common to end up with 6–10 endpoints.
10 endpoints × 2 AZ × $0.01/hr ≈ $0.20/hr (~$146/month)
2 NAT Gateways × $0.045/hr ≈ $0.09/hr (~$65/month)
In this case, endpoints cost more than NAT.
That surprises many teams.
Endpoints do process traffic at a lower per-GB cost, but for many workloads the hourly cost dominates:
| Path | Cost per GB |
|---|---|
| NAT | ~$0.045 |
| Endpoint | ~$0.01 |
Cost alone doesn't tell the full story. NAT provides broad internet egress, while endpoints provide narrowly scoped private access to specific AWS services.
You're not just paying for connectivity - you're paying for reduced attack surface and stronger isolation.
A useful way to frame the decision is:
Is preventing unrestricted internet egress worth an additional ~$80/month?
For many systems - especially SaaS platforms or regulated workloads - the answer is yes.
The Question Worth Asking
The useful framing isn't "which is cheaper?" It's:
"Do I want my workloads to have internet access at all?"
If the answer is no, NAT isn't even an option.
Once teams internalize that distinction - that NAT is a convenience feature and endpoints are a security primitive - the architecture conversation changes. You stop comparing line items and start comparing risk models.
AWS gives us the tools to build extremely isolated environments. But the default patterns most teams copy include NAT by habit rather than intent. Choosing VPC Endpoints - even when they cost more - means your workloads can only reach what you've explicitly allowed. The attack surface shrinks, compliance becomes easier to demonstrate, and the security boundary becomes something you can reason about rather than hope is sufficient.
