Creating and configuring a Virtual Private Cloud (VPC) within AWS can be a simple or difficult process. It all very much depends on the complexity of your requirements. For example, how many subnets and hosts will you require? Will you be using one VPC or peering multiple VPCs together? Do you need to establish connectivity back to your on-premise network? Do you need internet connectivity for your Private instances? These and many more questions need to be asked and answered before you start to design your VPC infrastructure.
As a part of this process, you will need to understand VPC Subnet configurations and VPC routing to ensure you architect your solution correctly and efficiently.
This AWS Virtual Private Cloud: Subnets and Routing course looks and VPC Subnets and VPC Routing in detail, providing examples of both across different configurations and solutions and how to best implement your network design.
- VPC CIDR Blocks - This lecture focuses on the effect of subnetting your VPC CIDR Block
- Why Subnet your VPC - This lecture looks at some of the reasons why you may want to subnet your VPC, by looking at the advantages and benefits
- VPC Subnets - This lecture dives into at what a VPC Subnet looks like within the Management Console and its associated components such as Network Access Control Lists (NACLs)
- Public & Private Subnets - This lecture looks at the differences between both Public and Private subnets within a VPC
- VPC Peering: Subnet Considerations - This lecture focuses on some of the considerations when architecting your subnets in different VPC Peering configurations
- Flow Logs: VPC Subnets - This lecture dives into at what a VPC Subnet looks like within the Management Console and its associated components such as Network Access Control Lists (NACLs)
- Demonstration: Creating a VPC & Subnets - This lecture provides a demonstration on how to set up and configure a VPC with both Public and Private subnets
- Routing Fundamentals & Route Tables - This lecture introduces AWS routing and its Routing tables by breaking down all the components within it
- Routing Priorities - This lecture explains how the routing priorities are defined for overlapping routes within the same route table
- Routing: VPC Peering - This lecture looks are different routing configurations for multiple VPC peering scenarios
- Routing: VPN Connection via a Virtual Private Gateway - This lecture looks at routing configurations for virtual Private Gateways
- Routing: Internet Gateways & NAT Gateways - This lecture looks at the routing configurations for both IGWs and NAT Gateways and the dependencies involved
- Routing: VPC Endpoints - This lecture looks at the automatic routing configuration when creating a VPC Endpoint
Hello and welcome to this lecture, where I want to discuss how AWS route tables manage routing priorities for overlapping routes.
A key point of understanding AWS routing, especially when it comes to troubleshooting, is to know how AWS route tables prioritizes these routes. For example, if there are overlapping destinations from a CIDR block perspective, which target should AWS use to send the traffic to?
Remember, the destination points to the network you need to route to and the target provides the gateway for doing so. The rule of thumb is that AWS will use the most precise route available within the table to route traffic to a specific destination. This is also known as the Longest Prefix Match.
For example, let's say you had four routes in your route table associated to a subnet as shown.
This subnet has its local route, like every subnet has, enabling all subnets within the VPC to route to each other. It also has an Internet gateway with a destination value of 0.0.0.0/0. Then it has two routes on the 192.168 network. So if traffic from within your subnet needed to be routed to 192.168.1.1, which route would it use?
Like I said before, the rule of thumb will be the most specific, in this instance, the last route in the table with a destination of 192.168.1.0/24 as this route has the Longest Prefix Match, even though it also falls within the boundaries of the third route. Let's look at some more examples.
So the first column shows a number of IP addresses in this example that we are trying to reach. The second column shows the potential routes that those IP addresses could use, if looked at individually. Almost all of the IP addresses could use more than one route in the table. The third and fourth columns show the example root table entries used previously. The fourth column shows the selected route for the corresponding IP address. And the final column explains the reason why that particular IP address used that route. Feel free to pause the video and take a review of this table for a few minutes.
Now there are some circumstances where the Longest Prefix Match of a route is not selected within the route table and these are important to be aware of, as they could aid with any routing troubleshooting issues that may arise.
If you have any virtual gateways attached to your VPC and have enabled propagation for those virtual gateways and these propagated routes have overlapping destinations with your VPC's local route, then your VPC local route will have precedence, even if your propagated routes across your VPN link have the Longest Prefix Match.
Also, again, if you have any propagated routes that have the same destination specified as any of your other existing static routes within your route table, then the rule of Longest Prefix Match will not be applied. Instead, the following priority is executed against any static routes that have the following gateways as their target first, the Internet Gateway, a Virtual Private Gateway, a Network Interface, an Instance ID, a VPC Peering connection, a NAT Gateway, or a VPC Endpoint.
Let me take a look at a couple of examples where these may come into play. This route table contains two routes, one is the local route for all VPC subnets and a second overlapping route that has been added through propagation via a Virtual Private Gateway. Any traffic destined to the 10.0.1.0/24 network will be routed using the local VPC route over any propagated route, even though it has the Longest Prefix Match.
Another example, in this example the root table has three routes, one that is the local VPC route, a route to the Internet Gateway, and a propagated route to the same destination as the Internet Gateway route. Just to clarify, the Internet Gateway does not always have to point to 0.0.0. 0/0 as it has done previously in this course. In some circumstances, you may only want to route to specific networks out to your Internet connection, rather than to everywhere. Any traffic that is destined for the 172.31.0.0/16 network would have the potential of using two routes. However, in this scenario, all traffic to that network would use the Internet Gateway route, as that is a static route and has precedence over any propagated route. When managing route tables, including your static and any propagated routes.
Do be aware that there are limitations on the number of routes within a VPC in any one table. Currently, there is a default limit of 200 routes per VPC, however, you can request an increase if required. For each route table you have a default of 50 non-propagated routes, with a maximum increased limit of 100.
However, if you do increase the amount of routes you may notice some degradation to your network performance. This limit is separate for both IPv4 and IPv6 addressing, meaning you can potentially have up to 100 IPv4 routes and 100 IPv6 routes. The maximum propagated route limit is fixed at 100 per route table, and this limit cannot be increased.
So far, we have looked at AWS routing, covering what routing is, the route tables themselves, subnet associations, route propagation, routing priority and limitations. In the next few lectures I want to run through some examples of how routing is configured across a range of different designs and configurations, including routing to a VPC Peered Connection, a Virtual Private Gateway, a NAT Gateway, an Internet Gateway and a VPC Endpoint.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.