Hello and welcome to this lecture, where I shall explain the fundamentals of AWS routing and take a look at the route tables themselves. Routing provides a mechanism to allow network packets to be forwarded to the correct destination. Within a VPC, this is all configured via routing tables associated to your subnets which use virtual routers that are fully managed by AWS.

This means you do not need to provision or configure any routers. When you create a new VPC an implicit router will be linked to your VPC as a part of your VPC creation process. If you remember from a previous lecture regarding VPC subnets, the first host IP address available within each subnet is always reserved to enable routing functionality for that subnet.

In addition to the implicit router linked to your VPC a default route table, known as the Main Route Table, is also created for your VPC. This Main Route Table cannot be deleted, however it can be customized by adding or removing routes to it. When you create a new subnet, this Main Route Table will be implicitly associated to it, unless you specify an alternate custom route table.

Remember, there has to be an associated route table for all subnets and a subnet can only have one route table association at any one time, although multiple subnets can all use the same root table. The Main Route Table will therefore act as the route table for any subnet that does not have a custom route table associated.

Let me now show you what a route table looks like and how to configure it. I'll start by looking at an example of a default Main Route Table from within the Management Console. When any new route table is created it will contain data around five components, these being a summary, routes, subnet associations, route propagation and tags.

The summary pane shows just a few details, unlike the summary pane for the subnets which contained a lot more information.

The route table ID is issued automatically which is prefixed with rtb, which stands for route table. In this example, it's been set to rtb-31bc7256. Similarly with the subnet ID, VPC ID and NACL ID, they're all referenced when using the CLI tools to perform specific programmatic commands.

The explicitly associated with section shows how many subnets are explicitly associated with this route table. Subnets can either be explicitly or implicitly associated to a route table, and we'll cover more on this when I come to subnet associations.

The main defines if this route table is the Main Route Table for the subnet and it will either be set to yes or no.

As we know, the Main Route Table will act as the route table for any subnet that does not have an explicit associated route table. The Main Route Table of a VPC can be updated and customized, but another route table can also take over as the Main Route Table. For example, you may have your Main Route Table set with a specific configuration which acts as an implicit association to many subnets within your VPC.

However, you want to change the routing of the Main Route Table without causing disruption and potential issues. So how would you achieve this? To start with, you would leave your Main Route Table serving implicit associations to those subnets using it. Next you would create a custom route table. You would then add the relevant routes that you need for the new Main Route Table to this newly created custom route table. Next you would explicitly associate that route table to a single subnet. And this subnet would then be using the new route table and not the Main Route Table. After this you would then test and confirm the routing would work as expected. And then from within the Management Console select route tables from the VPC Dashboard, select the newly created custom route table and then click on Set as Main Route Table and confirm the message.

This would then successfully act as the new Main Route Table for your VPC. You could then delete the old route table if it was no longer required.

Remember, you always have to have a Main Route Table within your VPC, but it doesn't always have to be the same one that was created when the VPC was.

Lastly within the summary the VPC section simply shows which VPC this route table resides in, which is defined by the VPC ID and tag name.

Let's now take a look at the routes tab. The routing pane shows the actual routing decisions that are made and this is where the routing of the network is defined. The table itself is comprised of four columns.

Destination, the destination field shows the CIDR block ranges for any network that you need to route to, outside of your current subnet.

Target, the target field provides the gateway to allow you to get to that destination. For example, if you wanted to route back to your own on-premise network, you could have a destination field of 192.168.0.0/16 with a target pointing to your virtual gateway, your VGW. This virtual private gateway is the gateway between your AWS VPC and a VPN connection back to your corporate network.

The status field will show you the status of your routes within the table, for example, Active. Propagated, the propagated field will define which routes within the route table are propagated. I will cover more on route propagation later in this lecture. So, to reiterate, the destination points to the network you need to route to and the target provides the gateway for doing so.

You may have noticed that from this example Main Route Table that it comes with a pre-configured route. This route will have a destination value the same as your VPC CIDR block, with a target set to local. This is an important route and one that exists for every route table that is created. What this route does is to allow all subnets within your VPC to route to each other.

It provides a path from every subnet to every other subnet. The route does not have to be created manually, it is automatically created when you create any route table and it cannot be deleted. As by default and by design, AWS allow routes to and from all of your subnets within your VPC.

Now just because you have this local route that enables a known route and pathway between all subnets does not mean that a subnet that does not have an Internet gateway attached can access the Internet by knowing the route to a subnet that does.

The subnet has to have its own route to a gateway to be able to use it. If you have a lot of rules within your route table you can perform some basic level filtering by using the drop down list above the routes in the table. Here you can filter on all rules within the table, just IPv4 rules or just IPv6 rules.

To modify the routes within the table you must edit the route table using the Edit button. Here you can then add another route by entering the destination and target fields. The status and propagation fields are automatically determined. You can also remove any routes that you no longer need by selecting the cross in the remove field, but notice that you cannot delete the local route.

Like I mentioned previously, when a subnet is created it has to have an associated route table, and by default the Main Route Table will be associated implicitly to that subnet. If then a custom route table is associated to that subnet, replacing the implicit association of the Main Route Table, then that route table will become an explicit association to that subnet.

From this example we can see that there are no explicit subnet associations to this route table, as it states: 'You do not have any subnet associations'. And you'll generally find that when looking at the Main Route Table, simply because of the implicit nature that the Main Route Table has. We can also see any subnets that do not have any explicit associations, which are listed at the bottom of the route table.

If we compare this example to another route table that is not the Main Route Table, we can see a difference. This route table does have explicit subnet associations and these are listed as subnet B and subnet S. This means that these two subnets are not using the Main Route Table, instead they are explicitly connected to this route table.

However, again, like the Main Route Table, we can see the subnets that are implicitly associated to the Main Route Table, and you will always see any subnets associated to the Main Route Table and all root table subnet associations. The IPv4 CIDR and IPv6 CIDR fields will simply show the corresponding CIDR blocks for each subnet listed.

The route propagation pane allows you to enable propagation against any virtual private gateways that you have attached to your VPC. Once you enable route propagation with a selected virtual private gateway then routes representing your VPN connection will be added to your route table automatically and will be identifiable by being listed as Yes in the propagated field of the routing table.

Lastly, the tags tab provides the same function as it did with subnets, it allows you to add any custom key value pairs to help with the tagging of your route table. In this example, I added a name of Main Route Table.

That brings us to the end of this lecture. Next I want to talk to you about routing priorities and how these are managed.