Skip to main content

Command Palette

Search for a command to run...

AWS Day 45: Configure NAT Gateway for Internet Access in a Private VPC

Updated
5 min readView as Markdown
AWS Day 45: Configure NAT Gateway for Internet Access in a Private VPC
A

"I'm a 3rd-year Computer Engineering student at Marwadi University with skills in C++, web development (MERN stack), and DevOps tools like Kubernetes. I contribute to open-source projects and share tech knowledge on GitHub and LinkedIn. I'm learning cloud technologies and app deployment. As an Internshala Student Partner, I help others find jobs and courses." now currently focusing on #90DaysOfDevops

As part of my KodeKloud 100 Days of Cloud journey, Day 45 focused on configuring a NAT Gateway to provide outbound internet access to an EC2 instance running inside a private subnet.

The objective of this lab was to understand how resources in a private subnet can access the internet without being directly exposed to inbound internet traffic.

The existing environment already contained a VPC and a private EC2 instance. My task was to build the required public networking components, configure the NAT Gateway, update the private route table, and verify connectivity by checking for a test file uploaded from the private EC2 instance to an S3 bucket.

Step 1: Use the Existing VPC

The VPC was already available:

datacenter-priv-vpc

Its IPv4 CIDR was:

10.1.0.0/16

The existing private subnet was also already created.

Therefore, I did not create another VPC or modify the existing private subnet.

Instead, I created the additional public networking components inside the same VPC.

The resulting structure would be:

datacenter-priv-vpc
CIDR: 10.1.0.0/16

Step 2: Create the Public Subnet

I opened:

AWS Console → VPC → Subnets → Create subnet

For the VPC, I selected:

datacenter-priv-vpc

The subnet was named:

datacenter-pub-subnet

The subnet must use an IPv4 CIDR block that is inside the VPC CIDR and does not overlap with the existing private subnet.

The Availability Zone can be selected according to the lab's networking requirements.

The important point is that this subnet will become the public subnet used by the NAT Gateway.

Step 3: Create the Internet Gateway

Next, I opened:

VPC → Internet Gateways → Create internet gateway

I created an Internet Gateway named:

datacenter-ig

The Internet Gateway is the component that provides a path between the VPC and the public internet.

However, simply creating an Internet Gateway is not enough.

It must also be attached to the VPC.

I attached:

datacenter-ig
        |
        v
datacenter-priv-vpc

After attachment, the VPC had a gateway capable of providing internet connectivity to subnets whose route tables point to it.

Step 4: Create the Public Route Table

I then opened:

VPC → Route Tables → Create route table

The route table was named:

datacenter-pub-rt

I associated it with:

datacenter-priv-vpc

A route table determines where network traffic from associated subnets should be sent.

Step 5: Add the Internet Gateway Route

After creating the public route table, I added the default route:

Destination : 0.0.0.0/0
Target      : Internet Gateway

The route table therefore contained:

Destination     Target
10.1.0.0/16     local
0.0.0.0/0       datacenter-ig

Step 6: Create the NAT Gateway

With the public subnet and Internet Gateway configured, I created the NAT Gateway.

I opened:

VPC → NAT Gateways → Create NAT Gateway

The NAT Gateway was named:

datacenter-natgw

For the connectivity type, I selected:

Step 7: Allocate an Elastic IP

A public NAT Gateway requires a public IP address.

For the NAT Gateway, I selected the automatic Elastic IP allocation option.

The resulting architecture was:

NAT Gateway
    |
    v
Elastic IP
    |
    v
Internet Gateway
    |
    v
Internet

The Elastic IP provides a stable public IPv4 address for the NAT Gateway.

The private EC2 instance does not receive this public IP.

Instead, the NAT Gateway uses the public address when communicating with external destinations.

Step 8: Place the NAT Gateway in the Public Subnet

The NAT Gateway was created in:

datacenter-pub-subnet

This is one of the most important parts of the configuration.

A NAT Gateway used for public internet access needs to be reachable through a route to an Internet Gateway.

Step 9: Update the Private Route Table

The next and most important configuration was modifying the route table associated with the existing private subnet.

The private route table already had the local VPC route:

10.1.0.0/16 → local

I added the default route:

0.0.0.0/0 → NAT Gateway

The resulting private route table was:

Destination     Target
10.1.0.0/16     local
0.0.0.0/0       NAT Gateway

This single route is what tells the private EC2 instance:

For any destination outside the VPC, send the traffic to the NAT Gateway.

Step 10: Verify the Private Route

Before testing the application, I verified that the private route table contained:

0.0.0.0/0
        |
        v
NAT Gateway

This is essential.

If the private route table instead pointed to the Internet Gateway:

0.0.0.0/0 → Internet Gateway

the private instance would not suddenly become internet-enabled because an Internet Gateway requires the instance to have a public IPv4 address for direct internet communication.

Conclusion

Day 45 focused on understanding one of the most common AWS VPC architectures: providing outbound internet access to private resources using a NAT Gateway.

I used the existing datacenter-priv-vpc and created a new public subnet named datacenter-pub-subnet. I then created and attached the datacenter-ig Internet Gateway and configured the datacenter-pub-rt route table with a default route to the Internet Gateway.

Next, I created the datacenter-natgw NAT Gateway in the public subnet and allocated an Elastic IP for it.

100 Days Of Cloud (AWS)

Part 1 of 38

This series documents my 100 Days of Cloud journey with AWS using KodeKloud. Each blog covers one daily task with hands-on practice, simple explanations, and real learning for beginners and cloud aspirants.

Up next

AWS Day 44: Implementing Auto Scaling for High Availability in AWS

As part of my KodeKloud 100 Days of Cloud journey, Day 44 focused on building a highly available web application using Amazon EC2, Auto Scaling Groups, and an Application Load Balancer (ALB). The goal