What is AWS Auto Scaling?
Auto scaling group treats a collection of EC2 instances as a logical group to automatically scale it in size and quality. It allows for dynamic management and gives you further features that reduce the management overhead. Two of these features are scaling policies and health check replacements.You can adjust the size of the group to meet the demand of your environment. You can achieve this manually or automatically. An Auto Scaling group starts by launching enough instances to meet its desired capacity. It maintains this number of instances by performing periodic health checks on the instances in the group. They continue to maintain a fixed number of instances even if an instance becomes unhealthy. If an instance becomes unhealthy, the group terminates the unhealthy instance and launches another instance to replace it. Auto Scaling Groups can give you your desired number of resources and when its goal is achieved, automatically scale it down to cut down costs and management. Similarly, for updated deployments, you can bring in new ASG with new instances.
How Do You Optimize an AWS Auto Scaling Group?
Once you have your ASG set up, you can optimize the process of scaling and managing your instances in a number of ways. There are many mistakes people make when setting up their applications, especially ASGs. There’s also a lot of different tools and best practices available that make the process either simpler, more efficient, or just better for your wallet.
Automatic vs Manual management
Most people set up their ASG by going to the AWS console. From there, you have the option to choose your name, the size, set an AMI, security group and other tightly packed specifications. There’s plenty more. Problem is, if you mess up in this setup process, you have to do it all over again. Forgot to enter a detail or mistyped something. Start over. Just check this out, they have an entire guide on modifying ASG specs. Now, on the other hand, there’s a different way you can go about this process. AWS Cloudformation lets you create Auto Scaling Groups(and other resources in fact) based on your description of what specifications you want. It has a template that details resources, provisions and security policies all in one package. Here’s the kicker, you can even modify it. Besides the gift of specifying all aspects of your deployment, you can also apply version control to your AWS infrastructure in the same manner in which you version your code.
Configure Your Health Check
Auto Scaling Group has a default health check policy called EC2 status checks. If your instances fail these checks, the ASG considers them unhealthy and replaces it with another one. Health checks are vital to keeping your applications running optimally. Sadly though, the default EC2 health checks don’t guarantee a thorough look into whether or not your applications will fail during deployment. There are factors that the health check doesn’t account for. This means EC2 check could say the instance is A-ok but then your application still dies while running in your instance. With the EC2 health check, you really don’t know if your application can handle requests or is still performing its duties correctly.AWS does offer the option to attach more target groups to broaden the scope of the health check. You can attach an ELB health check to add more conditions to the monitoring of your instances and you an application load balancer health checks to focus on your application. These health checks involve sending pings, trying to establish a connection, and send requests.
Reactive/Proactive/Predictive Scaling
You will need to preemptively configure your scaling group to dynamically scale your instances. This is done by enabling a policy which triggers a resize through cloudwatch metrics.
There are three ways scaling can be done and intelligently managing these three different ways can give you optimal results.
Reactive Scaling
Proactive Scaling
Predictive Scaling
Reactive Scaling
Dynamically resizes your instances based on demands that occur in real-time. This is the standard use case of auto-scaling and it comes with no cost. So as you come upon increased usage, traffic, or load, your instances are automatically scaled to meet these changing demands. It is useful to those applications in which traffic keeps going up and down with no absolute pattern and thus, want to maintain performance with less of a hassle.
Proactive Scaling
Proactive scheduling is chosen when you know what the state of the load will be in the upcoming future so you schedule your scaling policies to trigger a resize when it is required. For example, if you have an application that has high activity during the weekends and not so much on other days. You might not want to use a high number of EC2 instances or use a large number of resources just because of the weekend loads. So, a better approach would be using a scheduled scaling.
Predictive Scaling
This is a feature that AWS provides which hinges on its predictive capabilities to report to you on possible upcoming resizing. This is very much similar to reactive scaling in how the scaling is done but you are given knowledge of the future similar to proactive scaling. Predictive Scaling gives you a general trend on how your instances will be altered so it means you can utilize this information to paint a picture on what your pricing would look like.
Each of these scaling methods come with their own benefits, you can use all three depending on the nature of the environments you have created to maximize the efficiency of your instances while reducing the price and being aware of it as well. The ideal goal is to not entirely rely on reactive scaling but also not to load up your management overhead.
Turning off Auto Scaling
You don’t need to keep your scaling policies always active. ASG themselves don’t charge you any extra fees but the cloudwatch metrics that contain the policies for the scaling group can incur charges. You can bring this down by carefully choosing when to turn your policies on and when to turn them off. You can reduce the tediousness of having to manually maintain the status of your ASG by choosing a service that can automate the process.
Similar to Proactive Scaling, scheduling your scaling group is best done when the status of your application or environment is predictable. It is a small task but when you consistently find opportunities to stop your scaling groups, it will help ease your AWS bills.
Top comments (0)