In this lecture, we'll be discussing static and dynamic routing in AWS. When using static routing, it is your responsibility to manually update routing tables with all the routes needed to get your traffic to the correct destinations. When using dynamic routing, we installed dynamic routing protocols on our routers that automatically swap network information. The routers then use this network information to build their routing tables. When there is a network change, such as adding a new VPC in AWS or adding new networks on-premise, then the route is using the dynamic routing protocol, swap this information and use it to update their route tables. When you think about static routing, think manual updates of route tables. 

When you think about dynamic routing, think automatic updates of route tables. Although there are lots of dynamic routing protocols that you can use on your own networks when using dynamic routing in AWS, we use the Border Gateway Protocol, BGP, as our dynamic routing protocol. Your on-premise routers that you'll be using to connect to AWS, must support BGP if you wish to use dynamic routing. Lots of organizations work in hybrid environments, with users working at their site, so at home, and organizations might have some servers on-premise as well as having services deployed to AWS. These users and on-premise servers might need to access VPC resources hosted in AWS. This is a hybrid environment and requires hybrid connectivity. In AWS, hybrid connectivity is provided by Site-to-Site VPNs or Direct Connect. When configuring a Site-to-Site VPN, you can use either static or dynamic routing. 

When configuring Direct Connect, you must use dynamic routing. Whether setting up a Site-to-Site VPN or Direct Connect, you need to configure the following: A Customer Gateway and a Virtual Private Gateway or a Transit Gateway. Customer Gateways are used to provide configuration information, specifically, configuration information about your on-premise device that you'll be configuring at your site to connect to AWS Site-to-Site VPN or Direct Connect. Here's an example of a Customer Gateway configuration. We can see the BGP ASN. ASNs are autonomous system numbers. ASNs identify a group of IP networks that are under the control of a single entity or organization. Amongst other things, the ASN is used by BGP to establish a neighbor relationship between BGP-enabled routers. This is required so that BGP routers can swap information needed to build their respective route tables. 

Be aware that the ASNs we used to create Site-to-Site VPNs or Direct Connect connections need to be different on each side of the connection. Here we have chosen a private ASN number of 65001. This is the ASN configured on the on-premise router. The IP address of the on-premise device. This is the public IP address of our on-premise device that AWS will establish the connection with. The certificate is on. If we want to use certificate authentication for our endpoints, we select a private certificate that the on-premise device must trust. Now that we have a Customer Gateway, we should configure a Virtual Private Gateway or a Transit Gateway to connect our VPCs to our Site-to-Site VPN or Direct Connect. With the Customer Gateway and Virtual Private Gateway in place, we can now create our VPN connection. Here we can see the VPN connection information. 

Notice we have selected the appropriate Virtual Private Gateway, selected the appropriate Customer Gateway, selected static routing and inputted a static IP prefix. The static IP prefix is used to identify the networks that exist on-premise. Here we have a single entry of 192.168.0.0/16. You can add all the prefixes that match all of your on-premise networks. Once the VPN connection is configured, we need to add the static IP prefixes to our VPC route tables. Remember, this is static routing, so you are responsible for keeping the route tables up to date. Good news though. VPCs have a propagate route feature that can be found on your route tables. Here's an example. We are on the propagation tab. Notice the name of the Virtual Private Gateway this route table is using and that propagation is set to yes. By default, propagation is set to no. You can change the status of propagation by selecting 'edit route propagation'. But what does propagation mean?

Well, take a look at this route table that's propagation set to no. Here we can see the local route and a default route using a NAT Gateway. Here is the same route table with propagation set to enabled or yes. You can see an extra route to 192.168.0.0/16. Our static IP prefix for our on premise network. In other words, when you enable propagation on route table, static prefixes that you have added to the VPN connection are automatically written to the route table. This is still static routing, we had to add the prefix the VPN connections ourselves to make routing between our VPC and on-premise network work. We are now looking at the on-premise side of this configuration, but keep in mind that the on-premise router would now need to be configured in order to bring the VPN connection up and for traffic to be routed. What would a dynamic VPN configuration look like? 

Well, very similar. Here, you can see a Site-to-Site VPN connection set to use dynamic routing. There is no need to add a static prefix as a dynamic routing protocol will automatically swap prefixes. We would still enable propagation on the route tables. Your on-premise team would now need to configure BGP to match the BGP configuration of your Site-to-Site VPN. But luckily for us, AWS will provide us with the configuration needed for most common routers. Here is a partial configuration file of a Cisco router that shows the BGP configuration. Here we can see two commands, command one, router bgp 65001. This command initializes BGP on the Cisco router. The number 65001 is the autonomous system number of the on-premise autonomous system. This number must match the AS number configured in the customer gateway configured in AWS. Command two, neighbor 169.254.111.9 remote-as 64512. This command identifies the AWS end of the relationship. 169.254.111.9 is the IPv4 address of the end of the site-to-site connection and 64512 is the AS number used by AWS for this connection. With these commands in place and the VPN or Direct Connect connection up, the two BGP devices should form a neighbor relationship and begin swapping prefixes.