EC2 High Availability and Scalability

5. Load Balancer Stickiness

Let's talk about load balancer stickiness because it is quite an important exam topic and you may get a few questions on it. Nobody believes it is possible to implement stickiness, which means that the same client is always redirected to the same instance behind a load balancer, and this works for both traditional bouncers and application load balancers. So this cookie that enables using Stickiness will have an expiration date. We have control over that expiration date. We've even enabled Stickiness to make sure that the user doesn't lose his session data. So, for example, if you're always talking to the same server, you may have session information, but if you suddenly talk to another server, you lose that session information and you lose your state. So, stickiness can be quite a good thing. Overall, though, enabling Stickiness may bring some imbalance to the load over our backed EC two instances. So let me show you what it means.

Here is our load balancer and we have two EC instances behind it. Now, client A could be a web browser from my friend. He's talking to the load balancer and the load balancer forwards this traffic to the easy instance number one. Now, because we have stickiness enabled, if client A does a request again to the My Load Balancer, the My Loadbalancer will direct them to the exact same EC instance up until the cookie times out. Okay, now we have client B. It's my other friend, and he talks to the load balancer, and the load bouncer decides to send it to the other easy instance. So if my other friend still talks to the load balancer, it will always be redirected to the second easiest instance. And me, from my computer, I'm client C. I'm talking to the load balancer and I'm being redirected to the second instance. So it turns out that here we have an imbalance, right? Because two clients are redirected to the second EC two instance and one client is redirected to the first EC two instance, It's not a bad thing, but it's something you want to monitor. The exam will ask you questions such as "Hey, one easyto instance is experiencing 80% CPU, the other one is getting 20% CPU, and they're both behind a load balancer." What is the reason? Right, the reason is probably because stickiness is enabled and then a lot of clients are stuck on one easy to instance that is getting overloaded. So let's have a look at how we can enable stickiness.

So I am in My Load Balancer and actually have to go to my target groups. In my target group right now I have to scroll down and under attributes I can enable Stickiness. So let me just show you that as I refresh my page, I get redirected to my three easy instances, which is exactly what you want. This is a perfectly balanced load balancing.Now I'm going to edit the attributes. I'm going to enable stickiness. So I click on enable and I'll give the stickiness a duration of 60 seconds. So, 1 minute. But you can choose any value between one day and seven days. So for 1 minute, click on save. And now load balancer stickiness is enabled. So I'm first going to acquire a cookie. So I'm going to refresh this page and I'm redirected to one seventy-two, thirty-one nine, one thirty eight.And if I refresh, you see, it took a little bit of time to propagate, but now I'm always stuck at 33. So 33, 33, 33. At the end, I always go to the same instance and search for about 60 seconds. And in 60 seconds, my cookie will expire and I'll be able to talk to another easy instance. So I'll just pause the video. Now it's been over a minute and if I refreshmy page I'm redirected to a new instance, 33 27. And if I refresh again, I'm always redirected to that instance. So stickiness is indeed working, and it's working really well. So that's it. It's a quick lecture. But just remember that stickiness can be measured directly in the target group. And here you can set this tokenistratio between 1 second and seven days. So set it accordingly to what it makes sense for your app, but that's it. And remember that stickiness can bring some imbalance because many requests may be redacted to the same thing over and over again. So that's it. I will see you in the next lecture.

6. ELBs for SysOps

So this lecture is just for people who are taking the Sys Ops exam. You need to know a few things. I may have said them in the past, but I just want to reiterate them just so we can understand exactly what I mean. The application will bounce on layer seven, which means HTTP, HTTPS, and WebSockets. It's URL-based routing, so you can have hostname or path-based routing. And it does not support static IP. It has a fixed DNS, as we've seen in the previous lecture. We can provide SSL termination. So that means we can install SSLcertificates onto the application load balancer and make our application have HTTPS enabled. A network load balancer, on the other hand, will be a layer four device. So layer four is the lower level, so it's TCP. So Http, by the way, is built on top of TCP, but it's a few layers up. So TCP is lower level, but that means there's only a prewarming for the load balancer. You get one static IP per subnet. So this time there's no DNS, it's just a static IP. And you cannot do SSL termination using the network load balancer. SSL, in that case, must be enabled by you implementing the application. The network load balancer just redirects the traffic. So, in the exam, they may ask you how to assign a fixed IP address to an application bouncer. And there's kind of a hacky way of doing it. You have to put a chain in between NLB and ALB together to give the alba fixed IP.

