Episode 6: Auto Scaling Groups Deep Dive | AWS Solutions Architect Prep

Hey everyone, Balu here. Welcome back to yet another episode with TechTalk with Balu. Your complete guide to Asing the AWS Solutions Architect Associate Exam. We are now on episode six and today we are covering auto scaling groups, one of the most powerful services in AWS for building resilient cost-effective architectures. Here's the truth. If you're manually adding and removing easy-to-instances based on the load, you're doing cloud computing wrong. The whole point of cloud is elasticity, that's automatically scaling resources up when you need them and down when you don't. Auto scaling groups make this automatic. Your application gets more traffic, ASG launches more instances. If the traffic drops, then ASG terminates the instances. You only pay for what you actually need and your application ever goes down due to capacity issues. This is heavily tested on the exam because it's fundamental to AWS architecture. Every well-designed system uses auto scaling groups. So today we are covering what auto scaling groups are and why they are essential. We are covering scaling policies that target tracking, step scaling and schedule scaling. Launch templates and configuration. We are covering integration with load balancers. We cover life cycle hooks for custom automation. We cover health checks and instance replacement. We cover various architecture patterns for resilient web tiers and of course exam traps and the favorite real world scenarios. By the end of this episode, you will know how to design auto scaling architectures that are resilient, cost effective and exam ready. So let's dive in. Let's first look at the auto scaling fundamentals. All right, so that's the basics. What is an auto scaling group and why does it exist? Let's look at a core problem first. Your website normally gets about 1000 users per day. Your single easy-to-instance handles this just fine. Then one day you're mentioned on Reddit and suddenly you have about 50,000 users. Your instance is overwhelmed, CPU hits 100%, response time goes from 200 milliseconds to 10 seconds. Users start getting time or terrorist some give up and leave you losing potential customers here. Now what do you do? Manly launch more instances. By the time they're running and configured, the traffic spike might be over. Or maybe it's not a spike. Maybe this is the new normal. Do you keep those extra instances running forever? That's the question to ask. This is the problem auto scaling groups solve. An auto scaling group is a collection of easy-to-instances that automatically scales the number of instances based on the conditions you define. It's like having a smart operation steam that watches your application twin and adds a removed service as needed instantly or automatically. Now what are the three core goals of ASG? Goal number one. Scale out that is add instances to match increased load. If your traffic increases, ASG automatically launches new instances. Now within minutes you have the capacity to handle the load. Users never experience slowdowns. Goal number two, scaling that's remove instances to match the decreased load. Just the opposite. If the traffic decreases, ASG automatically terminates the instances you don't need. You stop paying for idle capacity. Cost optimization happens automatically here. Goal number three is to maintain minimum and maximum capacity. You define what the minimum is. That's always run at least two instances. That's for high availability. You define the maximum. That's never run more than 10 instances. That's your cost protection there. And then what you designed definition is that I want maybe four instances right now. That's your current target. Now ASG ensures you stay within those bounds. Goal number four is to automatically replace unhealthy instances. An interesting use case. What happens if an instance fails a health check? ASG automatically terminates it and launches a replacement. Your application then stays healthy without any manual intervention. The goal number five is automatic load balancer registration. If a new instance launch, then ASG automatically registers it with your load balancer. The traffic then starts flowing immediately. Again, no manual configuration needed. Let's look at a real world example here. Netflix uses auto scaling groups extensively. During the peak evening hours when everyone is streaming shows ASG scales out with thousands of instances. At 3 a.m. when the viewership is low, ASG then scales into hundreds of instances. This saves millions of dollars per year while ensuring great performance during peak times. What's the cost? ASG is free. The auto scaling group service itself is free. You only pay for the easy to instances it launches. But because it automatically terminates instances you don't need, it often saves you money compared to running instances 24/7. So for the exam, remember auto scaling groups are free. You only pay for the underlying easy to instances. On to the next section. Let's look at ASG components and its configuration. Let's break down how ASG work. There are several components you need to understand. Component number one, the launch template. That's a blueprint. The launch template defines what instances to launch. It's the blueprint like we said. It includes the AMI, that's the Amazon machine image we talked about earlier. That's what OS and the software to run. The instance type, whether it's a.medium or M5 large etc. The key pair, that's for SSH access. The security groups, that's your firewall rules. The IAM rules, that's permissions for accessing the instance. The user data, that's the startup scripts. The EBS volumes, that's storage configuration and the network settings. That's the VPC and subnet. Think of the launch template as a recipe. When ASG needs to launch an instance, it follows this recipe exactly. Just to quickly touch upon the old way of doing this is using launch configurations. They are the old method they're deprecated. We don't have to talk much about that. They are less flexible than the launch templates. So for the exam, remember that launch templates are recommended. Launch configurations are legacy. Component number two is the capacity settings. This defines how many instances. So minimum capacity is the floor. ASG will always maintain at least this many instances. An example would be a minimum of two. Even if there is zero traffic, ASG keeps two instances running. Why? That's high availability for you. If one fails, you still have the other one running. Then there is maximum capacity. That's this ceiling. ASG will never launch more than this many instances. An example would be a maximum of 10. Even if traffic is through the roof, ASG won't launch the instance. This protects you from runaway costs. And then there is the desired capacity. An example would be a desired capacity of four. ASG tries to maintain exactly four instances right now. This number changes dynamically based on your scaling policies. Component number three is subnets and availability zones. Use specify which subnets and thus which availability zones ASG can launch instances in. Best practice is to specify subnets in multiple A's at least two preferably three. An example would be subnet one in US East 1A, subnet two in US East 1B and subnet three in US East. Let's see. ASG then distributes instances evenly across A's. If you have six instances and three A's, you get two instances per A's. Why this matters? If an entire A's fails, your application keeps running in the other A's. Component number four is load balancer integration. You can and you should attach an auto scaling group to a load balancer. When attached, ASU automatically registers new instances with the load balancer. Load balancer then starts sending traffic to the new instances. ASU automatically de-registers terminated instances. Load balancer stops sending traffic before termination. This integration is seamless and automatic. Component five is Hellchecks. ASG can use two types of Hellchecks. Easy to Hellcheck. That's a default. Check whether the instance is running. That's a VM level check to see if the instance is stopped or terminated, whether it's unhealthy, so and so forth. So a best practice here is to use ELB Hellchecks. They detect application failures, not just instance failures. An example scenario. Your instance is running. It passes the EC2 Hellchecks, but your application crashed. Fails the ELB Hellchecks. Now with ELB Hellchecks, ASG detects the problem and replaces the instances. Now let's look at Hellcheck Grace period. When a new instance launches, it needs time to boot up and start serving traffic. During this Grace period, default value would be 300 seconds. ASG does not perform Hellchecks. This prevents ASG from immediately terminating instances that are just starting up. An example question would be instances in an ASG are being terminated immediately after launching. What could be the costs? The answer is Hellcheck Grace period might be too short. The instances don't have enough time to pass Hellchecks before ASG considers them unhealthy. Now let's go onto the next section and look at scaling policies. This is the most important part for the exam. Scaling policy defines when and how much to scale. There are several types of scaling policies. Let's go through each one of them. Policy type 1 Target tracking scaling. This is the simplest and the most commonly used. You set a target metric value and ASG automatically adjusts capacity to maintain that target. An example, I get CPU utilization. I want average CPU utilization across all instances to stay around 50%. If the average CPU is currently 35%, ASG does nothing. If the average CPU rises to 65%, ASG now launches instances to bring it back to 50%. If the average CPU drops to 30%, ASG terminates instances to bring it back to 50%. Another example, target request count per target. I want each instance to handle approximately 1000 requests per minute. You have 10,000 requests per minute. request per minute coming in. If you have five instances, each handles 2000 RPM. That's over target ASG then scales out. If you have 15 instances, each handles 667 RPM. That's under target, SG then scales in and the sweet spot 10 instances each handling 1000 RPM. Another example, I get network traffic. I want average network out to be around 5 MB/s or instance. This is useful for network intensive applications like streaming services. Advantage of target tracking are that it's simple to configure. Just set a target and ASG will handle the rest. It automatically creates both scale out and scale in policies and responds dynamically to changes. The disadvantages are that it's less precise than step scaling for complex scenarios. For the example, target tracking is the recommended approach for most the use cases. Now onto policy type 2 which is simple scaling. This is based on cloud watch alarms. You create an alarm that triggers when a condition is met, then ASG performs a scaling action. For example, cloud watch alarm, average CPU, if greater than 70% scaling action, add two more instances. And then you configure another cloud watch alarm, where the average CPU is less than 30% and the scaling action is to remove one instance. How it all works is when the CPU hits 71% the alarm triggers. She then adds two instances and then the cooldown period begins. During the cooldown period, which is a default of 300 seconds. Remember, ASG doesn't perform any more scaling actions. This allows the metrics to stabilize after the scaling action. Now what is the problem with simple scaling? The cooldown period applies to all scaling actions, even if the conditions change significantly. An example is you can add two instances, but CPU is still high. ASG then has to wait 300 seconds before it can add more instances. Your application might struggle during this wait. On to policy number three, which is step scaling, that's better than simple. Like simple scaling, but with multiple steps and no cooldown period, example, we see if between 50 to 70% then please add one instance, CPU between 70 and 85% add three instances, CPU greater than 85% now add five instances. If the CPU now is between 30 to 50% don't do anything, CPU between 15 to 30% remove that one instance, and if the CPU is less than 15% remove the two instances. And how it all works is then if the CPU is at 60%, it adds one instance, if the CPU jumps to 80%, then it immediately adds three more instances. There is no cooldown period here. And if the CPU spikes to 90%, it again immediately adds five more instances. Step scaling responds faster because it doesn't wait for cooldown periods. For the exam, remember step scaling is better than simple scaling because it responds faster without cooldown delays. Policy type four is schedule scaling. This is for predictable traffic patterns. You know traffic increases every Friday at 5pm, schedule a scale out at at 5pm. If you know the traffic drops every night at midnight, then you want to schedule a scale in at 12.30am. An example schedule looks something like this. Monday to Friday at am set minimum capacity to 10, work there starts Monday to Friday at 6pm set minimum capacity to 2, that's when the work day ends. Every Friday at 4pm set the desired capacity to 20, the instances are ready before traffic arrives. There's no lag time. That's more cost effective than over provisioning 24/7 and it's perfect for predictable patterns. Now onto a real world example. An e-learning platform knows students access the system most heavily between Monday to Friday at 6pm to 10pm that's after school or work and Saturday to Sunday between 10am to 4pm that's for weekend studies. This schedule scale out right before this period and scaling after. So for the exam, schedule scaling is for predictable traffic patterns where you know when demand will increase. On to policy type 5, predictive scaling. This uses machine learning to forecast loads and schedule scaling ahead of time. ASG analyzes historical cloud watch data to predict future traffic patterns. An example. ASG notices traffic increasing every Monday at 9am. It automatically starts scaling out at 8.45am on Mondays. This is newer and less commonly used but remember it's on the exam. So for the exam, predictive scaling uses ML to forecast load and scale proactively. To summarize, the scaling policies let's quickly compare them. Target tracking is simple automatic and most common. Simple scaling the alarm based has cool down delays. Step scaling is alarm based. There's no cool down which means it's faster response. And schedule scaling is for predictable patterns which is more proactive. Pregnive scaling is ML based forecasting and is proactive as well. So best practices. Use target tracking for most scenarios. Use schedule scaling for known traffic patterns and use step scaling for more complicated scenarios that require finer control. Let's now touch on a bit more on the scaling cool down period. After scaling activity, ASG enters a cool down period. Remember it's default 300 seconds. During cool down, ASG doesn't launch or terminate instances even if alarm's trigger. And why is that? This is to allow metrics to stabilize. If you just added instances CPU would decrease. You don't want to immediately scale in before new instances start handling the load. Now how would you reduce the cool down time? What you want to do is to use ready to use AMIs with your application preinstalled. Instances will then start serving traffic faster, metric stabilize faster and cool down can be shorter. So for an exam question. An ASG is slow to respond to traffic spikes. What can reduce its response time? The answer is to use a custom AMI with the application preinstalled and reduce the cool down period. Now on to section 4. Lifecycle hooks. Lifecycle hooks are an advanced feature that lets you perform custom actions when your instances launch or terminate. What are lifecycle hooks? Normally when ASG launches an instance, the instance starts, instance becomes in service and load balancer sends traffic. With lifecycle hooks you can pause between steps 1 and 2 to perform custom actions. So let's look at some use cases now. Use case number 1, system software installation. Your application requires specialized software that takes 5 minutes to install. Without lifecycle hooks, instance becomes in service immediately but software isn't installed yet. So the request fails. Now with lifecycle hooks, the instance launches lifecycle hook process instance in pending wait state. Your script installs the software, script completes lifecycle action, instance becomes in service and now you're ready to serve traffic. Another use case log extraction before termination. Before ASG terminates an instance, you want to extract application logs to s3. Now with lifecycle hooks, ASG decides to terminate the instance. Lifecycle hook process instances in terminating wait state like before. Your script copies logs to s3, the script completes the lifecycle action and then the instance terminates. Another use case, hellcheck data. Before an instance goes into service, you want to run custom hellchacks. Lifecycle hook pauses the instance, your script runs the test. If the test pass, complete the action. If the test fails, abandon the action that's instance terminates. So let's look at how lifecycle hooks work. You define when EC2 instance launch or EC2 instance terminate. You decide the timeout that's how long to wait, default is 3600 seconds and the action what to do if the timeout expires to continue or abandon. When the hook triggers, ASG publishes a message to SNS or SQS. Your script or lambda function picks up the message, the script performs the action. Script calls complete lifecycle action API. An example with lambda integration. Lifecycle hook triggers on instance launch, SNS sends notification to lambda function, lambda runs custom initialization script on the instance. Lambda completes the lifecycle action and the instance becomes in service. Now for an exam scenario, a company needs to extract application logs from instances before they are terminated. How should this be configured? The answer is to create a lifecycle hook for EC2 instance, terminating transition. Then you configure the hook to trigger a lambda function that extracts log to S3. Then this completes the lifecycle action. An important note, if you don't complete the lifecycle action within the timeout, ASG will proceed with the default action that's usually will continue. On to section 5, health checks and instance replacement. Let's type deeper into health checks because this is critical for resilience. So health check types recap, EC2 health checks. If the instance is running at the VM level, status checks are instance status is the instance reachable and system status is the underlying hardware okay. If either fails, the instance is deemed unhealthy. ELB check, on the other hand, the load balance is checks if the application is responding. The process ELB sends HTTP get slash health or whatever you've configured. If the application responds with 200 okay, it's healthy. If the application doesn't respond or returns an error code, it's unhealthy. Now which is normally better? ELB health checks are better for most applications and why is that? Because they detect application level failures, not just instance failures. On to a real world example, your application has a memory leak. Over time, it consumes all the available memory and becomes unresponsive. The EC2 health checks if the instance is still running. It says it's healthy. The ELB health check, on the other hand, says application is not responding, it's unhealthy. ASG with ELB health checks would detect the problem and replace the instance. ASG with only EC2 health checks would miss that. Now what is a health check grace period? This is how long ASG waits after an instance launches before performing health checks. Why does it matter? instances need time to boot up, install software and start the application. If Grace Period is too short, ASG terminates instances before they finish starting up. With the Grace Period on the other hand is too long, unhealthy instances stay in service longer. So it's about finding the right value. Time your application start up. If it takes three minutes to be ready, set the Grace Period to 240 seconds. That's probably four minutes for safety. Let's now look at instance replacement process. When ASG detects an unhealthy instance, it marks the instance as unhealthy. It starts the termination process. It launches the replacement instance. The new instance goes through a Grace Period. The new instance passes the health checks. The new instance becomes in service and the old instance is terminated. This ensures you maintain desired capacity even during replacements. For an exam question, an ASG maintains four instances. One instance becomes unhealthy. What happens? The answer is ASG launches a new instance to replace it. Once the new instance is healthy, ASG terminates the unhealthy instance. Desired capacity is maintained at four throughout. Now let's look at termination policy. When ASG needs to scale in that's to terminate instances which instances does it terminate? The default termination policy is to select AZ with the most instances to balance across AZs. Within that AZ, terminate instances with the oldest launch template. If it's a tie, then terminate instances closest to the next billing hour. You can customize this policy. An example tip to know is that the default policy balances across AZs and terminates oldest instances first. Next, let's look at ASG with load balances. The combination of auto scaling groups and load balances is incredibly powerful. Let's see how they work together. There are some integration benefits with this. Benefit one automatic registration. When ASG launches an instance, it automatically registers it with the attached load balancer. When ASG terminates an instance, it automatically de-registers it. You don't manage this manually. It just happens. Benefit number two, ELB health checks. The load balancer continuously checks instance health. ASG can use these health checks to determine if instances should be replaced. Benefit three, connection draining. When ASG decides to terminate an instance, load balancer stops sending new request to it. Existing connections complete after connection draining timeout, instance, terminates. No user's experience errors during instance termination. Benefit number four, dynamic scaling based on load. You can scale based on request target a load balancer metric. An example is if each instance is handling greater than 1000 requests per minute, then scale out. The load balancer provides a metric. ASG uses it for scaling. Now for an exam scenario question. A company needs a highly available web application that automatically scales based on traffic. Design the architecture. The answer is to deploy an application load balancer across multiple AZs, attach an auto scaling group with instances in multiple AZs. Then configure target tracking scaling based on request count per target. Set minimum capacity to two. Also note that it'll be provide some useful metrics for scaling. Request count per target. That's requests per instance. You could use target response time. That's how long the request steak. You could use HTTP code target count, which is for application errors. And then you could also use activation connection count. That's the current connections. You can use any of these for scaling decisions. So best practice is to scale on request count per target for most web applications here. On to section seven, resilient web tier architecture. Let's walk through designing a resilient web tier from scratch. This is a common exam scenario. So the scenario we're looking at is you're designing a web application for an e-commerce company. The requirements are that it should handle unpredictable traffic that you can spike 10 X times during sales. It should be high availability. That's survive AZ failures. It should be auto healing. That should automatically replace unhealthy instances. And it should be cost effective. That's don't over provision it. So solution architecture would be number one multi-AZ deployment to deploy it in three availability zones. Let's say US East one A US East one B and US East one C and Y three. If one easy fails, you know, you still have two running. If one of those two half issues, you have one final backup. Step two would be to use an application load balancer, deploy an internet facing ALB across all the three AZ step three would be to configure an auto scaling group. So the minimum capacity would be three one per AZ for high availability, a desired capacity of six that is two per AZ for performance and a maximum capacity of 30 that's cost protective. And why a minimum of three. If one AZ fails completely, you still have two instances in the other two AZ's application stays online step no force to have a large template, a custom AMI with application pre installed at T3 dot medium or whatever your app needs from an instance type perspective from a security group perspective allow HTTP or HTTPS from load balancer only from an I am role perspective. You want permissions to access S3 dynamo DB etc. And for user data, it's minimal because the app already is in AMI and then use private subnets in all three AZ's. Step number five is to actually implement scaling policies policy one is to target track on CPU policy two would be to target tracking on request policy three schedule scaling step six would be health checks. He'll be held checks at application level with the grace period of three minutes. Your application takes two minutes to start three minute grace period ensures instances have time to become healthy step number seven is to configure connection training with the deed registration delay of 60 seconds. Your application has short requests that's under one minute. 60 seconds is sufficient for all requests to complete. Now what does this architecture provide? It provides high availability. It provides auto healing. It provides scalability. It provides cost optimization and it provides resilience. So for a real world cost analysis without auto scaling running 13 instances 24/7. The cost would approximately be about $900 per month. But with auto scaling, you would have that reduced to only $180 a month. So that's an 80% reduction cost right there. So normally you do see these kind of exam question patterns like a web application experiences traffic spikes during business hours and low traffic at the night. The company wants to minimize costs while maintaining high availability design the architecture. The answer components normally are multi-AZ auto scaling group application load balancer to use schedule scaling for business hours, target tracking scaling for unexpected spikes and minimum capacity greater than two for high availability. Now finally, let's look at the next section. Zam traps and gotchas. Let's cover the common exam traps for auto scaling groups. Top number one, capacity settings relationship. An ASG has a minimum of two, a maximum of 10 and a desired of 15. What happens? People think ASG launches 15 instances. That's wrong. Desired cannot exceed maximum. The answer is ASG sets decide to 10 that the maximum and launches 10 instances. Top number two, hell check grace period to short. The question is instances in an ASG are being terminated immediately after launching. What is wrong? The answer is hell check grace period is too short instances don't have time to start up before the ASG checks their health and marks them unhealthy. So the fix is to increase hell check grace period to match your application start time. Top number three, EC2 versus ELB hell checks the question. An application is crushing but ASG isn't replacing instances. Why is that? The answer is ASG is using easy to help checks. That's the default. The instance is running, but the application has crushed easy to help checks pass. The fix is to use ELB health checks as well. They detect application failures. Top number four, scaling during cooldown question. ASG scaled out once, but CPU is still high and ASG isn't adding more instances. Why? The answer is ASG is in its cooldown period. During cooldown, remember no scaling action occur. So solution is to step scaling instead of simple scaling. Remember step scaling doesn't have cooldown delays. Or what you could do is to reduce the cooldown period itself. On to trap number five, launch template versus launch configuration. The question is, what is the difference between launch template and launch configuration? The answer is launch templates are newer and recommended. Launch configurations are deprecated. Both define instant settings, but launch templates have more features. So the exam answer you always want to say you recommend launch templates for new ASGs. Top six, as you'll scaling timing. The question is traffic increases every day at 9am, but the application is slow between 9am and 9.5am. Why is that? The answer is schedule scaling occurs at 9am, but instances take three to five minutes to launch and become ready. So the fix is to instead schedule scaling at 8.50am. So instances are ready when the traffic arrives. Trapped number seven, minimum capacity for high availability. The question, what minimum capacity ensures high availability? People think one instance, that's wrong. If that instance fail, then you have zero capacity. So the answer is minimum capacity should be at least two, preferably in different ASGs. If one fails, the other keeps running. Trapped number eight target tracking creates two policies. The question, how many scaling policies does target tracking create? The answer is two, one for scale out and one for scale in. You set one target example, CPU of 50% and ASU automatically creates policies to scale out when about that 50% and scale in when below 50%. 12. 12. AST doesn't directly scale based on load balancer metrics. The question. Can AST scale based on load balancer response time? The answer is yes, but indirectly. You create a cloud watch alarm based on target response time metric from the load balancer, then create a scaling policy triggered by that alarm. AST doesn't directly monitor load balancer metrics. It responds to cloud watch alarms. Remember that. 12. 10. Termination Policy When AST scales in, which instance is terminated? The answer is for default policy. AST selects the AZ with the most instances, then terminates the instance with the oldest launch configuration or template. This maintains balance across ASTs. On to trap 11. Question. Can one AST be attached to both an ALB and an NLB? The answer is yes, an AST can be attached to multiple load balancers. Here is a particular use case for that ALB for HTTP traffic and NLB to handle TCP traffic from on-premises systems. On to trap 12. Lifecycle hooks and timelots. Question is, a lifecycle hook timeout is one hour, but the script completes in five minutes. Does AST wait for the full hour? The answer is no. If the script calls complete life cycle action, AST proceeds immediately. The timeout is the maximum wait time, not the actual wait time. Just remember that one. Now on to section 9, the exam quick tips. Now these are rapid fire exam tips for auto scaling groups. Tip number one, AST is free. You only pay for easy to instances. AST service itself is free to use. Tip number two, capacity settings must follow a particular relationship. The minimum should be less than equal to desired, less than equal to the max capacity. Tip number three, always use launch templates over launch configurations. Always recommend launch templates for new ASTs. Tip number four, minimum two for high availability. High availability requires at least two instances in different ASTs. Tip number five, ELB health checks for applications. Use ELB health checks instead of EC2 health checks for application level failures. On to tip six, target tracking for most scenarios. It's the simplest and most commonly recommended scaling policy. Tip number seven, schedule scaling for predictable patterns. If traffic increases at known times, schedule scale out before those times. Tip number eight, always choose step scaling over simple scaling. Step scaling always responds faster because there is no cooldown. Remember that. Tip number nine, life cycle hooks for custom actions. Use hooks when you need to perform actions during launch or termination. Tip number 10, connection draining prevents errors. When integrated with load balancers, connection draining ensures graceful instance termination. So I guess the key words to watch out for is if it talks about automatically scale, then refer to the auto scaling group. Predictible traffic pattern, think schedule scaling, replace unhealthy instances, think ASG with health checks, maintain minimum capacity, then think ASG minimum settings, cost optimization, think ASG with dynamic scaling and high availability, think multi-AZ. That's ASG with a minimum of greater than or equal to two. So alright everyone, that's episode six on auto scaling groups. Let's recap what we have covered today. We started with auto scaling fundamentals, what ASGs are and the five goals they achieve. We explored ASG components, that's the launch templates, the capacity settings, subnets and the health checks. We then went deep on to scaling policies that target tracking, simple step, scheduled and predictive scaling. We covered life cycle hooks for custom automation during instance launch and termination. We discussed health checks and why ELB health checks are much better than easy to health checks. We then explored ASG integration with load balances and the benefits of that combination. We designed a complete resilient web tier architecture from scratch, a multi-AZ auto scaling self-healing system and then we covered 12 exam traps that trip people up on the test day. So I want to leave you with this auto scaling groups are fundamental to AWS architecture. They are virtually in every well designed systems around us, master this and you're well on your way to both passing the exam and building production grade AWS infrastructure. So in our next episode, that's episode seven. We are deep diving into Amazon S3, the foundational storage service in AWS. We'll cover buckets, objects, storage classes, versioning, replication, life cycle policies and S3 security amongst other points. Now if this episode helped you understand auto scaling topic, please leave a five star rating on Spotify and do consider to subscribe and share it with anyone studying for the AWS exam. So until next time, keep studying, keep practicing and I will see you in episode seven. This is Baloo signing off. Bye.