5.4 Routing Policies - Lab

Previous5.3 Setup Our EC2 Instances - Lab Next6. Databases on AWS

Last updated 4 years ago

Was this helpful?

5.4 Routing Policies - Lab

Route53 Routing Policies

Simple (round robin to choose an ELB)
Weighted (can be used in A/B testing during switch from old site to new site)
Latency (based on end users, how they get fastest performance)
Failover (when production site has failed health check, DR site comes online)
Geolocation (based on end users, )

Simple Routing policy

This is the default routing policy when you create a new record set. This is most commonly used when you have a single resource that performs a given function for your domain, for example, one web server that serves content for the website.

Steps:

Go to AWS console and go to Route53.
Click hosted zone. We have our hosted zone created when we registered the domain name "hellocloudgurus.com" in the previous lecture.
Click the registered domain name. You will see two record sets: NS (Name Service) and SOA (Start Of Authority) by default. The NS record has multiple top level domain names because we need redundancy, so if one of the domain name goes down it will not affect others. What we need to do now is to link this DNS record to our EC2 instances.
Click Create Record Set. In the right hand side, give a name in the front of "hellocloudguru.com", for example, "www.". If you don't write anything, it will be a naked domain name so you do want a Alias in this case. The Alias Target could be the DNS domain name of one of the ELBs you created in last lab (We could select the ELB which has two EC2 instances behind it), so when you send request to this naked domain name, the request will be directed to the selected ELB. Select Simple as the Routing Policy and click Create. You can also enable Evaluate Target Health if you want.
Now you can see there are 3 types of records, they are NS, SOA, and A. The A record is just an alias and it is pointing to the DNS name of the ELB. So every time somebody wants to go to "hellocloudgurus.com" that is going to point them to the DNS name of the ELB. Remember that ELB does not have IP address which is managed by Amazon so you can only resolve an ELB by going to its DNS name.
To visit the two web servers installed on the two EC2 instances which are behind the ELB, you just need to type "hellocloudgurus.com" in URL and hit enter. Essentially, the DNS is resolving to the ELB. The ELB here just use Round Robin to direct the request to web server #1 or #2, so you get equal possibility to be directed to web server #1 or #2.

Weighted Routing Policy

Route53 is a global service, it doesn't matter you are in Sydney Region or London Region. It is very similar to IAM, because if you create new users, they are global users.

Steps:

Go to Route53 and click hosted zones. Go into "hellocloudgurus.com", and delete the A record you created in last lab.
Create Record Set. Let the Name to be blank so let it to be a naked domain name.
The Alias Target could be one of the ELBs you created in last lab (We could select the ELB which has two EC2 instances behind it).
Select Weighted as the Routing Policy, and set a weight, for example 70.
Create another Record Set. All same as before, the difference is just to set the Alias Target to be the other ELB which has one EC2 instance behind it and set the weight to be 30.
For now there are two A records.
To visit the web servers, you just need to visit "hellocloudgurus.com", and the request will get 70% possibility to be directed to the first ELB (then round robin to be directed to one of the EC2 instances, this is thanks to ELB, not Route53), and get 30% possibility to be directed to the second ELB.

Latency Routing Policy

Latency based routing allows you to route your traffic based on the lowest network latency for your end user (i.e. which region will give them the fastest response time).

To use latency based routing you create a latency resource record set for the Amazon EC2 (or ELB) resource in each region that hosts your website. When Amazon Route53 receives a query for your site, it selects the latency resource record set for the region that gives the user the lowest latency. Route53 then responds with the value associated with that resource record set.

Steps:

Go to Route53 and click hosted zone. Go into "hellocloudgurus.com".
Delete the A records you created in last lab.
Click Create Record Set. In the right hand side, leave the name blank. Select Alias and the Alias Target could be the first ELB.
Select the Routing Policy to be Latency. Select the Region, which should be the Region of the selected ELB. Give a name to set the ID. Click Create.
Do the above steps again, and select the second ELB as the Alias Target. You also need to set the Routing Policy, Region and Set ID. Click Create.
For now there are two A records.
To visit the web servers, you just need to visit "hellocloudgurus.com". Route53 will direct your request to the ELB which has a lower latency.

Failover Routing Policy

Failover routing policy are used when you want to create an active/passive set up. For example, you want your primary site to be in EU-WEST-2 and your secondary DR Site in AP-SOUTHEAST-2.

Route53 will monitor the health of your primary site using a health check.

A health check monitors the health of your end points.

