Creating and maintaining connectivity for the resources in your private AWS subnets can be tricky and expensive. AWS’ new managed NAT Gateway is a great alternative.
Good news for all the folks working in the AWS VPC environment: the managed NAT gateway is here. I have been working in the AWS cloud for a long time and one of the most common requirements for the applications I’ve deployed is providing Internet connectivity from resources in a VPC’s private subnet. For those unfamiliar with how this works, let me briefly describe it.
Security is (or at least should be) king in AWS cloud, and the most important security tool is a properly designed VPC (Virtual private cloud):
Amazon Virtual Private Cloud (Amazon VPC) lets you provision a logically isolated section of the Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.
For more background on VPCs, take Cloud Academy’s AWS VPC Networking course.
A typical VPC setup is made up of public and private subnets. The EC2 instances deployed in private subnet of VPC cannot access the Internet because you cannot assign them a public IP. But if your application servers, sitting in a private subnet, need to talk to the Internet (to interact with S3 or some third party gateway, for instance), you need NAT (Network Address Translation) to make it happen.
What we used to do is to create a NAT instance in the public subnet of the VPC and open communication with private subnet instances via NAT through VPC Routing tables. So what is the problem? Why are we all so excited about this new Managed NAT Gateway?
Performing this kind of translation at scale can be challenging. Moreover, providing higher availability through more than one NAT instance across two Availability Zones can be expensive. Consider the traditional, two-zone design:
Now imagine that one of those NAT instances goes down. You’ll need to have all the automated scripts configured and ready to redirect communication from the private instances within one Availability Zone to the NAT instance in the other one. And the more instance and AZs you’re running, the more complicated things get.
But using AWS’s new Managed NAT Gateway, things work differently. Instead of configuring, running, monitoring, and scaling a cluster of EC2 NAT instances, it’s a matter of couple of clicks and you are all set. In short, all the configurations that were once the responsibility of the developer or the Ops team, will now be handled invisibly by AWS. Developers can relax just a bit and concentrate more on their application development.
What you need to know about the AWS Managed NAT Gateway
Just as you would with any new AWS features, it only makes sense that we spend some time getting to know each other a bit better. The Managed NAT Gateway…
- Has built-in redundancy for high availability.
- Can handle up to 10 Gbps of bursty TCP, UDP, and ICMP traffic, and is managed by Amazon.
- Can be used in US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) regions (as of the time of writing).
- Pricing starts at $0.045 per NAT gateway hour plus data processing and data transfer charges. Refer Amazon VPC pricing to get more details on this.
- Can be associated with a Security Group.
- Can be controlled suing the command line or API.
- Can be used with VPC flow logs to capture/analyze the traffic flowing through the NAT gateway.
- Cannot be accessed by a ClassicLink connection associated with your VPC.
- Cannot send traffic over VPC endpoints, VPN connections, AWS Direct Connect, or VPC peering connections.
Let’s try to see how we can create and configure an AWS NAT Gateway:
- Login to the AWS console, select VPC service and click on NAT Gateways as shown below:
- Provide the necessary details, like subnet and Elastic IP, and create the NAT Gateway. You need the select the subnet which you want to be private subnet and your Elastic IP so that it can communicate to Internet.
- Once created you will see this:
- Once the NAT Gateway is created you can edit your routing table to send traffic destined for the Internet toward the gateway. The gateway’s internal address will be chosen automatically, and will be in the same subnet as the gateway.
Once the NAT Gateway is configured, you are all set. Your private subnet instances should now be able to communicate with the Internet without much management, monitoring, and configuration overhead.
Sample NAT Gateway architecture:
Migrating from an existing NAT instance
If you are already using a NAT instance in your VPC setup, it’s time to migrate now, and I can tell you that it’s not tough. You only need to make sure that you create the NAT Gateway in the same subnet as your existing NAT instance. Then you need to edit the route table by replacing the existing NAT reference with the internal address of the new gateway. I told you this was very straightforward. You will need to ensure that you don’t have any critical tasks running at the time of migration, because changing a route from a NAT instance to the gateway can result in a dropped connection.
This feature was only very recently introduced by AWS, so it’s definitely worth sharing. It can resolve lots of existing concerns. Do you have your own experience with this new feature? Why not share it with others.