Why Your Private EC2 Instance Cannot Access the Internet — Understanding NAT Gateway
Why can't a private EC2 instance access the internet? Learn how NAT Gateways work, configure routing between public and private subnets, troubleshoot connectivity issues, and avoid unnecessary AWS costs with practical examples.
Have you ever launched an EC2 instance inside a private subnet and wondered why it cannot access the internet, even though your public EC2 instance works perfectly?
Imagine you're running a backend application on a private EC2 instance. Your application needs to download software updates, install dependencies, or call an external API. But whenever you try to access an external website, the request fails.
Why does this happen? And how can you provide internet access without exposing your private instance directly to the internet?
The answer lies in understanding VPC routing, Internet Gateways, and NAT Gateways.
In this article, we'll understand the problem, explore how a NAT Gateway works, configure one step by step, troubleshoot common issues, and discuss an important consideration that every AWS learner should know: cost.
Private EC2 → NAT Gateway → Internet Gateway → Internet: the outbound path, route tables, and setup checklist at a glance.
New to AWS VPCs?
Before diving deeper into NAT Gateways, check out my article, AWS VPC Explained for Beginners: From CIDR to Interview Questions . It covers the fundamentals of VPC networking and will help you understand the concepts discussed here.
1. The Problem: Why Can't My Private EC2 Instance Access the Internet?
Let's start with a simple example.
Suppose you have an AWS VPC containing two EC2 instances:
- Public EC2 instance: Located in a public subnet and configured for direct internet connectivity.
- Private EC2 instance: Located in a private subnet without a public IP address.
Your public instance can access external websites, but your private instance cannot.
For example, running the following command on your private instance might result in a connection timeout:
1
curl -I --max-time 10 https://www.google.comThis can happen because the private subnet doesn't have a route to the internet.
By default, a VPC has a local route that allows communication within its IPv4 network. However, that route alone doesn't provide internet connectivity.
For a typical private EC2 instance, two important things are missing:
- It doesn't have a direct route to an Internet Gateway.
- It doesn't have a public IPv4 address for direct internet communication.
But here's the interesting part: a private instance can access the internet without having its own public IP address.
We just need to provide the correct network path.
That's where a NAT Gateway comes in.
2. Understanding the VPC Setup
Before configuring a NAT Gateway, let's understand the components involved.
What is an Internet Gateway?
An Internet Gateway (IGW) is an AWS component that enables communication between a VPC and the internet.
For a typical EC2 instance to communicate directly with the public IPv4 internet, it needs:
- A public IPv4 address or Elastic IP.
- A route to an Internet Gateway.
- Appropriate security group and network ACL rules.
Attaching an Internet Gateway to a VPC doesn't automatically give every EC2 instance internet access. The routing and addressing configuration must also be correct.
What is a Public Subnet?
A subnet is considered public when its associated route table contains a route to an Internet Gateway for internet-bound traffic.
For example, the public subnet's route table might look like this:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | Internet Gateway |
Here,
10.0.0.0/16 represents the VPC's IPv4 CIDR block, while 0.0.0.0/0 represents all IPv4 destinations.An EC2 instance in this subnet still needs suitable public addressing and security configuration to access the internet directly.
What is a Private Subnet?
A private subnet typically doesn't have a direct route to an Internet Gateway.
Its route table might initially look like this:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
This allows communication with other resources within the VPC, subject to routing and security rules, but doesn't provide a route to the public internet.
Private subnets are commonly used for backend servers, application services, and other resources that shouldn't be directly reachable from the public internet.
However, these resources may still need outbound connectivity to download updates, retrieve dependencies, or call external APIs.
The goal is to allow outbound internet access while keeping private instances without public IP addresses.
3. What Is a NAT Gateway?
A NAT Gateway (Network Address Translation Gateway) is an AWS-managed service that allows resources in a private subnet to initiate connections to destinations outside the VPC, including the public internet.
For a typical public NAT Gateway setup, we:
- Create the NAT Gateway in a public subnet.
- Associate an Elastic IP address with it.
- Ensure the public subnet has a route to an Internet Gateway.
- Update the private subnet's route table to direct internet-bound traffic to the NAT Gateway.
When a private EC2 instance initiates a connection to an external server, the NAT Gateway translates the source address so that the request can travel through the internet using the NAT Gateway's public IP address.
The response returns through the NAT Gateway, which forwards it to the originating private instance.
The private EC2 instance doesn't need its own public IPv4 address for this communication.
Does a NAT Gateway Allow Inbound Connections?
No, not as a general mechanism for accepting new inbound internet connections.
A NAT Gateway allows return traffic for connections initiated by resources behind it. It doesn't work like a public-facing web server or load balancer that accepts new connections from the internet.
This distinction is important: your private instance can initiate a connection to an external server and receive its response without being directly exposed to the internet.
4. How Does a NAT Gateway Work?
Let's follow a request from a private EC2 instance to an external website.
Imagine your instance needs to download a software package.
Step 1: The private EC2 instance initiates a request.
The instance sends a request to an external server, such as a package repository.
Step 2: The private subnet's route table forwards the traffic to the NAT Gateway.
The route table contains:
0.0.0.0/0 → NAT GatewayThis tells AWS to send internet-bound IPv4 traffic to the NAT Gateway.
Step 3: The NAT Gateway forwards the request to the internet.
The NAT Gateway translates the source address and uses its public IP address for communication with the external destination.
Step 4: The external server sends a response.
The response travels back to the NAT Gateway through the Internet Gateway.
Step 5: The NAT Gateway forwards the response to the private instance.
The NAT Gateway translates the traffic back and delivers the response to the originating instance.
The complete traffic flow is:
Private EC2 → NAT Gateway → Internet Gateway → InternetThe response follows the reverse path for that connection.
Notice that the NAT Gateway is located in the public subnet, while the private EC2 instance remains in the private subnet.
The NAT Gateway doesn't sit in front of the private instance like a load balancer. Instead, the private subnet's route table directs outbound traffic to it.
5. Public NAT Gateway vs. Internet Gateway
These two services are easy to confuse, so let's compare them.
| Feature | Internet Gateway | Public NAT Gateway |
|---|---|---|
| Primary purpose | Enables internet connectivity for eligible VPC resources | Enables outbound internet connectivity for private resources |
| Placement | Attached to the VPC | Created in a public subnet |
| Public IP required on private EC2? | Direct IPv4 internet access typically requires one | No |
| Accepts new inbound connections to private instances automatically? | No; appropriate addressing, routes, and security rules are required | No |
| Typical use case | Public-facing web servers | Private backend servers downloading updates |
A NAT Gateway doesn't replace an Internet Gateway. A public NAT Gateway uses the Internet Gateway to communicate with the public internet.
Think of the Internet Gateway as the VPC's connection to the internet and the NAT Gateway as the component that enables private IPv4 resources to initiate outbound connections through that connection.
6. Step-by-Step: Configure a NAT Gateway
Now let's configure a simple VPC with a public subnet and a private subnet.
Step 1: Create a VPC
Create a VPC with an IPv4 CIDR block such as:
10.0.0.0/16Create two subnets:
- Public subnet:
10.0.1.0/24 - Private subnet:
10.0.2.0/24
These CIDR ranges are examples. Make sure your subnet ranges don't overlap with other networks you need to connect.
Step 2: Create and Attach an Internet Gateway
Open the VPC console, create an Internet Gateway, and attach it to your VPC.
Next, open the route table associated with the public subnet and add the following route:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | Internet Gateway |
Make sure the public subnet is associated with this route table.
Step 3: Create a NAT Gateway
Navigate to VPC → NAT Gateways → Create NAT Gateway.
Configure the following:
- Subnet: Select the public subnet.
- Connectivity type: Public.
- Elastic IP address: Allocate or select an Elastic IP address.
Create the NAT Gateway and wait until its status becomes
Available.The NAT Gateway must be in a public subnet with a working route to the Internet Gateway.
Step 4: Update the Private Subnet's Route Table
Open the route table associated with your private subnet.
Add the following route:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | NAT Gateway |
Select the NAT Gateway you created as the target for
0.0.0.0/0.This is the key step that enables the private subnet to send internet-bound IPv4 traffic through the NAT Gateway.
Make sure you're updating the route table actually associated with the private subnet.
Step 5: Launch a Private EC2 Instance
Launch an EC2 instance in the private subnet without assigning it a public IPv4 address.
Ensure its security group permits the outbound connections your application needs.
Also verify that the network ACLs permit the required outbound traffic and return traffic.
To connect to the instance for testing, you can use AWS Systems Manager Session Manager if the instance and your AWS environment are configured for it. Other suitable private access methods are also possible.
Step 6: Test Internet Connectivity
Once the NAT Gateway is available and the route table is updated, run the following command on your private EC2 instance:
1
curl -I --max-time 10 https://www.google.comIf the configuration is correct and the destination is reachable, you should receive an HTTP response.
You can also test DNS resolution separately:
1
nslookup www.google.comIf DNS resolution works but the HTTPS request times out, investigate routing, security rules, and connectivity to the destination.
If DNS resolution fails, check the VPC's DNS settings and the instance's resolver configuration.
A failed test doesn't necessarily mean the NAT Gateway is broken. The problem could be elsewhere in the networking or application configuration.
7. Troubleshooting: What If It Still Doesn't Work?
If your private EC2 instance cannot access the internet after setting up a NAT Gateway, check the following items.
1. Is the NAT Gateway Available?
Open the NAT Gateway details and confirm that its status is
Available.2. Is the NAT Gateway in a Public Subnet?
The public subnet's route table must have a working route to the Internet Gateway:
0.0.0.0/0 → Internet GatewayWithout this route, the NAT Gateway won't have the required path to the public IPv4 internet.
3. Does the Private Subnet Use the Correct Route Table?
Confirm that the route table associated with the private subnet contains:
0.0.0.0/0 → NAT GatewayIf the route is missing or the wrong route table is associated with the subnet, the instance won't use the NAT Gateway as intended.
4. Are Security Groups and Network ACLs Configured Correctly?
Security groups are stateful, so responses to permitted outbound connections are generally allowed automatically.
Network ACLs are stateless. They must permit both the outbound request and the corresponding return traffic. For HTTPS, this generally means allowing the required outbound TCP traffic and appropriate inbound ephemeral ports for responses, along with any other rules your setup requires.
5. Is DNS Resolution Working?
If the instance cannot resolve a hostname, check DNS independently of the NAT Gateway.
Review the VPC's DNS support, relevant DNS settings, and the instance's resolver configuration.
6. Is the Destination Reachable?
The external server, a firewall, a proxy, or an organizational policy may block the connection.
Try another known destination if appropriate, and inspect the actual error message rather than assuming every failure is a routing problem.
My recommended debugging order: Check the private route table, public route table, NAT Gateway status, security groups and network ACLs, DNS, and finally the destination service.
8. Common Mistakes to Avoid
Here are some common mistakes when configuring NAT Gateways:
- Creating a public NAT Gateway in a private subnet.
- Forgetting to allocate or associate an Elastic IP address.
- Missing the Internet Gateway route in the public subnet.
- Adding the NAT route to the wrong private route table.
- Assuming that attaching an Internet Gateway automatically gives every EC2 instance internet access.
- Assuming a NAT Gateway accepts unsolicited inbound connections.
- Overlooking security group, network ACL, or DNS configuration.
- Forgetting that NAT Gateway traffic and data processing can incur charges.
- Leaving the NAT Gateway running after completing a practice lab.
The last mistake is especially important for students and anyone learning AWS.
9. AWS NAT Gateway Costs: Don't Forget to Clean Up
A NAT Gateway is convenient, but it is not free.
AWS charges for NAT Gateway usage, including the time it runs and the amount of data it processes. Additional data transfer charges may also apply depending on your architecture and traffic.
The important thing to remember is that a NAT Gateway can continue generating charges even when you're not actively using your lab.
For example, you might create a NAT Gateway to test internet access from a private EC2 instance, finish your experiment, and forget to delete the resource.
That can lead to unnecessary costs.
How Can You Avoid Unnecessary Charges?
After finishing your lab:
- Delete the NAT Gateway if you no longer need it.
- Check whether the associated Elastic IP address is still allocated and release it if it is unused.
- Remove other temporary resources that you created for the experiment.
- Review your AWS billing dashboard and Cost Explorer to monitor charges.
- Check the current pricing for your AWS Region before starting a lab.
Deleting the NAT Gateway doesn't automatically clean up every associated resource, so review your VPC resources and Elastic IP addresses separately.
Can You Avoid a NAT Gateway Entirely?
Sometimes, yes.
If your private instance only needs to access supported AWS services, a VPC endpoint may be a better option.
For example, an Amazon S3 gateway endpoint can allow eligible resources in your VPC to access S3 without sending that traffic through a NAT Gateway.
Other AWS services support interface endpoints, which have their own configuration and pricing considerations.
However, VPC endpoints don't replace a NAT Gateway for general public internet access. Choose the solution based on the destinations your application needs to reach.
For production workloads, also consider availability. A NAT Gateway is associated with a specific Availability Zone, so architectures that require high availability commonly deploy NAT Gateways across multiple Availability Zones and configure private subnet routes accordingly. This improves resilience but increases cost.
You can check the official Amazon VPC pricing page for current pricing details.
10. Final Thoughts
A private EC2 instance cannot directly access the public IPv4 internet simply because it exists inside a VPC. It needs a suitable network path, and private instances generally don't have the public IP addresses required for direct internet connectivity.
A public NAT Gateway provides a way for private resources to initiate outbound internet connections while keeping those instances without public IP addresses.
Once you understand how the components work together, the configuration becomes much easier:
- Internet Gateway: Provides the VPC's connection to the internet.
- NAT Gateway: Enables private resources to initiate outbound IPv4 internet connections.
- Route tables: Determine where network traffic should go.
- Security groups and network ACLs: Control which traffic is allowed.
The next time a private EC2 instance cannot download a package or reach an external API, don't immediately assume something is wrong with the instance itself.
Start by tracing the traffic and checking the routes.
And if you're experimenting in your own AWS account, remember to clean up resources when you're done. Learning cloud networking is valuable, but unnecessary cloud charges aren't part of the lesson!
Let's Discuss!
When learning AWS networking, which concept confused you the most: Internet Gateways, NAT Gateways, or route tables?
Have you ever spent time debugging an EC2 connectivity issue that turned out to be a routing problem? Share your experience in the comments!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article