Tag Archives: NAT

High Availability for AWS VPC NAT instances


The Background

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.

NAT with no HA

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 ?

NAT on Failure

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.

NAT HA

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 –
  1. An Amazon VPC.
  2. 2 Linux Amazon EC2 NAT instances.
  3. Any number of instances that you would want to have in the private and public subnets.
  4. EIPs (Elastic IPs) for the instances in the public subnet.
  5. Route tables that would allow the NAT instances to act as mediators.
  6. 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!

{
“Statement”: [
{
“Action”: [
“ec2:DescribeInstances”,
“ec2:CreateRoute”,
“ec2:ReplaceRoute”,
“ec2:StartInstances”,
“ec2:StopInstances”
],
“Effect”: “Allow”,
“Resource”: “*”
}
]
}

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).

There are no rules for architecture for castles in the cloud”.

So set your imagination ablaze and Stay tuned to a lot more from us!

Links

Appendix A- Creation of an Amazon VPC

Appendix B-Creating a Security Group for the NAT instances

Appendix C-Creating an IAM role for the NAT instance

Appendix D-Getting your NAT instances ready

Appendix E-Creating routing tables for the VPC

Script.pdf- The script for configuration

Reference

http://aws.amazon.com/articles/2781451301784570

Extending AWS NAT instance utilization – Part 1


For those of us who have been through setting up VPC(Virtual Private Cloud) in AWS know the need to have a NAT instance running. Since we have to keep this instance running as long we need the easy internet access from instances running in Private subnets, had always wondered how else can this instance be utilized. In reality these NAT instance are doing a outward Port Address Translation from internal Private Subnet instances to external Internet.

Typical NAT Server in AWS:

NAT-Server

NAT-Server-1

While, there are those who may argue that the NAT instance better be left alone, we believe there are ways to extend the abilities without noticeable impact of the primary utility. Typically, NAT instance that is provisioned using AWS wizard allows you to choose between small / medium instance types. After providing for the need for the Internet access for your private subnet instances (read in most typical use cases), there is enough time cycles which we can take advantage off.

Note: In addition to above, as we know NAT instance will have an Elastic IP assigned (VPC type), which is a scarce resource (limited to 5 by default, and you need to request for more to Amazon). This gives one more reason to utilize an instance with EIP(Elastic IP) to best use.

Let us see a few of them which we were able to successfully harness, to our clients and for our needs here at CloudKinetics.

Extension-1: PAT (Inward Tunnel): enable access to specific port – instance in Private subnet from Internet

At first it seems appalling to have a direct access to an instance running in Private subnet from internet (as the very purpose of Private subnet is to avoid direct access from internet), it is not uncommon to this scenario, when you have VPC but no VPN configured and say a DB Server running in the private subnet. 

In the above scenario, if we need to access the DB Server(in Private Subnet with in VPC) from a Toad or other SQL clients from the enterprise / home network to quickly do a sql query, then we need a direct access. Alternative would be to run such clients from with in another instance with in the VPC. Nevertheless it is always convenient to run those from our own laptop / desktop from work. Though we want to enable to this access, but need to ensure it is restricted to only this instance and to a specific port and from a specific external IP(or range of IPs).

Let us assume we have an Oracle on RHEL running in our VPC in the Private Subnet, which is primarily accessed by other Application instance inside VPC.  If you have need to run some porting scripts or intializing DDL scripts from the client, need to have access to Oracle running in Private subnet (say 10.0.1.*) open port 1532 @ 10.0.1.123 from Enterprise public IP (xxx.xxx.xxx.110)

It is a three-step process,

a) Getting the IPTABLES update command ready

b) Updating the IPTABLES service in NAT configuration to ensure retaining configuration after restart.

c) Open the required port in the NAT Server SecurityGroup

By Default the AWS NAT ami implements the Outward PAT ability through IPTABLES service. The configurations to the service are updated on startup from /usr/local/sbin/configure-pat.sh

Edit this file as root and find the line as below

/sbin/iptables -t nat -A POSTROUTING -o eth0 -s ${VPC_CIDR_RANGE} -j MASQUERADE

Update to look as below to include the additional two lines for allowing the access from external internet to Db Server (10.0.1.123: 1532).

 /sbin/iptables -t nat -A POSTROUTING -o eth0 -s ${VPC_CIDR_RANGE} -j MASQUERADE && \
 /sbin/iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 51532 -j DNAT --to 10.0.1.123:1532 && \
 /sbin/iptables -A FORWARD -p tcp -d 10.0.1.123 --dport 1532 -j ACCEPT

Please take care to add the “&& \” to the existing MASQUERADE command line.

NAT-Server-PAT

Now, time to reboot the server. With the above step we have configured the port 51532 in the NAT Server to be open to Internet, which in turn will do a Port Address Translation to send it to port 1532 of the local VPC Private subnet instance 10.0.1.123.

To restrict and open the access from our Enterprise IP Address to the NAT Server on port 51352, need to configure the NATServerGroup (or the Security Group assigned to NAT Server) as below.

NAT-Securitygroup

That is it, we have now enabled the NATServer to do an inward Port Address Translation. We can extend this to other instances / ports as required.  Also the above steps can be automated by using simple shell scripts.

Final-SecurityGroup

Reference:

IP Tables: http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables

In the next parts we will cover other possible extensions, as listed below:

Part 2 on Extension-2: NFS (Network File Storage) – Shared drive for VPC instances (and Enterprise)

Part 3 on Extension-3: SFTP Server for File upload