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