Now, this is a bit technical about how to do it,but just get the idea that if you wanted to somehow have a fixed IP for your application load balancer, then you just place a network load balancer in front of it. So that's it. Now you need to be able to pre-warm your load balancer, and that is for the classic load balancer and the application load balancer. So a load balancer, it's scaling, will scale gradually to traffic. That's how it works. But if you have a certain spike in traffic, say ten times your traffic, then it won't scale as fast as you need it to. And so, say this is a big sales season, like Christmas or Black Friday, and you expect very high traffic. Then you need to open a support ticket with AWS support to prewarm your ELB. And prewarming your ELB essentially means scaling it up in events. You should make that request at least 36 hours in advance. They'll ask you how long this traffic will last. How many requests per second do you expect? The size of the request in kilobits and other information, but basically all this information is estimates, so AWS can see how high it needs to scale your ELB or your ALB. Okay, So this is performance and this is very important You need to open a support ticket with AWS error codes. There are a lot of errorcodes for your load balancers and you need to know them at a high level. So 200 is a successful request. 400 million banrequest 401 means unauthorized. 403 means forbidden If you get a four-six-three, it means that theXforwarded header has over 30 IPs, so it's a malformed request. All these are client-side errors.

That means your application will throw an error and the load balancer will just pass it on. If you get a five-xx error code, that means it's unsuccessful at the server side. So a 500 error means internal server error, which means that some errors on the ELB itself are pretty rare. 502 means by gateway, 503 means service unavailable, so this is when your service is overloaded and this is actually something you should know. 504 is a gateway timeout, so there's probably an issue with the server and 561 means unauthorized, so this is it. Just remember these error codes 204.Xx and five xx. Four xx is for clients and five xx is for servers. Another question you may get, and it is quite an odd one to be honest, is how do we support SSL forwarders when we have older browsers connecting to us? And this is quite a common question, but a weird answer to be honest and a weird question, but the way to do it is that you need to change the ELB policy to allow for a weaker cypher. So one of the cyphers is called the CBC three-shot. This is a deprecatedcipher. It's not something that Ellis supports out of the box, but you can basically change your policy to enable this very small percentage of the internet to use your SSLand your load balancer. So how do we do it? Basically, load balancer provides a bunch of security policies for ALB or even classical load balancers, so these are the security policies and basically the very last one allows for weaker ciphers, and so if you absolutely need to support the legacy old browsers that are not really secure, then you can enable this policy, but it's not something that I just recommend doing but it's something that you need to know as a system administrator.

Here is the link and you can just go and have a read through it now some common troubleshooting So basically, you need to check your security groups. If the load balancer is not working, sometimes it's just as simple as that you need to check your health checks. Maybe some instances are unhealthy, and therefore the traffic is not directed to them. You need to look at sticky sessions. Sticky sessions may bring imbalance on the low balancing side, as we've seen. So make sure that if there is some imbalance in CPU, say for example, you look at stickysessions for a multi-AZ load balancer, you need to make sure that cross-zone balancing is enabled. That's for the classic load balancer. If you have an internal loadbalancer, it's for private applications. So use that if you don't need any public access. So if you want your application to be available only within your network, don't use a public-facing internet load balancer, use an internal one. And finally, just like a tip from you, if you have a production load balancer, please, please enable deletion protection to prevent accidental deletion. So let me show you how to do this. You go to your load balancer, you go all the way to the bottom attributes, and here you edit the attributes and deletion protection you enable. And this will basically make sure that no one can delete your load balancer by mistake. So let's try to delete it. I'll try to delete it. I'll just delete it and it says "no, you can't do this because deletion protection is enabled." which is great because no one can delete your production load balancer. And then if you want to disable it,here you go, you just disable it. Okay, but that's it for the load balancer for Cisco. So basically, it's all about troubleshooting and understanding how load balancers work as a whole. But I think you got this now and I will see you in the next lecture on load balancer integration with Cloud Watch.

7. Metrics, Logging and Tracing for ELBs

