In part 1, we covered some of the basics of the VPC. In this article, we will cover some of the more advanced topics

Let’s dig in 👍

Network Address Translation

While you can put things straight on the internet within a VPC, it is likely only a good idea if you have a specific architectural requirement. Reducing the attack surface is always a good idea with any deployment in AWS. AWS provides us with another option to establish connectivity to the internet: NAT.

Network Address Translation (NAT) maps (translates, hence the name) multiple private addresses inside our local VPC subnets to a public IP address before transferring the information to the Internet. This public IP address is associated with the NAT device.

Using this technique, we remove the need to assign public IP addresses to our instances to gain internet access.

This now introduces the concept of Public / Private subnets.

Public/Private Subnets

A subnet is public if it has a route to the Internet Gateway in the VPC.

A subnet is private if it has no route to the Internet Gateway or has a route to a NAT device.

NAT Gateways

An AWS NAT Gateway is a highly available, managed service within AWS that allows instances in a private subnet to connect to the Internet or other AWS services while preventing the Internet from initiating connections with those instances.

NOTE: NAT Gateways have an hourly and a data transfer charge. Keep this in mind if you are testing them out or transferring large amounts of data through them.

NAT gateways are created within a specific Availability Zone; however, they are redundant within that zone. As a managed service, you don't have to restart it if there is an issue with it.

This means that to provide redundancy across availability zones, you will provision a NAT GW per Az.

Each NAT GW will be assigned a Public Elastic IP address, and this is the IP that will be used as the source for the external communication.

Other than providing access to the Internet, as a managed service from AWS, each NAT gateway automatically scales bandwidth up to 45 Gbps, meaning one less thing to manage from a performance perspective. AWS provides metrics via Cloudwatch for throughput, errors, and connection count.

NOTE:- A full list of metrics is available at https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway-cloudwatch.html

As with all AWS managed services there is no need for patch management, route table modifications, or software updates with a NAT gateway. AWS manages these tasks, simplifying network administration.

NAT Instances

An AWS NAT (Network Address Translation) Instance is an EC2 instance configured to provide NAT services for instances within a private subnet in an Amazon VPC (Virtual Private Cloud).

As the name implies, unlike a NAT Gateway, a NAT instance is a self-managed resource. You have control over the instance size and configuration. This comes with some more configuration overhead but can be more attractive from a pricing perspective.

To provision a NAT instance, you will need to choose the EC2 instance type, configure network settings, associate an Elastic IP address, and manage security groups. AWS does provide the Amazon Machine Image (AMI) however.

Unlike the NAT Gateway, you will also have to monitor the NAT Instance's bandwidth and performance and apply software patches and updates.

Route 53 Resolver

Machines and humans communicate using different methods. While machines rely on IP addresses, humans prefer using names. However, without DNS, communication between IP addresses and names becomes impossible.

The Route 53 Resolver is a magic service within each VPC that translates domain names into IP addresses, enabling resources to connect to the intended destination.

NOTE It used to be named Amazon DNS server, so you may still see references to it in the console or documentation.

In part 1, we introduced CIDR Blocks. The Route 53 Resolver lives as the .2 address of the first CIDR Block allocated to the VPC. For the Default VPC in any AWS account, this will be 172.31.0.2, i.e., VPC+2 IP address.

Now, I said it was magic because you don't have to configure a security group rule to allow your resource to access it; AWS takes care of it automatically.

If we were using an EC2 instance on a public subnet and wanted to get to https://blog.awsfundamentals.com it would flow as follows:-

1. The browser on the EC2 instance performs a DNS query for blog.awsfundamentals.com via the resolver address at x.x.x.2

2. The Route 53 resolver queries internet-based DNS servers for the ip to name mapping

3. The Internet-based DNS servers return the IP address 76.76.21.21 to the Route 53 resolver

4. The Route 53 Resolver returns the IP address 76.76.21.21 to the EC2 instance

5. The browser on the EC2 instance makes a request to 76.76.21.21 through the Elastic IP via the Internet Gateway

6. blog.awsfundamentals.com returns the webpage content to the EC2 instance

As this is a managed service as part of the VPC, the .2 address is accessible from all availability zones, so you don't need to worry about availability.

If you want to adjust this magic, then you can configure the DHCP Option Set for the VPC. This will allow you to override this behaviour and target another set of DNS servers.

Flow Logs

As things grow, there will be a time when you need to troubleshoot your security groups, Network Access lists, and other communication either within a VPC or across multiple VPC.

Flow logs can be enabled on the whole VPC, a specific subnet or group of subnets or at the interface level.

Enabling flow logs will capture the network communication going on for the resources it is applied to. It will contain information such as source ip, destination ip and port but also a lot of other details that can be found in the documentation

Example flow log entry

2 458173604507 eni-03afde5cbe8e61868 10.123.114.28 10.123.114.20 3341 36406 6 3 132 1709915568 1709915569 ACCEPT OK

Flow logs can be configured to send the data to S3, Cloudwatch of Kinesis. If you intend to configure alerts, Cloudwatch would be preferred, or S3 for longer, cheaper retention. Kinesis would likely be used to centralise to a specific logging account or other tool such as Splunk.

NOTE:- Even if you choose S3 you can still query your logs via AWS Athena

Summary

In this article, we have discussed some more of the fundamental concepts related to AWS Virtual Private Cloud. As you progress in your AWS journey and begin to manage multiple systems, your VPCs will grow along with your AWS Accounts.

In part III of this series, we will delve into connecting multiple VPCs, sharing resources, and establishing on-premise connectivity.

Check out the AWS Fundamentals VPC infographic here! that can be used as a reference.