Managing User Identities in AWS IAM
Managing Groups and Roles in IAM
Key Management Service (KMS)
Using Network Firewalls to secure your VPCs
Examining AWS Routing
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 course covers the core learning objective to meet the requirements of the 'Designing secure solutions in AWS - Level 2' skill
- Analyze the available options to secure credentials using features of AWS Identity and Access Management (IAM)
- Evaluate the appropriate routing mechanism to securely access AWS service endpoints or internet-based resources from an Amazon VPC
- Evaluate the appropriate encryption options available for data in transit and when at rest across AWS services
- Evaluate the most appropriate key management service and options based on business requirements and governance controls
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.