AWS: Enabling Internet Access to Your VPC (Part 1)
As your AWS infrastructure and requirements grow, you’ll likely want to enable internet access to/from your VPC to avoid routing traffic back through your VPN/Direct Connect to decrease latency and reduce the round trip for traffic from your VPC. AWS provides multiple ways to connect your instances to the internet and just like the physical world, some are better than others. Some options provide fast access to the internet without a lot of configuration, however, it can also reduce your ability to provide security services such as web filtering and virus protection. Other configurations can provide these higher level security services but require more configuration up front, including custom routing and a nontraditional mindset.
As Amazon Web Services continues to mature there have been multiple options which allow your instances access to the internet. When I started working with AWS back in 2011, the “easiest” way to provide internet accessibility for a public subnet wasn’t quite so easy to deploy. Amazon has since added a feature to make this slightly easier but it still requires quite a few steps to complete. Below are some of the various ways to provide internet access to your instances, all of which have their own pros & cons.
Let’s start by defining a few important pieces of this puzzle, namely services provided within a VPC:
- Internet Gateway: Scalable, redundant, and highly available component enabling communication between your VPC and the Internet. Only a single IGW can be assigned to a VPC.
- Route Table: List of routes to determine where traffic is directed. There can be a route table for every subnet or you can group multiple subnets into a single route table.
- NAT Gateway: Feature that allows Network Address Translation between a subnet and the public internet. Provides better availability, higher bandwidth, and requires less administrative overhead than the NAT Instance (see below).
- NAT Instance: NAT service providing Network Address Translation between a subnet and the public internet by way of an EC2 instance. Requires you disable source/destination checks on the NAT instance.
- Elastic IP Address: Publically accessible, static IP address which can be easily attached/detached to a resource. One EIP per instance is free but allocated EIPs that are unattached to a resource incur hourly charges. As all solutions discussed here, the use of a Elastic IP requires an Internet Gateway associated with your VPC.
Option 1 – Utilizing an Elastic IP Address
The easiest way to provide internet access, whether it’s for ingress or egress traffic, is to utilize an Elastic IP address for each instance requiring such connectivity. This requires the least amount of configuration to enable and can be a quick and easy solution if very few instances need inbound or outbound connectivity. That said, each instance with an EIP is “directly connected” to the internet with no security services outside of a security group, network access control list, or any software you’ve installed on the instance itself.
Steps to configure option 1:
- Assign Internet Gateway to your VPC.
- Configure routing table for desired subnet with a default route (0.0.0.0/0) pointing to the IGW.
- Launch instance, choosing Auto-Assign Public IP
- Alternatively, allocate a new Elastic IP address from the EC2 console and attach to an existing instance.
- For outbound access, ensure attached security group allows outbound traffic over 80 & 443 (Default is allow all outbound traffic).
- For inbound traffic, if desired, ensure attached security group allows desired ports inbound (i.e. RDP: 3389, HTTP: 80, HTTPS: 443, etc) (Default is Deny all inbound traffic)
Option 2 – Utilizing NAT Gateway for Public Subnet
Similar to on-premises infrastructure, you might have a requirement that multiple servers have internet access from the same source IP (i.e. API calls, IP restricted services, etc). Since each Elastic IP address provides a unique public address, this would be unsuitable for the requirements above and, depending on the number of instances, would be difficult to manage and could generate additional (unneeded) cost if not managed properly. As its name implies, the NAT Gateway provides the capability to provide NAT services to many resources using the NAT Gateway in its outbound path to the internet. The NAT Gateway not only provides built-in redundancy and high availability, it provides bandwidth which can burst up to 10Gbps.
An important characteristic of the NAT Gateway to remember is that it’s deployed on a single subnet…and, if you recall, a subnet is defined within a single availability zone. Therefore it’s critical to define a NAT Gateway in each of your availability zones being utilized in order to prevent a single AZ outage from stopping outbound traffic in another. Last but not least, NAT Gateways are not free, incurring a charge of $0.045/hour ($1.08/day) while in use in addition to data transfer fees of $0.045/GB.
Steps to configure Option 2:
- Assign Internet Gateway to your VPC
- Provision NAT Gateway with EIP in desired subnet (takes a minute or two to provision)
- Configure routing table used for instances with a default route (0.0.0.0/0) pointing to the NAT Gateway (listed as nat-xxxx)
- Configure routing table used for NAT Gateway with a default route (0.0.0.0/0) pointing to the Internet Gateway (listed as igw-xxxx)
- Ensure security groups allow outbound traffic over desired ports on instances
Option 3 – Utilizing NAT Instance for Public Subnet
As one of the ‘original’ solutions to provide outbound connectivity, using a NAT instance is very similar to using a NAT Gateway as described above. The biggest difference, however, is now we’re using an actual EC2 instance providing NAT services which is deployed from a Community AMI. It provides the same functionality in terms or NAT services, however, it doesn’t provide the benefits of a NAT Gateway as listed above. There is no built-in redundancy in a NAT Instance and the bandwidth is limited by the size of the instance selected, therefore most use-cases the NAT Gateway should be utilized. However, when you compare the two, the NAT Instance provides a small set of capabilites in which the NAT Gateway does not. For example, the NAT Instance supports port forwarding, CloudWatch metrics, and the ability to customize the IP address on your subnet.
Steps to configure Option 3:
- Assign Internet Gateway to your VPC
- Lauch appropriately sized NAT Instance with public IP in desired subnet (search for ‘nat’ under the Community AMI section)
- Disable Source/Destination Check by selecting the instance, choose Actions, Networking, Change Source/Destination Check
- The instance will not show up as a route target unless this is disabled.
- Configure routing table used for instances with a default route (0.0.0.0/0) pointing to the NAT Instance (listed as i-xxxxx)
- Configure routing table used for NAT Instance with a default route (0.0.0.0/0) pointing to the Internet Gateway (listed as igw-xxxx)
- Ensure security groups allow outbound traffic over desired ports on instances AND NAT Instance
But Wait….There’s More
Be sure to visit Part Two of this post to read on a few additional options that you can utilize in your AWS environment.