So now let's talk about how Cloud Watch integrates with load balancers because this is really important. So all load balancer metrics are directly pushed into Cloud Watch metrics, so you don't have to do anything to get that. Now there are a lot of metrics and some are more classic load balancers, some are more application loungers, and finally some are just network load balancers, but you don't need them all. Just remember the general idea of how metrics work and then you'll figure out which ones you need. This is exactly what you need. For example, they can be backend connection errors. So if you can't connect to the back end, there can be a healthy host count or an unhealthy host count. So if some hosts are unhealthy, then you'll get these metrics.

You can have a maximum of two Xx backend responses. So we should get three Xx for successful requests, four Xx for redirected requests, and five Xx for server errors. So all these things are great to monitor, especially the error ones. So remember four Xx, five Xx, that means your errors, which you should monitor and possibly set an alarm for latency. You may get some information around how fast your load bouncer is, and it's just kind of nice to have in case you need to have a SL request count, which is how many requests go to your load balancer. And if your load balancer is overwhelmed, you're going to see something called the search queue length. And this is the number of requests that are connections that will be pending route to the healthy instance. So this is a metric you might want to use to auto scale an ASG because the more requests that are waiting, the more you need two instances to serve these requests, and the maximum value of the search queue is 1024. So you need to remember this one because when the search queue length is filled, then spillover means that the requests are fully rejected because the search queue is entirely full. So spillover count as well.You need to understand and remember this one because, basically, that means that if your load balancer is overloaded and it didn't scale fast enough, your backend then requests are going to spill over and they're going to be rejected.

So let's have a look at monitoring real quick. We're in my load balancer, and there's two places where you can look at monitoring. Number one is in the monitoring tab, and we can see that there is a target response time in milliseconds, so one millisecond is a really good response time. The number of requests runs overtime, which is kind of cool. So we can see that we've done a few requests here and there. Then you can see the http five Xx, four Xx ELB,five Xx ELB, four Xx. So these are all errors, but we didn't get any errors, so they're not showing up. In the case of connection errors, they would show here the rejected connections. There will be some errors around TLS. The three Xx received errors, the two Xx received response codes, and the number of active connections. So here we can see the number of active connections and, finally, the new connection count in the process byte. So there are a lot of metrics right here. What you would need to remember is that they're all pushed into Cloud Watch directly. By the way, you can click here to view Cloud Watch metrics. The really cool thing is that if you click on Application ELB, you can view all these metrics right here. Or even better, what you can do is view the dashboard and it will just show a cool dashboard directly in Cloud Watch that was created for you. I really like that. But if you need to access a specific metric, then go to Application ELB and go to whatever metric you need. For example, these ones. And here you can get the request countover time by AZ, which is super neat. OK? Now the other thing you want to look at is target groups. So again, they're monitoring. Here you get the target group, and so it shows you the number of healthy host counts and unhealthy host counts. So, as we can see, we didn't deploy the application when we first started, so they were all unhealthy.

But then we deployed the application and the healthy host counts went to the roof and the unhealthy host counts went to zero. Then we can see the target response time,the number of requests, some error codes,some backend connection errors, and the number of requests count for targets, maybe something you want to keep under control as well. So that's it for monitoring. But there are other things you need to know. You need to know about access logs. So this is logging. Now we've done metrics, now we do logging. And so logs are access logs and they are stored in S Three. You must enable that integration, but load balancers will write logs into S Three, which will include information such as the time of the request, the client IP address, latencies, the request path, the server response, and the trace ID. So it contains a lot of information that could be really really good. And you don't pay for the feature, you just pay for the S three storage that is used. It's really helpful for compliance reasons. So when you enable this, for example, what happens is that you can keep track of all the requests that are made, and so it's super helpful if you want to keep extra data. Even if you delete your ELB or your easyto instance, do you still need to access what happened? Exactly. So the access logs are the place to go, and by the way, the excess logs are automatically encrypted for you. So you don't need to do anything special. So let's see how we can enable them. If we go to the load balancer description and scroll down in attributes, we can edit the attribute and enable Access Log. And here we need to specify an S3 location.

