Amazon offers VPC for creating a secured private network space, to host and run their Servers. In AWS VPC, you can create public & private subnets. Public subnets are used to host the Internet facing servers (mostly web / application servers) that you want inbound internet traffic allowed to and private subnets for backend instances (mostly Database servers) that you do not want to be directly addressable from the Internet. These DB Servers would still need access to internet for their updates and any other Interfacing that may need to be made to the internet. This is possible by routing the traffic through a mediating instance called the NAT instance (Network Address Translation instance). This mediator will need to be launched in the public subnet with Elastic IP and has to and from internet access. It simply performs the Network Address Translation and acts as a gateway to internet for the private subnet.
While this being the case, if the connectivity of Internet from private subnet becomes a critical factor, then there is a need to design High Availability for the same.
This blog is for those who are wondering what would happen when the NAT instance associated with the private subnet of their VPC, to allow outbound internet access fails.
Yes folks, there is a way by which you can overcome this by having not one but 2 NAT instances and leverage bidirectional monitoring between those two NAT instances to implement a high availability (HA) failover solution for network address translation (NAT).
For those who are new to this maze of services, worry not! The following paragraphs will take you through the process with ease.
This image would exactly depict the above said.
Now comes a potential failure situation. What if the single NAT instance that you launched to allow outbound internet access for the instances in your private subnet fails or crashes ?
The prevention scenario would be to have not one but rather two NAT instances, each monitoring each other and leveraging their purpose thereby offering high availability.
Ok, so you have decided to take the preventive step, let us go through the requirements and then the tasks for the same.
What you will need –
- An Amazon VPC.
- 2 Linux Amazon EC2 NAT instances.
- Any number of instances that you would want to have in the private and public subnets.
- EIPs (Elastic IPs) for the instances in the public subnet.
- Route tables that would allow the NAT instances to act as mediators.
- A shell script that you will download from here for the configuration.
Now let’s go through each of the step and get this up and working.
Step 1: Creation of an Amazon VPC.
What you need here is a VPC with one public subnet only. Once you create this, add 3 more subnets of your choice one in the same AZ as the subnet that came along with the VPC creation and the other two in a different AZ.
If you are new to this, or you don’t really get a complete picture of how to go about it, worry not! We have for you, an exclusive step by step procedure to do this at Appendix A.
Before we launch our NAT instances, let us create a security group for the same. A typical NAT instance must allow inbound SSH traffic from the private subnet (or the entire VPC) and outbound HTTP/HTTPS (or ALL traffic) traffic to the internet.
Check out Appendix B for a detailed explanation on creation of a security group for the NAT instances that you would be launching.
Step 2 – Setting up an IAM role:
What is needed next is an EC2 role that will grant your NAT instances permissions to take over routing when the other NAT instance fails.
So create a role and simply add this script to the policy document and hit save!
For a detailed pictorial depiction, do check out Appendix C that will take you through this.
Step 3: Now comes the most important part – Getting your NAT instances ready.
It’s finally time to launch the two NAT (Linux Amazon EC2) instances into the VPC. For this, you could use the Amazon Linux AMI or anything else of your choice. All you need to be careful about is to launch them into the 2 public subnets of your VPC accurately and use the security group and IAM roles that you previously created.
For a NAT instance to perform network address translation, you got to disable source/destination checking on each of those instances. Once you do this, create 2 EIPs or if you already have EIPs that are free, associate each of the NAT instances with EIPs.
Cool! Now you have your NAT instances all set and ready.
For those who are not sure how to go about it, we have Appendix D for you. Go through it and you will do this in a jiffy.
Next comes the process of actually designating your subnets as private and public.
Step 4: Creating and associating route tables with your subnets.
Now that your Amazon EC2 NAT instances are configured with EIPs, you can create route tables and rules for the private subnets to send Internet-bound traffic through these NAT instances.
When you used the wizard to create your VPC, by default your subnets are shunned outbound internet access except for the one subnet that was automatically public (as you chose “VPC with one public subnet only”).
For your VPC’s private subnets to reach the Internet, route their traffic through your NAT instances in the public subnets. And for the other subnet that you want as public, associate it with the internet gateway that you have for your VPC.
Don’t hesitate to have a look at Appendix E for a step by step procedure to get done with route table creation.
If you are done, rejoice as now you have almost come to the end of it. Now all you need to do is download and install. That’s quite easy ain’t it?
Step 5: Download this PDF file to configure your instances with the shell script.
Follow instructions in Script.pdf and you are done with configuring HA for NAT instances in your VPC
Congratulations! You now have successfully provided your VPC with 2 NAT instances and have leveraged bidirectional monitoring between them to implement a high availability (HA) failover solution for network address translation (NAT).
So set your imagination ablaze and Stay tuned to a lot more from us!