Every time I get the chance, I like to write articles that are geared towards enabling you make your cloud infrastructure on AWS and other cloud platforms more secure. In today’s edition of writing about AWS services, we will be learning about NAT Gateways, what they are, how they work and how they enhance our cloud infrastructure. From NAT gateways we will finish it off by talking about VPC endpoints. Allons-y (FYI: that’s “let’s go” in French 😉)

NAT Gateways

First and foremost, NAT stands for Network Address Translation. Let’s look at what NAT really is before moving on to NAT gateways proper. Network Address Translation is a process in which private IP addresses used on a network (usually a local area network) are translated into public IP addresses that can be used to access the internet.

To understand how NAT gateways work, we are going to use the example of a two-tier architecture with a web tier deployed on EC2 instance in a public subnet (a public subnet is a subnet that has a route to an Internet gateway on the route table associated with it) and an application tier deployed on EC2 instances in a private subnet ( a private subnet has no route to an internet gateway on its route table). With this architecture, the EC2 instances that make up the application tier are unable to access the internet because they the subnet in which they reside has no route to an IGW on its route table. How will the instances go about performing tasks like downloading update patches from the internet? The answer lies in using NAT gateways. For the application tier to have access to the internet, we need to provision a NAT gateway in the public subnet housing our web tier.

When an instance in the application tier wants to connect to the internet, it sends a request which carries information such as the IP address of the instance and the destination of the request to the NAT gateway in the public subnet. The NAT gateway then translates the private IP address of the instance to a public elastic IP address in its address pool and uses it to forward the request to the internet via the internet gateway. One important thing to note about NAT gateways is that, they won’t accept or allow any inbound communication initiated from the internet as it only allows outbound traffic originating from your VPC. This can significantly improve the security posture of your infrastructure.

NAT gateways are managed by AWS. To create a NAT gateway, all you have to do is specify the subnet it will reside in and then associate an Elastic IP address (EIP). AWS handles every other configuration for you.

VPC Endpoints

VPC endpoints allow private access to an array of AWS services using the internal AWS network instead of having to go through the internet using public DNS endpoints. These endpoints enable you to connect to supported services without having to configure an IGW (Internet Gateway), NAT Gateway, a VPN, or a Direct Connect (DX) connection.

There are two types of VPC endpoints available on AWS. They are the Interface Endpoints and Gateway Endpoints

Interface Endpoints — They are fundamentally Elastic Network Interfaces (ENI) placed in a subnet where they act as a target for any traffic that is being sent to a supported service. To be able to connect to an interface endpoint to access a supported service, you use PrivateLink. PrivateLink provides a secure and private connection between VPCs, AWS services and on-premises applications through the internal AWS network.

To see the suite of services that can be accessed via interface endpoints, check out this AWS documentation.

Gateway Endpoints — They are targets within your route table that enable you to access supported services thereby keeping traffic within the AWS network. At the time of writing, the only services supported by gateway endpoints are: S3 and DynamoDB. Be sure to check the appropriate AWS documentation for any addition to the list of services. One last thing to keep in mind about gateway endpoints is that they only work with IPv4

Conclusion

Some say the mark of a good dancer is to know when to bow out of the stage. With that, we have officially reached the end of this article about VPC endpoints and NAT gateways. I will like to implore you to keep learning and getting better at using tools such as these for you don’t know when they will come in handy. That could be sooner rather than later. Thank you for riding with me to the very end. Best of luck in all your endeavors.