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