Steps:

Delete the A record you created before.
Go to the ELB for your primary site (London). Copy the DNS name of the ELB, go to Route53, go to Health Checks, create Health Check, give a name to the health check and select endpoint as what to monitor, select to specify endpoint by domain name, paste the DNS name of the ELB to the "Domain name" of the "Monitor an endpoint". In this way, if the ELB or the two instances behind it go down, this health check is going to fail.
You can set the request interval to be fast which is 10 seconds, (standard is 30 seconds). So this health check will go fail within 10 seconds of the site going down. Leave everything else as default and click Next.
We don't create Alarm for this health check, so just click create health check.
Go to create another health check which will check the health of the whole site, so select to specify endpoint by domain name and the domain name should be "hellocloudgurus.com". The Path could be "index.html". Select the request interval to be Fast. Click Next.
Create Alarm. Send notification to New SNS topic. The topic you can call it MyWebSiteGoesDown, and give an email address. Click Create.
For now we have two health checks. But the whole site health check could be unhealthy for now, this is because you have not A record set in the "hellocloudgurus.com" hosted zone yet.
Go back to Hosted Zones. Go to "hellocloudgurus.com". Click Create Record Set. Leave name as blank and select Alias. The Alias Target could be the primary website's ELB (London), which is the first ELB. Change the Routing Policy to be Failover. Select the Failover Record Type to be Primary. Select Evaluate Target Health and select Associate with Health Check. In the Health Check to Associate, you could choose the health check for the ELB of the primary site (London). Click Create.
Click Create Record Set again. Leave name as blank and select Alias. The Alias Target could be the secondary website's ELB (Sydney), which is the second ELB. Change the Routing Policy to be Failover. Select the Failover Record Type to be Secondary. Don't select Evaluate Target Health and select Associate with Health Check, set them as No. In the Health Check to Associate, you could choose the health check for the ELB of the secondary site (Sydney). Click Create.
To visit the web servers, you just need to visit "hellocloudgurus.com". When there is no failures in the primary site, you could see it is the London web server #1 or #2. When there is a failure in the primary site, for example, you stop the two instances behind the first ELB in London, the health check will shows that the first ELB (London) health check is unhealthy. You still could see it is the Sydney web server when you visit "hellocloudgurus.com", so the whole site health check is still healthy, so you will not receive an email that notify you the entire site is down.

Geolocation Routing Policy

Geolocation routing lets you choose where your traffic will be sent based on the geographic location of your users (i.e. the location from which DNS queries originate). For example, you might want all queries from Europe to be routed to a fleet of EC2 instances that are specifically configured for your European customers. These servers may have the local language of your European customers and all prices are displayed in Euros.

Steps:

Go to Route53 and go to hosted zones and go into "hellocloudgurus.com". Delete the A records of last lecture.
Create Record Set. Leave it as a naked domain name. Select Alias and the Alias Target could be the first (London) ELB.
Select Geolocation as the Routing Policy and the Location is where your end users are located (select Europe). Give a Set ID and leave all other things as default. Click Create.
Create another Record Set. Leave it as a naked domain name. Select Alias and the Alias Target could be the second (Sydney) ELB.
Select Geolocation as the Routing Policy and the Location is where your end users are located (you can select Default, it means everywhere else, so all the users who are not from Europe will visit the Sydney site). Give a Set ID and leave all other things as default. Click Create.
For now there are two A records. One geolocation is EU, the other is asterisk which means everywhere else.

Exam Tips

The latency and geolocation routing policies depend on end users, and use IP addresses of end users to determine where the users are. So you can use VPN to simulate multiple users from different locations and test the routing policy.
ELB never has an IPv4 address, it is always just got a DNS name. You resolve to ELB using a DNS name. That would of course still need to resolve to IPv4 address in the end, but Amazon handle it. You can never have a public IP address for an ELB. Something like "resolve the DNS record to the IPv4 address of ELB" is always an incorrect answer.
Understand the difference between an Alias Record and a CNAME. Remember an Alias record acts sort of like a CNAME except you could resolve individual AWS resources, for example, you can resolve ELB, CloudFront distributions. If you are given a choice in any exam question to choose between an Alias record and a CNAME, always choose an Alias record over CNAME, because in most scenarios you are going to be resolving to an AWS resource.
Remember the 5 different routing policies and their use cases.
If you are using Route53 for a static web site hosted in S3, the S3 bucket name must be the same as the domain/subdomain name. For example, if you want to use the subdomain "acme.example.com", the name of the bucket must be "acme.example.com".

