VPC Security and Control
Basic Networking Concepts
VPC Sharing using the AWS Resource Access Manager
Inter-Regional and Intra-Regional Communication Patterns
Understanding Direct Connect, Implementation and Configuration
Understanding AWS Direct Connect - Connectivity Options
Examining AWS Routing
DNS & Content Delivery on AWS
Managing Public and Private SSL/TLS Certificates using AWS Certificate Manager
The course is part of this learning path
Instructor: Mike Brown
Static and Dynamic Routing
In this lecture we will be discussing static and dynamic routing in AWS.
When using static routing, it is your responsibility to manually update routing tables with all of the routes needed to get your traffic to the correct destinations.
When using dynamic routing, we install dynamic routing protocols on our routers that automatically swap network information. The routers then use this network information to build their route tables. When there is a network change such as adding a new VPC in AWS or adding new networks on-premise then the routers 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 a lot 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 will be using to connect to AWS must support BGP if you wish to use dynamic routing.
Working with Static and Dynamic Routing
Lots of organizations work in a hybrid environment with users working at their sites or 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 Site-to-site VPNs or Direct Connect you will need to configure the following:
- A Customer Gateway.
- 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 will be configuring at your site to connect to the AWS site-to-site VPN or Direct Connect.
Here is 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 (Autonomous Systems) that are under the control of a single entity or organization. Amongst other things the ASN is used by BGP to establish neighbor relationships between BGP enabled routers.
This is required so that the BGP routers can swap information needed to build their respective route tables. Be aware that the ASNs we use 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 our 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 ARN - 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 connections or Direct Connect.
With the customer gateway and virtual private gateway in place we now create our VPN connection (if using a Transit Gateway you would create a VPN Attachment)
Here you can see the VPN connection information, notice we have:
- Selected the appropriate Virtual Private Gateway
- Selected the appropriate customer gateway
- Selected Static routing
- Imputed 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 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 is 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 has propagation set to No.
Here you 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 a 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 to the VPN connection ourselves to make routing between our VPC and On-premise work.
We are not looking at the on premise side of the configuration here, 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 configuration set to use dynamic routing:
There is no need to add a static prefix as the 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 the configuration needed for most common routers. Here is a partial configuration file for a CISCO router that shows the BGP configuration.
router bgp 65001
neighbor 169.254.111.9 remote-as 64512
Here we can see two commands.
Command 1: router bgp 65001
This command initializes BGP on the CISCO router, the number 65001 is the Autonomous System Number (AS) of the on-premise Autonomous System. This number must match the AS number configured in the customer gateway configured in AWS.
Command 2: 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 AWS 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.
This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the core networking concepts and services relevant to the SAP-C02 exam. We start with an introduction to the AWS Virtual Private Network (VPC) and networking services. We then understand the options available and learn how to select and apply AWS networking, DNS, and content delivery services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam.
- Get a foundational understanding of VPCs, their security, and connectivity
- Learn about VPC sharing using the AWS Resource Access Manager
- Discover inter-regional and intra-regional communication patterns in AWS
- Learn about AWS Direct Connect, along with its implementation, configuration, and connectivity options
- Understand routing in AWS, including static and dynamic routing
- Understand the basics of networking, including Elastic IP addresses, Elastic Network Interfaces, networking with EC2, VPC endpoints, and AWS Global Accelerator
- Learn about the DNS and content delivery services Amazon Route 53 and Amazon CloudFront
Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.