Let’s build a Cloud Network- 04: NAT Instances
Welcome to the fourth article in our series, where we explore fundamental networking concepts in AWS. In this article, we’ll explore AWS NAT Instances, a useful solution when dealing with EC2 instances in private subnets that need internet connectivity. When our EC2 instances reside in private subnets, they lack direct access to the outside world. To bridge this gap, we have two options: NAT Instances and NAT Gateways.
In this article, let’s focus on understanding NAT Instances and how they function. We’ll delve into their concept and learn how they effectively facilitate internet access for our resources within private subnets.
NAT, which stands for Network Address Translation, serves an essential role in AWS networking. By using a NAT instance, we enable EC2 instances within private subnets to establish outbound connections to the internet. For this setup to function effectively, it’s crucial to launch the NAT instance within a Public subnet. We also need to attach a fixed Elastic IP to the NAT instance for this to work.
Imagine this situation where we have an EC2 instance within a private subnet, and we want to access it from a server in our on-premises network. To make this work, we’ll follow the steps outlined in the diagram below.
First, we launch an EC2 instance into our public subnet. This instance will serve as our NAT (Network Address Translation) instance. To ensure its accessibility, we’ll attach an elastic IP address to this instance.
Next, we need to configure the route table of our private subnet. We’ll set it up in such a way that traffic from the private subnet is directed to the NAT instance.
So, when our EC2 instances within the private subnet attempt to communicate with the on-premises server, the traffic will flow through the NAT instance, effectively facilitating the connection between the two networks.
The magic occurring in the background
Let’s dive into what occurs when our EC2 instance in the private subnet attempts to send traffic to our on-premises server. To grasp this concept better, take a look at the following diagram.
When the private EC2 instance wants to access the on-premises server, it sends a request (Flow A) through the NAT instance. The NAT instance sees the source IP as 10.0.0.25 (IP of the Private EC2) and the destination IP as 132.115.85.196, which is the on-premises public IP address. At this point, the NAT instance takes over and forwards the traffic to the requested destination on behalf of the private EC2 instance (Flow B).
Now, here’s the crucial part — when the NAT instance sends the request to the on-premises server (Flow B), it changes the source IP to its own public IP address instead of the Private EC2’s IP address. This way, from the on-premises server’s perspective, it appears that the traffic is coming from the NAT instance’s IP address rather than the Private EC2’s IP address.
Once the on-premises server responds, it sends the traffic back to the NAT instance’s public IP address (Flow C). The NAT instance then redirects the traffic back to the Private EC2 instance (Flow D).
Since the source and destination IP addresses are being rewritten during this process, it’s crucial to remember that when creating a NAT instance, we must disable the “Source/Destination Check” option in the EC2 settings. This ensures that the NAT instance can effectively handle the traffic forwarding and translation.
Wrapping Up
It’s essential to be aware that NAT instances reached the end of standard support in 2020, and a more reliable alternative for them is NAT gateways. Using NAT instances comes with several challenges, such as being managed by us, which involves tasks like installing software updates and operating system patches on the instance.
To avoid these issues and ensure a more robust and hassle-free solution, it’s recommended to opt for NAT gateways, which are fully managed AWS resources and provide better performance and scalability for handling outbound internet traffic from private subnets.
Stay tuned as we explore important networking configurations in our AWS environment!
You can explore the other articles from this series by accessing the following links.
Let’s build a Cloud Network- 01: VPC and Subnets
Let’s build a Cloud Network — 02: Internet Gateway and Route Tables
At Apium Innovations we build world-class software products while following the best practices in DevOps, follow us to learn more.