An example of Route53 + ELB + EC2 + Auto-scaling

Actually in this diagram, there can be another ELB which is in another Region and has some EC2 instances behind it, so the Route53 can route to both of them.

Previous5.3 Setup Our EC2 Instances - Lab Next6. Databases on AWS

Last updated 4 years ago

Was this helpful?

Route53 Routing Policies

Simple (round robin to choose an ELB)
Weighted (can be used in A/B testing during switch from old site to new site)
Latency (based on end users, how they get fastest performance)
Failover (when production site has failed health check, DR site comes online)
Geolocation (based on end users, )

Simple Routing policy

Steps:

Go to AWS console and go to Route53.
Click hosted zone. We have our hosted zone created when we registered the domain name "hellocloudgurus.com" in the previous lecture.
Click the registered domain name. You will see two record sets: NS (Name Service) and SOA (Start Of Authority) by default. The NS record has multiple top level domain names because we need redundancy, so if one of the domain name goes down it will not affect others. What we need to do now is to link this DNS record to our EC2 instances.
Click Create Record Set. In the right hand side, give a name in the front of "hellocloudguru.com", for example, "www.". If you don't write anything, it will be a naked domain name so you do want a Alias in this case. The Alias Target could be the DNS domain name of one of the ELBs you created in last lab (We could select the ELB which has two EC2 instances behind it), so when you send request to this naked domain name, the request will be directed to the selected ELB. Select Simple as the Routing Policy and click Create. You can also enable Evaluate Target Health if you want.
Now you can see there are 3 types of records, they are NS, SOA, and A. The A record is just an alias and it is pointing to the DNS name of the ELB. So every time somebody wants to go to "hellocloudgurus.com" that is going to point them to the DNS name of the ELB. Remember that ELB does not have IP address which is managed by Amazon so you can only resolve an ELB by going to its DNS name.
To visit the two web servers installed on the two EC2 instances which are behind the ELB, you just need to type "hellocloudgurus.com" in URL and hit enter. Essentially, the DNS is resolving to the ELB. The ELB here just use Round Robin to direct the request to web server #1 or #2, so you get equal possibility to be directed to web server #1 or #2.

Weighted Routing Policy

Weighted Routing Policy allows you to split your traffic based on different weights assigned. For example, you can set 10% of your traffic to go to US-EAST-1 and 90% to go to EU-WEST-1. This can also be used in A/B testing to test a new website to see how much traffic load it can handle.

Route53 is a global service, it doesn't matter you are in Sydney Region or London Region. It is very similar to IAM, because if you create new users, they are global users.

Steps:

Go to Route53 and click hosted zones. Go into "hellocloudgurus.com", and delete the A record you created in last lab.
Create Record Set. Let the Name to be blank so let it to be a naked domain name.
The Alias Target could be one of the ELBs you created in last lab (We could select the ELB which has two EC2 instances behind it).
Select Weighted as the Routing Policy, and set a weight, for example 70.
Create another Record Set. All same as before, the difference is just to set the Alias Target to be the other ELB which has one EC2 instance behind it and set the weight to be 30.
For now there are two A records.
To visit the web servers, you just need to visit "hellocloudgurus.com", and the request will get 70% possibility to be directed to the first ELB (then round robin to be directed to one of the EC2 instances, this is thanks to ELB, not Route53), and get 30% possibility to be directed to the second ELB.

Latency Routing Policy

Latency based routing allows you to route your traffic based on the lowest network latency for your end user (i.e. which region will give them the fastest response time).

Steps:

Go to Route53 and click hosted zone. Go into "hellocloudgurus.com".
Delete the A records you created in last lab.
Click Create Record Set. In the right hand side, leave the name blank. Select Alias and the Alias Target could be the first ELB.
Select the Routing Policy to be Latency. Select the Region, which should be the Region of the selected ELB. Give a name to set the ID. Click Create.
Do the above steps again, and select the second ELB as the Alias Target. You also need to set the Routing Policy, Region and Set ID. Click Create.
For now there are two A records.
To visit the web servers, you just need to visit "hellocloudgurus.com". Route53 will direct your request to the ELB which has a lower latency.

Failover Routing Policy

Failover routing policy are used when you want to create an active/passive set up. For example, you want your primary site to be in EU-WEST-2 and your secondary DR Site in AP-SOUTHEAST-2.

Route53 will monitor the health of your primary site using a health check.

