Last year we posted a blog entry that posed one of the real world dilemmas associated with running highly available NAT instances inside AWS. For quite a few years now, AWS’ customers have been requesting a managed solution to this that didn’t require standing up and monitoring EC2 instances. And now it’s here !
So what exactly was the problem ? By default, in AWS, a server can only have access to an external network (eg. the internet) if it is launched in a public subnet and/or has an external Elastic IP (EIP) address and can directly route to an internet gateway. Backend servers may need to establish outbound network connections to receive updates or connect to an external webservice, but putting these servers in a public subnet is not best practice. Instead, they should proxy their connection via a NAT instance. Up until now, NAT instances needed to be manually configured and made to be highly available to ensure business continuity.
With the recent release of AWS’ NAT Gateway this issue has now been resolved.
Following Jeff Bar’s blog, we tried AWS NAT Gateway today. The setup is really simple. Instead of firing up a NAT instance from a community AMI, you can simply create a NAT Gateway from the VPC console or CLI. After that, making sure that route tables have the correct settings is the last step of the whole process. However, there are few more things that users need to be aware before you following Jeff’s introduction. It’s a fairly obvious prerequisite that an Internet gateway must be present prior to the creation of the NAT gateway, otherwise, the NAT Gateway creation process will fail. Although, it’s not a big issue to restart the whole process, getting everything ready before starting is always the better option.
The following diagram is the basic architecture of a VPC with a NAT Gateway.
So should everyone use it ? For medium to large scale installations where there is an absolute requirement to have guaranteed bandwidth and high available NAT, this new service is definitely worthwhile. However, the pricing of the NAT gateway does not make it a no brainer for everybody. Unlike an Internet gateway that exists as a redundant service inside a VPC, a NAT gateway must be created in each subnet (and AZ) that requires an outbound connection. Users are billed on hourly usage as well as for data transfer and data processing. The entry point pricing is $0.045USD per hour which puts it reasonably close to an m3.medium EC2 instance once you factor in the additional data processing charges. For smaller projects, or projects that don’t have a critical reliance on outbound traffic, it can be quite common to use t2.micro (or even the new t2.nano) EC2 instances in a NAT capacity. Whilst we certainly don’t recommend using t2.micros or t2.nanos in critical production environments, they definitely represent a more cost effective option for the lower tier.