1 00:00:06,870 --> 00:00:11,670 - The most commonly used elastic load balancer 2 00:00:11,670 --> 00:00:16,670 deployment mode is the ALB or application load balancer. 3 00:00:17,650 --> 00:00:19,440 Now, this load balancer 4 00:00:19,440 --> 00:00:20,840 is a little different than the others 5 00:00:20,840 --> 00:00:25,040 in that it only operates at Layer 7 6 00:00:25,040 --> 00:00:27,830 of the seven-layer OSI model, 7 00:00:27,830 --> 00:00:30,810 which is the application layer. 8 00:00:30,810 --> 00:00:34,920 It is designed to accept inbound traffic. 9 00:00:34,920 --> 00:00:38,883 It can be internet-facing or internal only, 10 00:00:40,010 --> 00:00:45,010 and you can attach one or more TLS certificates to it 11 00:00:45,150 --> 00:00:50,090 so that it can accept HTTPS for different domains 12 00:00:50,090 --> 00:00:51,553 on the same load balancer. 13 00:00:53,150 --> 00:00:56,530 It also allows for a little bit of intelligence. 14 00:00:56,530 --> 00:00:59,450 You can figure out how to route requests 15 00:00:59,450 --> 00:01:03,600 based on the properties of the request itself 16 00:01:03,600 --> 00:01:05,420 using path-based routing 17 00:01:05,420 --> 00:01:09,403 and then deliver those requests to different locations. 18 00:01:11,040 --> 00:01:13,080 It also supports redirects. 19 00:01:13,080 --> 00:01:15,410 So if you wanna create a redirect engine 20 00:01:15,410 --> 00:01:19,133 with 301 or 302 redirects, you can do that. 21 00:01:20,900 --> 00:01:23,630 And it's one of the few services 22 00:01:23,630 --> 00:01:26,120 that is supported by the AWS WAF 23 00:01:26,120 --> 00:01:28,970 or Web Application Firewall service 24 00:01:28,970 --> 00:01:32,610 that allows you to filter or block requests 25 00:01:32,610 --> 00:01:34,693 if they don't meet certain criteria. 26 00:01:37,030 --> 00:01:39,500 There are a number of good use cases 27 00:01:39,500 --> 00:01:41,250 where the application load balancer 28 00:01:41,250 --> 00:01:44,170 is the appropriate one to choose. 29 00:01:44,170 --> 00:01:46,300 If you have stateless web applications 30 00:01:46,300 --> 00:01:48,800 where you have a number of backend resources 31 00:01:48,800 --> 00:01:51,833 that are performing identical work in a stateless fashion, 32 00:01:52,860 --> 00:01:54,460 it is worth considering the ALB. 33 00:01:56,220 --> 00:02:00,224 Even if you have stateful application servers, 34 00:02:00,224 --> 00:02:04,453 the ALB does support stickiness if you want to configure it. 35 00:02:06,350 --> 00:02:10,160 And really, any web-based application 36 00:02:10,160 --> 00:02:13,620 that is using HTTP or HTTPS requests 37 00:02:13,620 --> 00:02:16,463 could be a good candidate for this load balancer. 38 00:02:17,500 --> 00:02:21,210 So let's take a look at an example of where a feature 39 00:02:21,210 --> 00:02:24,570 called TLS Certificate Smart Selection 40 00:02:24,570 --> 00:02:25,923 can be really important. 41 00:02:27,050 --> 00:02:30,180 In this example, I have two target groups 42 00:02:30,180 --> 00:02:32,830 that are attached to the same load balancer. 43 00:02:32,830 --> 00:02:37,740 One of them is running ECS task containers 44 00:02:37,740 --> 00:02:41,370 and the other is an auto-scaled group of EC2 instances 45 00:02:41,370 --> 00:02:43,223 and they perform two different tasks. 46 00:02:44,780 --> 00:02:49,780 I have two certificates attached to my load balancer, 47 00:02:50,000 --> 00:02:52,940 both of them provisioned through the ACM 48 00:02:52,940 --> 00:02:55,700 or AWS Certificate Manager Service, 49 00:02:55,700 --> 00:02:57,093 for two different domains, 50 00:02:57,093 --> 00:03:01,063 *.brightkey.cloud and *.brightkeycloud.com. 51 00:03:02,040 --> 00:03:06,390 Now, our end user issues a request using HTTPS 52 00:03:08,010 --> 00:03:09,940 and then www.brightkeycloud.com 53 00:03:11,100 --> 00:03:15,110 and that through path-based routing can be delivered 54 00:03:15,110 --> 00:03:18,000 to the auto-scaling group of EC2 instances 55 00:03:18,000 --> 00:03:23,000 and say this is our main website and dynamic pages. 56 00:03:23,060 --> 00:03:27,520 And the ALB automatically picks the correct certificate 57 00:03:27,520 --> 00:03:29,320 based on the domain and the request. 58 00:03:31,350 --> 00:03:34,473 And when it is time to log into the website, 59 00:03:35,580 --> 00:03:37,420 the client issues a request 60 00:03:37,420 --> 00:03:41,563 to https://login.brightkey.cloud. 61 00:03:42,510 --> 00:03:44,800 And through path-based routing, that is delivered 62 00:03:44,800 --> 00:03:48,940 to the ECS containers instead for authentication 63 00:03:48,940 --> 00:03:52,030 and that also uses the correct certificate 64 00:03:52,030 --> 00:03:54,580 so that there's no browser warning 65 00:03:54,580 --> 00:03:56,193 because of a mismatched domain. 66 00:03:58,150 --> 00:04:02,623 The ALB supports up to 25 TLS certs. 67 00:04:04,910 --> 00:04:06,530 So we've talked a little bit 68 00:04:06,530 --> 00:04:10,820 about how we can route our requests 69 00:04:10,820 --> 00:04:12,630 based on their properties. 70 00:04:12,630 --> 00:04:15,453 That's called path-based routing. How do we do it? 71 00:04:16,900 --> 00:04:19,280 Through listener rules. 72 00:04:19,280 --> 00:04:22,270 Each listener that you create on your load balancer 73 00:04:22,270 --> 00:04:27,180 has an ordered list of rules that you can create and manage. 74 00:04:27,180 --> 00:04:30,850 And these listener rules are going to have a condition type 75 00:04:30,850 --> 00:04:33,100 associated with each rule. 76 00:04:33,100 --> 00:04:36,640 And this would be the property of the request 77 00:04:36,640 --> 00:04:40,810 that you use to determine where you're going to route it. 78 00:04:40,810 --> 00:04:43,200 And there's a number of options here: 79 00:04:43,200 --> 00:04:48,020 the host-header, the http-header, the request-method, 80 00:04:48,020 --> 00:04:51,320 the path-pattern, the query-string, 81 00:04:51,320 --> 00:04:53,140 and this last one is important, 82 00:04:53,140 --> 00:04:57,893 you can even filter based on the source-ip. 83 00:04:58,770 --> 00:05:01,030 Now, once you've done that, you gotta figure out 84 00:05:01,030 --> 00:05:02,500 what you're gonna actually do with the request 85 00:05:02,500 --> 00:05:04,970 and you have a number of options here too. 86 00:05:04,970 --> 00:05:08,350 You can authenticate the request 87 00:05:08,350 --> 00:05:11,173 against another AWS service called Cognito. 88 00:05:12,490 --> 00:05:14,170 You can authenticate the request 89 00:05:14,170 --> 00:05:18,393 against any open ID-compatible identity provider. 90 00:05:20,130 --> 00:05:24,290 You can return a static response that could be text or HTML. 91 00:05:24,290 --> 00:05:26,563 It just has to be a static string. 92 00:05:28,260 --> 00:05:30,510 You can issue a 301 or 302 93 00:05:30,510 --> 00:05:33,993 to redirect to some other location. 94 00:05:36,070 --> 00:05:39,810 You can forward the request to a target group, 95 00:05:39,810 --> 00:05:43,143 and this is how most of the actual work is gonna get done. 96 00:05:44,330 --> 00:05:45,380 But that's not all. 97 00:05:45,380 --> 00:05:48,590 You can actually forward to more than one target group 98 00:05:48,590 --> 00:05:52,360 and you can configure weights between them, 99 00:05:52,360 --> 00:05:55,000 which makes for a really elegant way 100 00:05:55,000 --> 00:05:58,350 of performing a blue-green deployment. 101 00:05:58,350 --> 00:05:59,860 If you are upgrading 102 00:05:59,860 --> 00:06:03,150 from one version of an application to another, 103 00:06:03,150 --> 00:06:07,290 you can gradually change those weights to shift the traffic 104 00:06:07,290 --> 00:06:09,623 from one target group to the other.