A health check monitors the health of your end points.

Steps:

Delete the A record you created before.
Go to the ELB for your primary site (London). Copy the DNS name of the ELB, go to Route53, go to Health Checks, create Health Check, give a name to the health check and select endpoint as what to monitor, select to specify endpoint by domain name, paste the DNS name of the ELB to the "Domain name" of the "Monitor an endpoint". In this way, if the ELB or the two instances behind it go down, this health check is going to fail.
You can set the request interval to be fast which is 10 seconds, (standard is 30 seconds). So this health check will go fail within 10 seconds of the site going down. Leave everything else as default and click Next.
We don't create Alarm for this health check, so just click create health check.
Go to create another health check which will check the health of the whole site, so select to specify endpoint by domain name and the domain name should be "hellocloudgurus.com". The Path could be "index.html". Select the request interval to be Fast. Click Next.
Create Alarm. Send notification to New SNS topic. The topic you can call it MyWebSiteGoesDown, and give an email address. Click Create.
For now we have two health checks. But the whole site health check could be unhealthy for now, this is because you have not A record set in the "hellocloudgurus.com" hosted zone yet.
Go back to Hosted Zones. Go to "hellocloudgurus.com". Click Create Record Set. Leave name as blank and select Alias. The Alias Target could be the primary website's ELB (London), which is the first ELB. Change the Routing Policy to be Failover. Select the Failover Record Type to be Primary. Select Evaluate Target Health and select Associate with Health Check. In the Health Check to Associate, you could choose the health check for the ELB of the primary site (London). Click Create.
Click Create Record Set again. Leave name as blank and select Alias. The Alias Target could be the secondary website's ELB (Sydney), which is the second ELB. Change the Routing Policy to be Failover. Select the Failover Record Type to be Secondary. Don't select Evaluate Target Health and select Associate with Health Check, set them as No. In the Health Check to Associate, you could choose the health check for the ELB of the secondary site (Sydney). Click Create.
To visit the web servers, you just need to visit "hellocloudgurus.com". When there is no failures in the primary site, you could see it is the London web server #1 or #2. When there is a failure in the primary site, for example, you stop the two instances behind the first ELB in London, the health check will shows that the first ELB (London) health check is unhealthy. You still could see it is the Sydney web server when you visit "hellocloudgurus.com", so the whole site health check is still healthy, so you will not receive an email that notify you the entire site is down.

Geolocation Routing Policy

Steps:

Go to Route53 and go to hosted zones and go into "hellocloudgurus.com". Delete the A records of last lecture.
Create Record Set. Leave it as a naked domain name. Select Alias and the Alias Target could be the first (London) ELB.
Select Geolocation as the Routing Policy and the Location is where your end users are located (select Europe). Give a Set ID and leave all other things as default. Click Create.
Create another Record Set. Leave it as a naked domain name. Select Alias and the Alias Target could be the second (Sydney) ELB.
Select Geolocation as the Routing Policy and the Location is where your end users are located (you can select Default, it means everywhere else, so all the users who are not from Europe will visit the Sydney site). Give a Set ID and leave all other things as default. Click Create.
For now there are two A records. One geolocation is EU, the other is asterisk which means everywhere else.

Exam Tips

The latency and geolocation routing policies depend on end users, and use IP addresses of end users to determine where the users are. So you can use VPN to simulate multiple users from different locations and test the routing policy.
ELB never has an IPv4 address, it is always just got a DNS name. You resolve to ELB using a DNS name. That would of course still need to resolve to IPv4 address in the end, but Amazon handle it. You can never have a public IP address for an ELB. Something like "resolve the DNS record to the IPv4 address of ELB" is always an incorrect answer.
Understand the difference between an Alias Record and a CNAME. Remember an Alias record acts sort of like a CNAME except you could resolve individual AWS resources, for example, you can resolve ELB, CloudFront distributions. If you are given a choice in any exam question to choose between an Alias record and a CNAME, always choose an Alias record over CNAME, because in most scenarios you are going to be resolving to an AWS resource.
Remember the 5 different routing policies and their use cases.
If you are using Route53 for a static web site hosted in S3, the S3 bucket name must be the same as the domain/subdomain name. For example, if you want to use the subdomain "acme.example.com", the name of the bucket must be "acme.example.com".

An example of Route53 + ELB + EC2 + Auto-scaling

Actually in this diagram, there can be another ELB which is in another Region and has some EC2 instances behind it, so the Route53 can route to both of them.