So I'll call it Stephan ELB Access Logs. And I'll say, create this location for me and click on Save. Now this will basically create an S Threebucket for me and we can verify this. So we'll go to services and we'll go to S Three. Now, in s3, I have my StefanELB access logs, which contain some AWS logs. And here are my log and test files. So basically, any request that we're going to make to our load balancer So I'm going to do a few requests right here. And actually, I should disablestickiness while I'm at it. So I'll just go to my target group and I'll disable stickiness. Here we go. So any request I make to my loadbalancer may take a while to disable the stickiness, or it may only take a minute. Any request I make is going to be logged into S Three. So what I'm going to do is just launch a few requests for 5 minutes and get back to SThree, which I will show you in a second. Okay? So I'm going back to my four-engine console. Click on it and here we have an elastic load balancing folder that was created for us. We can go to the region EOS One,go to the date 2018, the month of 1128. And here we get files around the load balancer that were created, and those are access logs. So the cool thing is that we can click on one, for example, and we can see what happens. So it's a pretty long file name, but if you scroll down, the cool thing I want to show you is that it is encrypted.

So encryption is AES 256 by default. So the logs are encrypted by the load balancer for us. Let's download the file. And the file has been downloaded. And so I went ahead and opened this file. So you have to despot and then decrypt it. But here we get a lot of good information. So this was an HTTP request. We have the time of the request, we have some information about the target group,some IP information, and we got some URL that was hit. So it was a get on this URL using the protocol HTTP 1.0, etc. And so we get a lot of information about Target Group. So all these things are really cool and important to have. And basically, that means that all the logs of all myrequests that were made, and you see, there's a lot of them that were made, appear under that log. And I think it's really, really cool to understand how access logs work. Finally, there's request tracing. So load balancers, basically any time you hit them, especially the application load balancer, will add a custom header called X Amazon Trace ID. And so, this is a request header to be able to do tracing. And so here's an example: amazontraceID roots equals blah blahblah. So that's one, and why do we use them? We use them in logs, access logs, and distributed tracing platforms to track a single request and see where it has been. And so you may be asking, if you have followed my developer course, is the application also integrated with X ray?And no, not yet.

It's not integrated with xray. So you can use that trace ID for other applications, such as open tracing, but not X-ray just yet. If you look at my access log again, if you look at this request, for example, root here. So this is my trace ID that was added as a header and I think it's kind of cool to see it right here. So each request will have its own trace ID added right here. Okay? So you just need to know that overall ALB to add some tracing. Finally, there is some troubleshooting you can do using metrics. So if you get a 400 b request,that means that the client sent a malformed request that does not meet a few specifications. If you get a 503, the service is unavailable. So you need to make sure you have healthy instances in each and every availability zone. So you may want to look at the Healthy Host camp. 504 Game Away Timeouts on Cloud Watch And so you need to look at the keeperlife setting on your X two instances, and you need to make sure that the timeouts are better. So there's a whole basic page on the Amazon website explaining each error code. And so what I suggest you do is every time you see an error code and you don't know what this means, you go and have a look at this documentation page and you set alarms accordingly to make sure these errors don't happen. So that's it. As a sys admin, you should be able to troubleshoot load balancers and this is why this section was a bit longer, but basically remember that load balancers are integrated with Cloud Watch metrics, that you can enable access logs that go directly into S3, and that there is some kind of tracing enabled through headers. Okay, that's it. I will see you in the next lecture.

8. Auto Scaling Groups Overview

Now we're getting into the concept of auto-scaling groups. So basically, in real life, your websites and applications will change and they will have different loads, so the more users, the more popular you're going to be and the more load you're going to have. So in the cloud, as we see, we can create and get rid of servers very quickly and so there's one thing that line group does very well, and that is to scale out. That means adding EC two instances to match an increased load but also scaling in removing two instances to match a decreased load. And then finally, we can ensure that the ECtwo instances can only grow to a certain amount or decrease to a certain amount and so we can define a minimum and a maximum number of machines running in an ASG. Finally, we can have an ASG super goal feature that automatically registers new instances to a load balancer. So in the previous lecture we registered instances manually, but obviously there's always some kind of automation we can do so in AWS. What does it look like with the graph?

Well, here is our beautiful autoscaling group It's a big arrowand so the minimum size, for example, one here, is the number of easy two instances you'll have for sure running into this auto scaling group parameter of actual size or desired capacity The maximum size is the number of EC2 instances running at the previous moment in the current moment in your ASG, and then you have the maximum size, which is how many instances can be added for scale out if needed when the load goes up, so that's super useful. What you need to know about is the minimum size, desired capacity, and maximum size parameters because they will change very often. Also notice that scale out means adding instances and scale in means removing instances. So now what does it look like with a load bouncer? Well here is our load balancer and web traffic goesstraight through it and we have an auto scaling group at the bottom. Basically, the load balancer will know how to connect to these ASG instances, so it will direct the traffic to these three instances.

