An AWS Auto Scaling group (ASG) is a fleet of EC2 instances that can scale up or down depending on application demand. The elasticity of Auto Scaling groups makes them highly-attractive options for enterprises who do not want to invest in purchasing expensive hardware only to respond to sudden or temporary spikes in application demand. Organizations can benefit from using Auto Scaling groups to add or remove compute resources, define policies governing when to scale, and by how much and how to rely on the autohealing (self-healing) capabilities to replace unhealthy EC2 instances from service.
The elastic and highly-available characteristics of cloud make it an appealing for organizations and enterprises that are looking to modernize and run their applications efficiently. When architecting a net new solution, there are always a multitude of options, and architects and solution designers must carefully consider each factor when choosing their platform. To assist cloud architects with this planning process, AWS has authored several white papers discussing best practices from its own experience with thousands of customer implementations. The most notable one is the AWS Well-Architected Framework, which serves as the go-to guide for AWS Cloud architects, and lists a series of best practices over 5 pillars:
This framework describes best practices and optimization for Auto Scaling groups and how you can adhere to the operational excellence, performance efficiency and cost optimization pillars as you design and architect your solution on the AWS Cloud.
To deploy EC2 instances using Auto Scaling groups, architects must choose between numerous factors such as Amazon Machine Instances (AMIs), EC2 instance types, placement groups, and security considerations. Related to scaling, they also need to consider what the minimum, maximum, and desired capacity would be, and how and when to scale. Additionally, they need to decide how to provision these ASGs—whether or not to use launch templates or launch configurations.
There is a large selection of EC2 instance types available by family and size. Picking the wrong instance type can lead to inefficient use of the EC2 instance. For example, if the EC2 instance selected is compute optimized, but the underlying application running on it can comfortably operate in a general purpose or burstable general purpose instance type, this leads to highly inefficient usage of the EC2 instance. If the workload is not compute-intensive, why pay excess for something that you are not using? As the AWS Well-Architected Framework recommends, the best practice is to continuously measure, monitor, and improve your workloads depending on your demand patterns.
Auto Scaling groups allow architects to select a scaling policy to determine when/how to scale. There are a multitude of options available, including:
Choose one that is reflective of the nature of your application’s demands.
Architects must also determine the minimum, maximum, and desired capacity of their applications running on Auto Scaling groups during configuration. However, without well-defined monitoring of the actual application metrics, this can lead to wasted spend (often in the range of thousands of dollars). What I see in many of my customer cases is that developers and architects often choose overly high minimum and desired capacity settings even if their application can operate well with much lower thresholds.
This makes this an interesting challenge for architects and developers who must determine exactly their application’s true demand patterns. We often see that since architects and developers are unable to precisely gauge their application’s demand patterns, especially over time, they end up overprovisioning their ASGs. This isn’t really a surprise as the main focus for most enterprises is performance and reliability. Exacerbating this is often a disconnect about concern around costs. Architects and developers may also end up underprovisioning their Auto Scaling groups, leading to resource throttling and performance degradation. The AWS Well-Architected Framework pillars of Performance Efficiency and Operational Excellence suggest one must continually measure and make incremental changes to their Auto Scaling groups to optimize.
The effective management of Auto Scaling groups optimization requires transparent, detailed, science-based analytics and projections that enable architects and developers to ensuring their application instances are always configured and resourced correctly, while running reliably in the cloud at the lowest possible cost.
Densify advises taking the following steps to best-optimize each ASG:
Completing a cursory optimization of a single AWS Auto Scaling group as outlined above is a complex and time-consuming process. At enterprise scale, AWS ASG optimization and management is only possible through solutions like Densify.
Interested in learning what Auto Scaling group optimization at scale and its potential benefits might look like for your organization? Request a demo with one of our Cloud Advisors today, and we’ll set up a presentation customized to your business and specific infrastructure management needs.