Welcome back to BackSpace Academy. In this lecture on route 53, we already know 2
what route 53 is, we've registered a domain name before, we've set up a public 3
hosted zone, but we're going to go into a lot more detail into the features of 4
route 53. We'll look at not only public hosted zones but private hosted zones 5
where we can create a domain name specifically for inside of our VPCs 6
we'll look at different types of routing policies which is where the true power 7
of route 53 comes in and we'll look at how we can use that to reduce the 8
latency and increase the availability of our infrastructure and finally we'll 9
have a look at route 53 traffic flow and that is a visual interface for route 53. 10
Route 53 it's a highly available and scalable cloud domain name system web service 11
you're going to pay only for the hosted zones that you set up and the 12
number of queries that route 53 responds to. Route 53 it has three main functions 13
the first being domain name registration. You can not only register new domains 14
with AWS but you can also transfer domains from AWS to outside by AWS and 15
from outside of AWS with another registrar back into AWS if you require 16
You can route internet traffic to the resources that are for your domain 17
You can have public and private hosted zones so not only can you have a domain name 18
for Internet traffic coming in. You can also set up an internal domain name for 19
your private traffic within your VPCs. There are multiple routing policies 20
that are available and this is where the true strength of route 53 comes in. 21
You can route your requests based on latency to get them the quickest 22
response to requests. It can be based on geographic location or you could 23
distribute requests to different resources based on a weighted round 24
robin and finally we can check the health of our resources, which is very 25
important for ensuring high availability. So if one of our resources goes down, 26
we can have the DNS service or route 53 to fail over to another set of resources. 27
Now we have already used the domain name service with AWS. We've already created 28
or purchased a domain name in the past, so we know that it automatically creates 29
that hosted zone for that domain name for us. We also know that once we've 30
purchased that domain name and we've received our confirmation notification 31
we can start adding resource record sets to that. Privacy protection is included 32
by AWS by default for Whois queries and you can transfer that domain to another 33
AWS account by simply contacting AWS support and, if you no longer want to use 34
AWS route 53 for your domain name you can transfer that to another registrar 35
other than AWS, again by simply contacting AWS support. Hosted zones are 36
collections of resource record sets for our specific domain. Public hosted zones 37
which we've used before. It defines the domain and subdomain routing for our 38
internet outside traffic. AWS automatically creates our name server 39
and start of authority records for us and we just add our other records to 40
that being our A or Cname or MX or whatever that may be. We can also set up 41
a private hosted zone and that can define a domain and subdomain routing 42
for traffic within one or more of our virtual private clouds. 43
Private hosted zones allow you to specify a domain name that you can use 44
for communication between your private resources within your VPC. 45
Now that domain name it can be anything you want you don't have to register it because 46
it's only going to be used within your private resources within your VPC 47
now you specify the VPCs that you want to associate with that private hosted zone 48
and when an EC2 application running inside of that VPC 49
makes a request to that domain name, route 53 will return the corresponding 50
IP address for that domain name. To set that up you need to set enableDNShostnames 51
and enableDNSsupport in your VPC settings. Now before Amazon Aurora 52
came along with its load balancing capabilities, we had no way of load balancing 53
requests to multiple RDS instances and so what we did in the past 54
is that we would create a private hosted zone with a domain name for that 55
private hosted zone that would direct traffic to our multiple RDS read replicas based on 56
a weighted round robin policy and that way our applications could send traffic 57
to one endpoint and then the RDS Route 53 service would look after distributing 58
that to multiple RDS instances. 59
Routing policies are where the true power of route 53 comes in. We've used 60
simple routing policies before, where we just got a single resource that we're 61
directing traffic from the wider Internet to, but there are also failover 62
routing policies that we can use to create high availability where we can 63
have health checks that can trigger a failover to a backup set of resources in 64
the event that there is a problem with those resources. We can have weighted 65
routing policies that can distribute traffic to multiple resources on a weighting 66
so 10% of our traffic could go to one resource and 90% could go to another 67
we have multi-value answer routing where we can distribute our 68
traffic to multiple resources. We have latency routing policies that can allow 69
us to distribute traffic depending on the location of our end user. That is 70
going to provide the lowest latency for that response. We can have geolocation 71
routing policies which we can define continents and countries and direct 72
traffic based upon the location of that request based on its location or 73
continent. We can also have geo proximity routing and that is only for the traffic 74
flow service which is a visual interface for route 53 but that allows us to 75
define an area within the AWS infrastructure and if that request is 76
located within that area it will be directed to a certain resource for that area 77
a failover routing policy will check the health of our resources and 78
failover to a backup set of resources when they become unresponsive. The health checks 79
can monitor an endpoint if it becomes unresponsive, they can also be 80
triggered from Cloudwatch alarms but they can also monitor other health 81
checks for example if you wanted to maintain a minimum of resources 82
There are two types of failover strategy. You can have active 83
and active where your traffic will be routed to unhealthy or healthy resources 84
based upon those health checks or, you can have active and standby where you 85
have a standby set of resources, for example a static site or a backup site 86
that's just sits there not being used but is available if a health check has failed 87
and traffic will be routed to that standby set of resources. 88
With a weighted routing policy you can associate multiple resources with that single 89
domain or subdomain name and choose how much traffic is routed to each one of 90
those resources. The way it works is that you will select a weight from 0 to 255 91
and the percentage of traffic that goes to each one of those resources will be 92
its weight divided by the sum of all of the weights. If the weight is 0 for all 93
of the records then that traffic is routed to all of those resources with 94
equal probability. You can't use aliases for your records and as we said before 95
it's quite useful as a simple load balancer and for example in the past 96
when we didn't have Amazon Aurora we could use it to load balance requests to 97
RDS read replicas, but it's also very good at reducing the risk when we're 98
rolling out new software version releases. So for example we might have a 99
new software version that we want to release to our our large number of end users 100
so to minimize the impact of that new software version if there's any issues 101
we can release it to only 10% of those requests and then we can slowly 102
increase it to 10 20 30 until we're more confident that there's no issues with 103
that new software. Multi-value answer routing is useful when you're creating 104
more than one record of the same name and type and when you're routing traffic 105
to multiple resources and you would like to have 106
a health check associated with those records. Route 53 will respond to 107
requests with up to eight healthy records that are selected at random and 108
returned to your end user and your end users operating system will select 109
one of those healthy records to connect with. If you don't associate a 110
health check with a record it will be considered to be healthy and it will 111
direct traffic to it. If you have eight or less healthy records route 53 will 112
respond with only the healthy records, but if you have no healthy records then 113
it will respond with up to eight unhealthy records. There are limitations 114
on the values for your records you can't use an alias you can't use a cname either 115
so let's have a look at an example here. We've got multiple 116
resources there for a single domain name so there we've got www example com 117
it's an A record and we have multiple values for those multiple endpoints for those 118
resources and so we've also got multiple health checks for those endpoints there 119
A, B and C and what we do is that we give that record set an ID web1, web2, web3 120
and with a multi-value policy or multi value answer policy route 53 121
we'll distribute at random traffic to those multiple resources if they are healthy. 122
Latency routing policies are useful if your application is hosted in multiple 123
AWS regions and you want to get the lowest latency for your end user 124
depending on where they're located. The way it works is that you create 125
latency records for your resources. Route 53 it will keep data on 126
latency from different locations for all of its regions and then it uses that 127
data to return the IP address in a region based on 128
that Route 53 latency data for that request's location and that way the end user 129
is going to get the best low latency response to their request. 130
A geolocation routing policy will allow us to direct traffic to different resources 131
based on the geographic location of that request. The way it works is that we will 132
select a continent or a country and we will allocate or associate a resource to 133
that continent or country. Now those codes are from ISO 3166 134
country codes. To handle requests for countries or continents that you haven't 135
included in your routing policy, you can create a default record but, it's very 136
important to remember that you should have a default record because if you 137
don't create one, Route 53 will return a no answer response for queries from 138
those locations that aren't covered by a continent or country in your geolocation 139
routing policy. Geoproximity routing policies are similar to geolocation 140
routing policies in that they allow you to route traffic to your resources based 141
on the geographic location of that user, but the difference is that you can 142
specify a bias to change the size of that specific region. You can increase it 143
or decrease it by defining a number from 1 to 99 or decrease it from minus 1 to 144
minus 99., To use geo proximity routing you need to use it with Traffic Flow and 145
we'll talk about traffic flow in the next slide. Let's have a look at how 146
geoproximity routing works. On the left there we've got a Geoproximity map of 147
different coverage areas here that have the bias unchanged. We can see there - 148
we've got one that covers the majority of the 149
US East North Virginia and on the right there we can see that the number two 150
area in pink has been given a positive bias that has expanded the area to cover 151
all of South America and going up north there as well 152
So that's how we can modify where our requests go within that AWS global infrastructure 153
Route 53 traffic flow is a visual interface for designing and 154
implementing complex configurations that use a combination of multiple policies. 155
This greatly simplifies the process of creating these very complex 156
configurations because we can visualize them and see exactly how they work. 157
Once you've created one you save it as a traffic policy once you've done that you 158
can then associate it with a domain or a subdomain name,. You can use it with 159
multiple hosted zones but those hosted zones must be public zones 160
It can't be used with private zones. So that brings us to an end to our 161
discussion on route 53 I hope you've enjoyed it and I look forward to seeing 162
you in the next one.