But our auto scaling group scales out, so if we add two instances, then the load balancer will also register these targets, obviously perform health checks and directly reach traffic back to them. So the load balancer and auto scaling groups really work hand in hand in AWS. As a result, ASG have the following characteristics: We'll be creating one in the next lecture during the hands-on, but the launch configuration has an AMI and an instance type for easy user data if you need EBS volumes. security groups SSH. As you can see, this is exactly what we were doing before when we manually launched an instance. Obviously, they're very, very close. You also set the minimum size, the maximum size, and the initial capacity, as well as the desired capacity. We can define the network and the subnet in which our ASG will be able to create instances. And we'll define load balancer information or target group information based on which load balancer we use. Finally, when we create an SG, as we'll see, we'll be able to define scaling policies. So, what will set off a scale, or what will set off a scale in? So we are getting to the auto scaling part of autoscaling, which is the alarms. So basically, it's possible to scale your autoscaling groups based on the cloud watch alarm. And we haven't seen what Cloud Watch is yet, but as I said, Amazon is kind of a spaghetti ball.

So don't worry. Please follow me. So the Cloud Watch alarm is going to be something that's going to monitor a few metrics and when the alarm goes off, it's going to say when a metric goes up, it's okay, you should scale out, you should add instances, and then when the alarm goes back down or there's another alarm saying it's too low, we can scale in. So basically, the ASG will scale based on the alarms and the alarms can be anything you want to metric the monitors, such as the average CPU and the metrics are computed as an average overall. Okay, it doesn't look at the minimum or maximum, it looks at the average of these metrics based on the alarm. Basically, we can create scaling policies and scaling policies as I said. So there are rules and there are new rules for odour scaling. We'll be seeing them in the hands on.But now you can basically say, "Okay, I want to have a target average CPU usage in my auto scaling group, and basically it will scale in and scale outbased on your load to meet that target CPU usage." You can also have a rule based on the number of requests on the ELD, for instance, the average network in an average network app.

So really, whatever you think the best scaling policy is for your application, you can use these rules because they are easier to set up than the previous ones and they can make more sense to reason about saying okay, I want to have a thousand requests, for instance, from my ELB. That's easy to reason about where I want my Cpusage to be 40% on average. You can now auto scale based on your custommetric, and we can basically define a custom metric, such as the number of connected users to your application. And to do this, we'll create that customer metric from our application, we'll send it to CloudWatch using the Putmetric API, and then we'll create a CloudWatch alarm to react to low or high values of that metric. And then these alarms will basically trigger the scaling policy for the ASG. So what you should know out of this is that the auto scaling group isn't tied to the metrics AWS exposes. It can also be any metric you want. It can be a custom metric. So a small brain dump for ASG before we go into the hands on.So the scaling policy can be CPU network or custom metrics or even based on a schedule.

You can use launch configuration and if you want to update your ASG, just provide a new launch configuration. If you attach an im role to the ASG, you will get assigned to the EC two instances. We haven't seen yet what an IAM role is, but just know that they get transmitted from the ASG to the ECQ instance and the ASG are free. You don't really pay for ASG. You only pay for the two instances that are being spun up and spun down. So scale out and scale in. Okay? So ASG overall, you should definitely use them because they don't cost anything. Having instances under an ASG means that if you accidentally, you know, terminate an instance, the ASG will automatically create a new one or restart it. And so that's extra safety because now we know that if we need absolutely one instance running for our application and our easy-to-instance, then theASG will ensure that always one application is running. And then if a load balancer deems that an instance is unhealthy, it says it does a few health checks and it turns out that the instance is unhealthy, then the auto scaling group will automatically terminate the instance because it's marked unhealthy and then automatically replace it by creating new ones. So it's a really good way, it's a really good combination to work with a low bouncer and an ASG because together they can ensure that, number one,your application meets the traffic and, number two, if anything becomes unhealthy, then the ASG takes care of replacing these instances. So that's pretty cool. I hope you're excited and I will see you at the next lecture for the hands-on.

Study with ExamSnap to prepare for Amazon AWS Certified SysOps Administrator - Associate Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, Amazon AWS Certified SysOps Administrator - Associate Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide Amazon AWS Certified SysOps Administrator - Associate Practice Test Questions & Exam Dumps that are up-to-date.