AWS Routing 101
Introduction
AWS makes routing simple by abstracting the complex configuration required when configuring hardware routers, and only requiring users of the platform to manage simple routing tables with a few fields. AWS’ underlying infrastructure handles the rest. That being said, there are still several different options for routing which need to be considered and then configured, based on the size and complexity of your AWS environment.
This post will cover the following topics:
- Route Table Basics
- Routing between subnets inside of a local VPC
- Routing between multiple VPCs (VPC Peering)
- Routing to the public internet (0.0.0.0/0)
- Routing via VPN connection to an on-premise network
Route Table Basics
In a general sense, a route table tells network packets which way they need to go to get to their destination. Route tables are managed by routers, which act as “intersections” within the network — they connect multiple routes together and contain helpful information for getting traffic to its final destination. Each AWS VPC has a VPC router. The primary function of this VPC router is to take all of the route tables defined within that VPC, and then direct the traffic flow within that VPC, as well as to subnets outside of the VPC, based on the rules defined within those tables.
Route tables consist of a list of destination subnets, as well as where the “next hop” is to get to the final destination.
The router knows how to get to either EC2 instance based on a request’s IP address which is then matched up to the routing table to determine the quickest route.
A route table within AWS may contain values similar to the following table. Throughout the rest of this post, the sections will help to clarify what the values in the below table mean.
Routing between subnets inside of a local VPC
By default, each VPC comes with 1 route table pre-configured with a “local” route. The scope of the “local” route is only within the subnet defined for the entire VPC. For example, if your VPC was set up to have the address space of 172.16.0.0/16, your “local” route would be defined as “172.16.0.0/16”. This allows all of the resources created within the VPC to talk to each other without any additional configuration. You cannot delete the “local” route from your route table, and anytime a new route table is created within a VPC, the “local” route is included by default.
Within a VPC, route tables are assigned to individual subnets. With only 1 route table created in a VPC, all of the subnets would be assigned to that route table. You can create multiple route tables in a VPC, or you can leave the 1 default route table.
Configuration options:
A single route table for the entire VPC
This can be used for simple environments where there are only public subnets which are all pointing to the single VPC internet gateway, and require no more complex routing rules. As is displayed below, there is only 1 route table which sits in the VPC and connects to each subnet.
1 route table per subnet
In this scenario, each subnet has 1 route table assigned, and there is a 1 to 1 relationship between route tables and subnets within the VPC. Using this method causes more management overhead and increases the amount of changes needed whenever there is a routing change to implement across the environment. This is generally used in more complex routing scenarios. In the diagram below, you can see there are 6 subnets and 6 route tables, one for each subnet.
2-tier routing tables (1 for public subnets, and 1 for private subnets)
For environments that are broken apart into public and private subnets, it is best practice to have 1 route table for public subnets, and 1 route table for private subnets.
In this scenario, you will need to further separate your route tables into availability zones, as well. The reason for this is: you will want systems in AZ A to use a NAT gateway and any other systems which are also within that AZ; same for systems in AZ B. This ensures that if one availability zone becomes unavailable, the systems in the other availability zone are not relying on a system that is now non-functional. The diagram below shows this configuration.
Routing between multiple VPCs (VPC Peering)
In larger AWS deployments, there may be more than 1 VPC. This is generally used as a way to add an additional level of separation between environments, rather than just using different subnets. For example, you might have 1 VPC for production environments, 1 VPC for testing and staging environments, 1 VPC for development environments, and 1 VPC for management services which will be leveraged by all of the other VPCs. In this case, all of your 3 application environment VPCs would need to have some way to connect and route to the management VPC where services such as Chef, Git, Active Directory, etc. will be housed. While you can set up a VPN connection between VPCs, that adds more complexity than is necessary in this situation. To solve this, Amazon offers VPC Peering. VPC Peering allows you to request a peering connection with another VPC in your own account, or within another Amazon account, and then route between those VPCs by simply adding routes to the route tables. Note that, in order for this to work, the subnets in each VPC must not overlap.
In order to enable connectivity between VPCs, you must initiate the peering connection from one VPC, and then accept the request on the other VPC. Once the connectivity has been accepted and established, a new route needs to be added to each route table, in each VPC, for the peering connection. This is done by adding a route with the other VPC’s CIDR range as the Destination, and then thepcx ID of the peering connection as the Target. At this point, connectivity is established between the VPCs, and traffic is routeable between the resources in both.
In the above diagram, you can see the same subnet and route table configuration in each VPC, but note that the CIDR is different for each VPC. Through VPC peering, the resources in VPC1 are able to connect and route to the resources in VPC2.
Routing to the public internet (0.0.0.0/0)
In order for the resources within your VPC to reach the public internet, the “gateway of last resort” (0.0.0.0/0) needs to be defined and pointed to either a NAT Gateway or an Internet Gateway.
When to use an Internet Gateway
The internet gateway (IGW) is what allows the VPC to reach the public internet. It allows devices which already have a public address, and are placed in a public subnet, to connect directly to the internet. There is only 1 internet gateway per VPC.
Once the internet gateway is configured and attached to your VPC, you must have a route within each public subnet defined with the Destination CIDR as: 0.0.0.0/0, and a Target of: igw-########, which is the ID of the internet gateway. Once you have hooked up your IGW, your public resources will be able to connect to the internet. Having the NAT gateway (explained below) in a public subnet, which routes to the internet gateway, is what allows that device to transmit traffic from the private subnets to the internet.
When to use a NAT Gateway
Because a private subnet contains only resources with private IP addresses, these devices have no way to reach the internet by themselves, so they need a little help. This is where the NAT gateway comes in. A NAT (Network Address Translation) gateway is what facilitates internet access for resources sitting in a private subnet in a VPC. The NAT gateway (NGW) is placed in a public subnet within the VPC and given a public IP address. This allows the NGW to connect through the internet gateway to the public internet and translate the private addresses of the resources in the private subnets into a public address that can be used to connect to the outside internet. The NAT gateway facilitates that connection and remembers where to route traffic back to the source private IP addresses within the VPC.
In order to allow this type of connectivity, the route table associated with each subnet much have a route defined with the Destination CIDR as: 0.0.0.0/0, and a Target of: ngw-########, which will be the ID of the NAT gateway. Note that it is best practice to create 1 NAT gateway within the public subnet of each availability zone, and then point the route tables in AZ A to the NGW created in AZ A; same concept for AZ B.
In the diagram above, you can see the peered VPCs from the previous scenario now have 1 internet gateway per VPC, and 1 NAT gateway per availability zone. The private subnets route 0.0.0.0/0 to the NAT gateway. The public subnets route 0.0.0.0/0 directly to the internet gateway.
Routing via a VPN connection to an on-premise network
In the case of enterprise deployments on AWS, where connectivity is required back to an on-premise datacenter, a VPN connection can be configured. To establish VPN connectivity, there are 3 primary components which need to be set up in AWS:
- Customer Gateway: the customer gateway is where you configure the address of the on-premise VPN device. This should be a public facing address on the VPN device within your on-premise datacenter.
- Virtual Private Gateway (VPG): the virtual private gateway is the component that sits on the edge of the VPC, allowing VPN connectivity to come in and out of the VPC. The VPG sits at the same level as the internet gateway.
- VPN Connection: the VPN connection puts it all together by connecting the customer gateway to the rest of the VPC network through the virtual private gateway. Within the VPN connection, you see the status of the 2 Tunnels configured for connectivity back to the on-premise network. Within the VPN Connection is where the routes back to the on-premise network are configured to allow the rest of the route tables within the VPC to be able to find the resources within the datacenter.
Once the 3 pieces above are configured, the VPN tunnels within AWS will show a status of UP and VPN connectivity will be available. Ensure that route propagation is turned on in each of your route tables, so that the routes configured on the VPN Connection will be available to all of the route tables within the VPC.
In the above diagram, you can see the VPN Gateway added to the edge of the VPC and routing through the Public Internet in order to connect with the Customer Gateway in the customer’s on-premise datacenter.
Putting It All Together
Through the configuration of the above routing scenarios, whether independently or in conjunction with each other, you will have a functioning VPC network where traffic can be routed without issue to wherever its final destination is.
For additional information about Route Tables on AWS, visit the VPC Route Table user’s guide.
