1 00:00:12,349 --> 00:00:16,980 Welcome back to Backspace Academy. In this lecture we're going to be talking 2 00:00:16,980 --> 00:00:22,439 about elastic load balancer in particular the ELB classic type and in 3 00:00:22,439 --> 00:00:26,250 further lectures we'll talk about the other types of elastic load balancers as well. 4 00:00:26,250 --> 00:00:31,500 To start off we'll look at how we can encrypt our traffic to and from our 5 00:00:31,500 --> 00:00:38,370 elastic load balancer using HTTPS or Secure Sockets Layer. Then we'll look at 6 00:00:38,370 --> 00:00:43,200 the automated back-end administration that we can set up with our elastic load 7 00:00:43,200 --> 00:00:48,270 balancer to make sure that everything is healthy and receiving traffic as it should. 8 00:00:48,270 --> 00:00:52,350 Then we'll look at the configuration settings that we can set 9 00:00:52,350 --> 00:00:58,410 up to have our ELB customized for our specific application. Then we'll look at 10 00:00:58,410 --> 00:01:04,229 proxy protocol which can send information concerning the client 11 00:01:04,229 --> 00:01:07,590 that is connected to our elastic load balancer and send that information over 12 00:01:07,590 --> 00:01:12,750 to our back-end instances, and why we would want to do that. Then we'll look at 13 00:01:12,750 --> 00:01:17,640 sticky sessions which can stick a session between a client that is 14 00:01:17,640 --> 00:01:22,409 connected to our ELB and our backends to make sure that they have a seamless 15 00:01:22,409 --> 00:01:27,000 session while they're connected. Then we'll look at monitoring, how we can make 16 00:01:27,000 --> 00:01:32,579 sure that our ELB is performing as it should and is healthy, and finally we'll 17 00:01:32,579 --> 00:01:39,990 look at troubleshooting steps that we can take if something goes wrong. 18 00:01:39,990 --> 00:01:44,610 SSL or secure Sockets Layer can be implemented on your elastic load 19 00:01:44,610 --> 00:01:49,590 balancer architecture and the easiest way to do that is to upload an SSL 20 00:01:49,590 --> 00:01:55,409 certificate to that ELB and associate it with that ELB and then that ELB will 21 00:01:55,409 --> 00:02:00,329 receive encrypted traffic from your connected clients. It will then decrypt 22 00:02:00,329 --> 00:02:05,850 that traffic and pass it on to your back-end instances. There are two ways to 23 00:02:05,850 --> 00:02:10,500 implement this. First of all you can use the AWS certificate manager to create 24 00:02:10,500 --> 00:02:13,890 that certificate and then you can associate 25 00:02:13,890 --> 00:02:19,110 with your elastic load balancer, or if you want up a more difficult way, and 26 00:02:19,110 --> 00:02:22,800 this is the way that we used to do it before the certificate manager came 27 00:02:22,800 --> 00:02:27,630 along, is that you can use your own certificate from a certificate authority 28 00:02:27,630 --> 00:02:33,290 and then you can upload that to the ELB yourself manually. That's a very 29 00:02:33,290 --> 00:02:36,930 complicated process and I wouldn't recommend it because it doesn't really 30 00:02:36,930 --> 00:02:43,020 provide any advantage at all. To use the AWS certificate manager what you need to 31 00:02:43,020 --> 00:02:47,520 do is go to the certificate manager console or else use one of the many 32 00:02:47,520 --> 00:02:53,040 software development kits or the command-line interface to request an ACM 33 00:02:53,040 --> 00:02:59,310 or certificate manager certificate from AWS. Once that's occurred and that 34 00:02:59,310 --> 00:03:04,410 certificate has been approved then what you can do is go to the elastic load 35 00:03:04,410 --> 00:03:08,610 balancer console, or again use one of the software development kits or the 36 00:03:08,610 --> 00:03:13,520 command-line interface, and then provision that certificate on the 37 00:03:13,520 --> 00:03:18,030 elastic load balancer. Now this certificate it must be in the same 38 00:03:18,030 --> 00:03:24,320 region as the elastic load balancer is and the user that is implementing this 39 00:03:24,320 --> 00:03:30,930 must have list certificates API permission to associate that with the 40 00:03:30,930 --> 00:03:35,820 load balancer. If you already have a certificate for your domain that you 41 00:03:35,820 --> 00:03:39,570 would like to use and you'd like to upload that and that was a certificate 42 00:03:39,570 --> 00:03:43,880 that you've got outside of AWS the process is a little bit more difficult. 43 00:03:43,880 --> 00:03:47,070 First thing that you would need to do is that you will need to install 44 00:03:47,070 --> 00:03:52,830 certificate tools and that would be open SSL or something equivalent. The next 45 00:03:52,830 --> 00:03:57,540 step is that you would need to create a server certificate and get that signed 46 00:03:57,540 --> 00:04:01,980 off by a certificate authority. So that process would involve you generating an 47 00:04:01,980 --> 00:04:08,780 RSA private key, and then creating a certificate signing request or a CSR, 48 00:04:08,780 --> 00:04:14,340 handing that over to the certificate authority to have that signed off. 49 00:04:14,340 --> 00:04:17,910 Once that's done you could upload that certificate to your elastic load 50 00:04:17,910 --> 00:04:23,340 balancer and then verify that the certificate is actually working. 51 00:04:23,340 --> 00:04:26,610 Okay so here we have an example of how it would normally work. We would have our 52 00:04:26,610 --> 00:04:29,550 client would connect into our elastic load 53 00:04:29,550 --> 00:04:36,270 balancer and they would do that on port 443 with HTTPS secure sockets layer and 54 00:04:36,270 --> 00:04:42,390 then at the ELB we would have SSL termination that would receive that 55 00:04:42,390 --> 00:04:46,650 encrypted traffic, it would decrypt it and then pass it on to the relevant 56 00:04:46,650 --> 00:04:53,370 instance on port 80 and that would be HTTP traffic that would be unencrypted. 57 00:04:53,370 --> 00:04:58,500 So the way that looks in the management console is that on the load balancer you 58 00:04:58,500 --> 00:05:02,940 you would add a listener to there and we can see there that we've 59 00:05:02,940 --> 00:05:10,320 got a listener. The load balancer protocol is HTTP the load balancer port is 443 60 00:05:10,320 --> 00:05:15,930 and then it will be decrypting that and the instance protocol that is being sent 61 00:05:15,930 --> 00:05:25,200 back out to the instances will be HTTP on port 80 there. In order for SSL to 62 00:05:25,200 --> 00:05:30,540 work between the client that is connected to the ELB and the ELB the 63 00:05:30,540 --> 00:05:36,090 client and that ELB need to negotiate on what ciphers and what protocols are 64 00:05:36,090 --> 00:05:40,770 going to be used for that connection. There is a security policy that you will 65 00:05:40,770 --> 00:05:44,610 associate with that elastic load balancer and that will be used to 66 00:05:44,610 --> 00:05:50,520 negotiate the SSL protocols that will be used. If you don't define a security 67 00:05:50,520 --> 00:05:57,150 policy then the default security policy will be defined for you. The SSL 68 00:05:57,150 --> 00:06:04,470 protocols that are supported include transport layer security 1.2, 1.1 and 1.0 69 00:06:04,470 --> 00:06:14,250 and SSL 3. If you enable server order preference as an option on your ELB that 70 00:06:14,250 --> 00:06:19,530 will enforce cipher ordering. So what that means is that both your load 71 00:06:19,530 --> 00:06:25,650 balancer and your connected client will have a list of ciphers that they can 72 00:06:25,650 --> 00:06:32,280 communicate with, and so the load balancer will select the first cipher in 73 00:06:32,280 --> 00:06:38,070 its list that will be on the clients list of ciphers. By doing that we're 74 00:06:38,070 --> 00:06:41,249 going to make sure that the security policy or the 75 00:06:41,249 --> 00:06:46,619 cipher that is used is going to be the one that we prefer. So always make sure 76 00:06:46,619 --> 00:06:53,609 that you use the latest predefined security policy and that's important for 77 00:06:53,609 --> 00:06:59,279 example, server order preference that will not be supported with the 2011 08 78 00:06:59,279 --> 00:07:03,179 security policy. So if you've got that and you're trying to implement serve 79 00:07:03,179 --> 00:07:06,899 order preference, it's just not going to work. So make sure that you always use 80 00:07:06,899 --> 00:07:11,929 the latest security policy on your ELB. 81 00:07:12,780 --> 00:07:20,340 A great advantage of using an elastic load balancer is that it automates a lot 82 00:07:20,340 --> 00:07:24,810 of the backend administration on our architecture through the use of health 83 00:07:24,810 --> 00:07:29,970 checks. So we can implement health checks, they can check whether our instances are 84 00:07:29,970 --> 00:07:34,560 healthy or unhealthy, and the different status for those is, in service and 85 00:07:34,560 --> 00:07:42,419 healthy or out of service and unhealthy. If an instance becomes unhealthy the ELB 86 00:07:42,419 --> 00:07:48,900 will stop routing traffic to it and will route it to another instance. When that 87 00:07:48,900 --> 00:07:53,400 instance becomes healthy it will be added to those healthy instances and it 88 00:07:53,400 --> 00:08:00,090 will then resume receiving traffic from the ELB. Now there is a default health 89 00:08:00,090 --> 00:08:05,490 check configuration or you can define your own custom health check. To do that 90 00:08:05,490 --> 00:08:12,300 you'll need to first define the protocol port and path to that health check, the 91 00:08:12,300 --> 00:08:18,570 response timeout for these health checks, the interval between health checks and 92 00:08:18,570 --> 00:08:24,810 also the unhealthy to healthy threshold, and that is how many consecutive fail 93 00:08:24,810 --> 00:08:30,240 health checks that will be required to bring that instance out 94 00:08:30,240 --> 00:08:35,219 of service, or it could be how many passed consecutive health checks that 95 00:08:35,219 --> 00:08:41,729 will need to bring it back into service. An ELB health check is additional to 96 00:08:41,729 --> 00:08:46,020 an auto-scaling health check that you may have implemented on your auto 97 00:08:46,020 --> 00:08:52,260 scaling group to automatically scale in and scale out the size of that group, and 98 00:08:52,260 --> 00:08:57,780 if you like you can also replace that auto scaling group health check with the 99 00:08:57,780 --> 00:09:03,750 ELB health check instead, and use the ELB health check to expand and contract that 100 00:09:03,750 --> 00:09:10,860 auto scaling group of instances. You can manage the security of your ELB 101 00:09:10,860 --> 00:09:18,540 by using an ELB security group. Now my original AWS account goes back to around 102 00:09:18,540 --> 00:09:26,370 about 2010 and back then we didn't have VPC we had something called ec2 classic 103 00:09:26,370 --> 00:09:32,069 and we shared that cloud with other users, so it wasn't as secure as it is 104 00:09:32,069 --> 00:09:38,339 now with VPC, but that said, you still need to know about EC2 classic because 105 00:09:38,339 --> 00:09:43,829 you may go into a company that has a very old account and you need to 106 00:09:43,829 --> 00:09:50,160 understand that. So if you've got an ELB operating on EC2 classic it will use a 107 00:09:50,160 --> 00:09:56,999 fixed security group for those back-end instances and the ELB. If you're using a 108 00:09:56,999 --> 00:10:01,319 current AWS account, which of course you most likely will be and, 109 00:10:01,319 --> 00:10:06,779 you're most likely putting your elastic load balancer inside of a VPC then 110 00:10:06,779 --> 00:10:10,860 you'll be creating your own security group and associating that with the 111 00:10:10,860 --> 00:10:16,559 elastic load balancer. So here we can see we've got our elastic load balancer that 112 00:10:16,559 --> 00:10:21,809 is receiving traffic from the wider internet and it's going to have an 113 00:10:21,809 --> 00:10:27,089 inbound rule for that, and that traffic is coming on port 443 and that is going 114 00:10:27,089 --> 00:10:33,929 to allow inbound traffic coming in to that load balancer lister port for HTTP 115 00:10:33,929 --> 00:10:41,970 traffic. Now we also need to have an outbound rule to allow the elastic load 116 00:10:41,970 --> 00:10:47,910 balancer to send traffic out to our instances that are behind our elastic 117 00:10:47,910 --> 00:10:52,800 load balancer. So the first thing we need there is for port 80 to allow that 118 00:10:52,800 --> 00:10:57,589 traffic to go to those instances and to receive traffic to those instances and, 119 00:10:57,589 --> 00:11:02,129 then the next one we need to do is that we need to send out from our Elastic Lopad Balancer 120 00:11:02,129 --> 00:11:06,809 our health checks. So depending on how we've got that health check setup 121 00:11:06,809 --> 00:11:11,189 and in this situation we've got it set up on port 80 so we need to allow 122 00:11:11,189 --> 00:11:18,800 traffic outbound on that port for those health checks to be to be conducted. 123 00:11:20,940 --> 00:11:26,500 There are a number of configuration settings that we can define for our 124 00:11:26,500 --> 00:11:32,170 elastic load balancer. The first one there is the idle connection timeout. 125 00:11:32,170 --> 00:11:39,399 If no data is received within that defined idle connection timeout period, 126 00:11:39,399 --> 00:11:44,050 the elastic load balancer will close that connection, and so the default for that 127 00:11:44,050 --> 00:11:49,959 is 60 seconds. Now one thing to really take into consideration is that if 128 00:11:49,959 --> 00:11:55,240 you're implementing HTTP, which of course you no doubt will be, 129 00:11:55,240 --> 00:12:03,100 it's recommended to have a keep alive timeout option enabled. So what that does is it 130 00:12:03,100 --> 00:12:10,120 enables a load balancer to reuse those existing instance connections over that 131 00:12:10,120 --> 00:12:15,459 period of time, and what that does is that we reduce the CPU load on those 132 00:12:15,459 --> 00:12:20,380 back-end instances. So the recommended there is greater than the 60 seconds but 133 00:12:20,380 --> 00:12:25,510 you need to make sure that is greater than the idle connection timeout period 134 00:12:25,510 --> 00:12:30,399 that you have defined. Connection draining allows you to keep your 135 00:12:30,399 --> 00:12:37,269 existing connections to your instances open even when they're about to become 136 00:12:37,269 --> 00:12:43,630 deregistered or they have a status of unhealthy. Now the reason we would want 137 00:12:43,630 --> 00:12:48,160 to do that is that, for example if we've got a client connected, he's 138 00:12:48,160 --> 00:12:53,050 communicating with an instance and sent a request to that instance. We would 139 00:12:53,050 --> 00:12:57,519 like the instance to have a good opportunity to respond to that 140 00:12:57,519 --> 00:13:02,019 request, for example there might be an intermittent fault that has made that 141 00:13:02,019 --> 00:13:07,570 instance unhealthy or, it could be responding to an auto scaling event or 142 00:13:07,570 --> 00:13:12,420 something like that could interrupt that connection. So to keep that open, 143 00:13:12,420 --> 00:13:18,730 that will allow us to complete those in-flight requests that have come in 144 00:13:18,730 --> 00:13:22,990 from our client through to that instance and also from the other way 145 00:13:22,990 --> 00:13:28,750 back as well. So the ELB state when this is occurring when we've got connection 146 00:13:28,750 --> 00:13:32,000 draining in effect it will say in service 147 00:13:32,000 --> 00:13:36,890 instance de-registration currently in progress. So the way that we do that is 148 00:13:36,890 --> 00:13:43,700 that we define a timeout period and that can be anywhere from 1 to 3600 seconds 149 00:13:43,700 --> 00:13:50,810 or 1 hour. Now after those in-flight requests have been completed or the 150 00:13:50,810 --> 00:13:56,390 connection draining timeout period that you have defined has been exceeded, then 151 00:13:56,390 --> 00:14:01,460 the ELB state will change to out of service, and then instance is not 152 00:14:01,460 --> 00:14:06,680 currently registered with a load balancer and the load balancer will no 153 00:14:06,680 --> 00:14:13,540 longer be sending requests, or waiting for return responses, from that instance. 154 00:14:13,540 --> 00:14:18,290 Cross zone load balancing is another great feature that you might want to 155 00:14:18,290 --> 00:14:22,730 consider if you have got your elastic load balancer spanning multiple 156 00:14:22,730 --> 00:14:28,490 availability zones, and of course you would always want to do that anyway. It is a 157 00:14:28,490 --> 00:14:31,520 good practice to make sure that you have your architecture across multiple 158 00:14:31,520 --> 00:14:37,610 availability zones. Now by default requests coming into an elastic load 159 00:14:37,610 --> 00:14:42,670 balancer will be distributed by that load balancer across the available 160 00:14:42,670 --> 00:14:50,890 availability zones. So that's fine but what happens if for example we have one 161 00:14:50,890 --> 00:14:55,160 availability zone is more loaded than the other? It may have more instances in 162 00:14:55,160 --> 00:14:59,990 one availability zone than in another availability zone, or one availability 163 00:14:59,990 --> 00:15:04,190 zone might have got a lot of long-running requests, and so that has 164 00:15:04,190 --> 00:15:09,380 taken away a lot of the instances that are available. How can we make sure that 165 00:15:09,380 --> 00:15:13,280 we're getting the most out of all of those instances across all of those 166 00:15:13,280 --> 00:15:18,050 availability zones? So that's where cross zone load balancing comes in. 167 00:15:18,050 --> 00:15:21,800 So within our elastic load balancer we're going to have nodes that 168 00:15:21,800 --> 00:15:26,839 distribute that traffic, and so looking at our diagram there on the right hand 169 00:15:26,839 --> 00:15:31,940 side, that we can see that without it or with it disabled, that traffic is going 170 00:15:31,940 --> 00:15:36,830 to be distributed from the nodes within that availability zone to the instances 171 00:15:36,830 --> 00:15:42,470 within that availability zone, but when we have cross zone low balancing enabled 172 00:15:42,470 --> 00:15:49,220 those nodes, for example we can see here availability Zone B if there are no 173 00:15:49,220 --> 00:15:55,009 available instances then that node will then select an instance from the other 174 00:15:55,009 --> 00:15:58,600 availability zone, and we can see there it's selecting an instance from 175 00:15:58,600 --> 00:16:03,679 availability zone a, and that way we're maximizing the utilization of those 176 00:16:03,679 --> 00:16:10,669 instances across both availability zones. Cross zone load balancing determines how 177 00:16:10,669 --> 00:16:17,119 the load balancer selects an instance, and when it is enabled those nodes 178 00:16:17,119 --> 00:16:22,759 within that elastic load balancer will select that instance regardless of what 179 00:16:22,759 --> 00:16:26,379 the availability zone is. 180 00:16:28,330 --> 00:16:33,769 One thing to take into consideration when using elastic load balancers is that 181 00:16:33,769 --> 00:16:38,870 when a client connects into an elastic load balancer and it's had its traffic 182 00:16:38,870 --> 00:16:44,570 transmitted through to that back-end instance, that may change, that situation 183 00:16:44,570 --> 00:16:48,649 may change and you might get an auto scaling event and all of a sudden that 184 00:16:48,649 --> 00:16:52,730 client is no longer communicating with that particular instance but with 185 00:16:52,730 --> 00:16:57,970 another instance. So that's very important if we want to maintain 186 00:16:57,970 --> 00:17:02,510 connections between a client and a specific back-end instance, and that's 187 00:17:02,510 --> 00:17:07,640 very important when it comes to new technologies such as WebSockets which 188 00:17:07,640 --> 00:17:13,730 maintain a live connection between the client and that back-end for 189 00:17:13,730 --> 00:17:18,020 transferring of data, and you see that a lot in modern web applications such as 190 00:17:18,020 --> 00:17:24,380 for example the Gmail application where where your inbox will be updated even 191 00:17:24,380 --> 00:17:28,189 though there is no page refresh going on. It's just automatically got that live 192 00:17:28,189 --> 00:17:35,090 connection that allows that to happen, and so proxy protocol can be used to 193 00:17:35,090 --> 00:17:41,050 carry connection information from that source to the destination. Now normally 194 00:17:41,050 --> 00:17:46,970 the header information that is sent over from the elastic load balancer to the 195 00:17:46,970 --> 00:17:52,490 instance contains the IP address of the load balancer It doesn't provide the 196 00:17:52,490 --> 00:17:58,090 information of the originating client that connected to the load balancer 197 00:17:58,090 --> 00:18:04,429 before that information was sent over to the back-end, and so what proxy protocol 198 00:18:04,429 --> 00:18:11,270 does it adds a human readable header to the request header that is sent to the 199 00:18:11,270 --> 00:18:16,460 instance, and that provides connection information such as the source IP 200 00:18:16,460 --> 00:18:21,169 address of the client that is connected to the elastic load balancer, the 201 00:18:21,169 --> 00:18:26,960 destination IP address and the port numbers, and proxy protocol it is a 202 00:18:26,960 --> 00:18:32,510 single line that is added and there is what it looks like. Now one thing to take 203 00:18:32,510 --> 00:18:39,500 into consideration is that your back-end instances need to support proxy protocol. 204 00:18:39,500 --> 00:18:44,480 So if you've got for example an Apache web server, and 205 00:18:44,480 --> 00:18:49,130 that's not going to support proxy protocol, and so that's going to create a problem. 206 00:18:49,130 --> 00:18:53,600 It just won't work because it won't be able to process that proxy 207 00:18:53,600 --> 00:19:00,020 protocol information but if you've got a modern NGINX backend then that will 208 00:19:00,020 --> 00:19:05,210 support proxy protocol and it will be able to communicate with that 209 00:19:05,210 --> 00:19:08,560 elastic load balancer. 210 00:19:11,010 --> 00:19:18,580 As we discussed previously, it's very important to take into consideration the 211 00:19:18,580 --> 00:19:24,550 session state of your application, and so what that means is that we might be 212 00:19:24,550 --> 00:19:28,420 connected to one instance and then all of a sudden we are connected to another 213 00:19:28,420 --> 00:19:34,270 instance, and that instance doesn't have the temporary information that was saved 214 00:19:34,270 --> 00:19:39,810 by that instance when it was connecting with that client. So sticky sessions 215 00:19:39,810 --> 00:19:47,290 enable a load balancer to bind a user's client session, that is connected to that 216 00:19:47,290 --> 00:19:51,310 load balancer, to a specific back-end instance, and it 217 00:19:51,310 --> 00:19:58,090 will maintain that and unless the instance becomes unhealthy, and in that 218 00:19:58,090 --> 00:20:04,360 situation then the stickiness moves to another healthy instance instead. 219 00:20:04,360 --> 00:20:08,860 There are two types of sticky sessions., We can have duration based, which is what we 220 00:20:08,860 --> 00:20:13,060 would normally use and that is where the elastic load balancer itself will create 221 00:20:13,060 --> 00:20:18,940 a cookie named AWS ELB, and that cookie will be used to map that particular 222 00:20:18,940 --> 00:20:24,730 session to that particular back-end instance. If it is a new connection and 223 00:20:24,730 --> 00:20:29,890 no cookie is present because of that, then the load balancer will simply use 224 00:20:29,890 --> 00:20:35,140 the instance that has the least load. The other way that we can implement it is 225 00:20:35,140 --> 00:20:41,890 through application controlled and that way the application generates a cookie 226 00:20:41,890 --> 00:20:47,740 with its response and then the elastic load balancer will insert a stickiness 227 00:20:47,740 --> 00:20:52,990 cookie within that, and of course the same thing again if the application does 228 00:20:52,990 --> 00:20:57,880 not generate a cookie then that session will not be stuck to that particular 229 00:20:57,880 --> 00:21:05,880 instance and the ELB will simply again use the instance with the least load. 230 00:21:07,400 --> 00:21:13,890 In the same way that we can measure the performance of our ec2 instances using 231 00:21:13,890 --> 00:21:18,870 cloudwatch metrics, we can also measure the performance of our elastic load 232 00:21:18,870 --> 00:21:23,940 balancer with a number of cloudwatch and metrics, and those will be measured 233 00:21:23,940 --> 00:21:30,150 by the elastic load balancer and sent over to the cloudwatch service every 60 seconds 234 00:21:30,150 --> 00:21:34,860 and the cloudwatch metrics include the healthy hosts and unhealthy 235 00:21:34,860 --> 00:21:41,190 hosts, the request count and the latency for those requests. We can also have 236 00:21:41,190 --> 00:21:45,390 information about how much that elastic load balancer service is actually under 237 00:21:45,390 --> 00:21:50,400 pressure. We can see the surge queue length and the spillover count from that 238 00:21:50,400 --> 00:21:55,650 elastic load balancer. We can also see the number of HTTP errors and the 239 00:21:55,650 --> 00:21:59,490 back-end connection errors and we can monitor those and view those in the 240 00:21:59,490 --> 00:22:06,330 cloudwatch console as a dashboard. You can also enable access logs on an 241 00:22:06,330 --> 00:22:11,840 elastic load balancer, and when you do that the elb will publish a log file 242 00:22:11,840 --> 00:22:17,310 for each of those access connections to that load balancer and those will be 243 00:22:17,310 --> 00:22:24,180 within 5 to 60 minute intervals and they will be saved as a log file to Amazon s3. 244 00:22:24,180 --> 00:22:30,900 Finally we can also look at the API calls that are going to our elastic load 245 00:22:30,900 --> 00:22:36,440 balancer as well, and we can log those using cloudtrail. 246 00:22:39,020 --> 00:22:44,460 There are a number of ways that we can troubleshoot our elastic load balancers 247 00:22:44,460 --> 00:22:49,770 when something goes wrong. If we're using the API or one of the many software 248 00:22:49,770 --> 00:22:54,750 development kits, we may get some API errors coming back. The first one there 249 00:22:54,750 --> 00:22:58,679 we've got certificate not found. So what that normally means is that our 250 00:22:58,679 --> 00:23:04,740 certificate is not valid is expired or it actually does not even exist on our 251 00:23:04,740 --> 00:23:09,570 or associated to our elastic load balancer. The other one there could be 252 00:23:09,570 --> 00:23:14,400 out of service a transient error and that is generally a problem with your 253 00:23:14,400 --> 00:23:19,559 load a load balancer that is temporary and normally fixes itself after a short 254 00:23:19,559 --> 00:23:25,710 amount of time. We can also get a number of HTTP errors coming back from requests. 255 00:23:25,710 --> 00:23:31,590 We can have 400 which would be a bad request. So the client that is connected 256 00:23:31,590 --> 00:23:36,840 to the elastic load balancer has put forward a bad request. We could have a 257 00:23:36,840 --> 00:23:45,120 405 method not allowed and so again the client has put in there a method in the 258 00:23:45,120 --> 00:23:53,309 request header that exceeds the maximum 127 characters. A 408 eror will be a 259 00:23:53,309 --> 00:23:58,280 request timeout, and so that means that the client itself that is connected has 260 00:23:58,280 --> 00:24:03,960 for some reason cancel that request or that request was interrupted midway 261 00:24:03,960 --> 00:24:09,720 through making that request. 502 bad gateway and that generally means that 262 00:24:09,720 --> 00:24:15,480 the instance has responded with a malformed response. 503 service 263 00:24:15,480 --> 00:24:20,309 unavailable and that would normally mean that the load balancer is overloaded or 264 00:24:20,309 --> 00:24:26,330 there are no available healthy instances available to respond to any requests. 265 00:24:26,330 --> 00:24:33,809 504 gateway timeout error will mean that the connection was closed because of a 266 00:24:33,809 --> 00:24:39,090 timeout error for a response. Now all of these you don't need to write them down 267 00:24:39,090 --> 00:24:44,100 because they are all in the troubleshoot your load balancer section of the elastic 268 00:24:44,100 --> 00:24:47,190 load balancer developer guide. So if you go to there, there'll be a chapter 269 00:24:47,190 --> 00:24:50,940 called troubleshooting your load balancer, and that will do detail all of 270 00:24:50,940 --> 00:24:52,700 this. All I've done here is really just 271 00:24:52,700 --> 00:25:00,570 captured it in a more concise format for you. If you're using Cloudwatch to 272 00:25:00,570 --> 00:25:04,559 monitor your elastic load balancer, you may want to have a look at the response 273 00:25:04,559 --> 00:25:10,229 code metrics. So we're going to see there ELB 4XX. So that is going to be 274 00:25:10,229 --> 00:25:13,769 requests errors so they're going to be client-side errors. A client that is 275 00:25:13,769 --> 00:25:18,450 connected to the elastic load balancer has made a bad request or hasn't 276 00:25:18,450 --> 00:25:23,039 finished that request or has had that connection interrupted while they were 277 00:25:23,039 --> 00:25:29,009 making that request. We have ELB 5XX and there will be a load balancer or 278 00:25:29,009 --> 00:25:35,399 instance error. So that's back end errors. We have back-end metrics. So we would say 279 00:25:35,399 --> 00:25:41,580 back end 2XX whatever that may be, that will be that a successful response 280 00:25:41,580 --> 00:25:47,099 was sent back to the client from the back end. If it's a 3XX that means that 281 00:25:47,099 --> 00:25:51,719 the response was redirected by the backend. If it's a backend 4XX 282 00:25:51,719 --> 00:25:57,269 that means that the backend has sent a client error back to the client. If it's 283 00:25:57,269 --> 00:26:01,619 a 5XX then that will be a server error response that has come back 284 00:26:01,619 --> 00:26:08,179 from the instance and the ELB has forward that back to Cloudwatch. 285 00:26:09,820 --> 00:26:14,269 We can also have a look at the health checks and see how they are failing as well . 286 00:26:14,269 --> 00:26:19,399 So the first one there is a health check target page error. So if we've got 287 00:26:19,399 --> 00:26:23,899 our health check, to check on a certain page within our website, there might be a problem, 288 00:26:23,899 --> 00:26:28,009 that page may not exist or we might have made a mistake like that or 289 00:26:28,009 --> 00:26:33,489 there may be an application error that is stopping that page from being seen. 290 00:26:33,489 --> 00:26:38,090 The next one there, connection to the instances has timed out. So for whatever reason 291 00:26:38,090 --> 00:26:42,679 our instances are not responding to those requests. so again need 292 00:26:42,679 --> 00:26:46,730 to look at maybe our firewall settings or maybe our application, there's a 293 00:26:46,730 --> 00:26:50,960 problem there, it's not responding to these instances. Next we've got SSL 294 00:26:50,960 --> 00:26:55,669 public key authentication is failing. So there is a problem there with our SSL 295 00:26:55,669 --> 00:27:00,799 public key. It's not the correct one. Most probably instance is not receiving 296 00:27:00,799 --> 00:27:05,090 traffic from the load balancer. So you need to make sure that the security 297 00:27:05,090 --> 00:27:09,289 group that is associated with that instance allows that traffic from the 298 00:27:09,289 --> 00:27:14,539 load balancer and also make sure that the subnet access control is also allows 299 00:27:14,539 --> 00:27:19,999 that traffic come in from the load balancer . It could also have ports on the 300 00:27:19,999 --> 00:27:26,480 instance are not open. We may have for example our linux firewall settings may 301 00:27:26,480 --> 00:27:31,279 not be allowing access on that port, so we would need to check our firewall 302 00:27:31,279 --> 00:27:35,239 settings and make sure that is correct. We may also have a situation 303 00:27:35,239 --> 00:27:42,200 where our instances in an auto scaling group are failing the elastic load 304 00:27:42,200 --> 00:27:48,109 balancer health check, but they are actually not failing the auto scaling 305 00:27:48,109 --> 00:27:52,399 group health checks, and so that would most probably be a problem with your 306 00:27:52,399 --> 00:27:57,109 application for some reason your application is not processing those 307 00:27:57,109 --> 00:28:02,749 health checks properly. If you have connectivity issues, for example you have 308 00:28:02,749 --> 00:28:06,950 a website and you can't access it through a browser make sure that your 309 00:28:06,950 --> 00:28:11,389 elastic load balancer isn't located within a private subnet make sure that 310 00:28:11,389 --> 00:28:16,609 this security group allows traffic and the access control is also allow traffic. 311 00:28:16,609 --> 00:28:21,409 If you have problems with registering instances first thing to check is make 312 00:28:21,409 --> 00:28:25,010 sure that the health checks are correct and make sure that your instance 313 00:28:25,010 --> 00:28:29,030 is not failing those health checks. Another thing that can cause instance 314 00:28:29,030 --> 00:28:33,500 registration issues is if there's a problem with the AMI that you're using. 315 00:28:33,500 --> 00:28:40,490 So make sure that you're using an AMI that you're allowed to use. So again all 316 00:28:40,490 --> 00:28:44,360 of this stuff is in the troubleshoot your load balance a chapter of the 317 00:28:44,360 --> 00:28:51,020 elastic load balancer developer guide. So that brings us to the end of another big 318 00:28:51,020 --> 00:28:55,460 lecture. Hope you got a lot out of it and I look forward to seeing you in the next 319 00:28:55,460 --> 00:28:57,610 one.