Auto Scaling helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application. You create collections of EC2 instances, called Auto Scaling groups. You can specify the minimum number of instances in each Auto Scaling group, and Auto Scaling ensures that your group never goes below this size. You can specify the maximum number of instances in each Auto Scaling group, and Auto Scaling ensures that your group never goes above this size. If you specify the desired capacity, either when you create the group or at any time thereafter, Auto Scaling ensures that your group has this many instances. If you specify scaling policies, then Auto Scaling can launch or terminate instances as demand on your application increases or decreases.
For example, the following Auto Scaling group has a minimum size of 1 instance, a desired capacity of 2 instances, and a maximum size of 4 instances. The scaling policies that you define adjust the number of instances, within your minimum and maximum number of instances, based on the criteria that you specify.
[fusion_imageframe image_id=”1519″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/autoscaling-basic-diagram.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
Benefits of Auto Scaling
[/fusion_title]
Adding Auto Scaling to your application architecture is one way to maximize the benefits of the AWS cloud. When you use Auto Scaling, your applications gain the following benefits:
- Better fault tolerance. Auto Scaling can detect when an instance is unhealthy, terminate it, and launch an instance to replace it. You can also configure Auto Scaling to use multiple Availability Zones. If one Availability Zone becomes unavailable, Auto Scaling can launch instances in another one to compensate.
- Better availability. Auto Scaling can help you ensure that your application always has the right amount of capacity to handle the current traffic demands.
- Better cost management. Auto Scaling can dynamically increase and decrease capacity as needed. Because you pay for the EC2 instances you use, you save money by launching instances when they are actually needed and terminating them when they aren’t needed.
Contents
Example: Covering Variable Demand
To demonstrate some of the benefits of Auto Scaling, consider a basic Web application running on AWS. This application allows employees to search for conference rooms that they might want to use for meetings. During the beginning and end of the week, usage of this application is minimal. During the middle of the week, more employees are scheduling meetings, so the demands on the application increases significantly.
The following graph shows how much of the application’s capacity is used over the course of a week.
[fusion_imageframe image_id=”1522″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/capacity-example-diagram.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
Traditionally, there are two ways to plan for these changes in capacity. The first option is to add enough servers so that the application always has enough capacity to meet demand. The downside of this option, however, is that there are days in which the application doesn’t need this much capacity. The extra capacity remains unused and, in essence, raises the cost of keeping the application running.
[fusion_imageframe image_id=”1528″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/capacity-example-over-diagram.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
The second option is to have enough capacity to handle the average demands on the application. This option is less expensive, because you aren’t purchasing equipment that you’ll only use occasionally. However, you risk creating a poor customer experience when the demands on the application exceeds its capacity.
[fusion_imageframe image_id=”1527″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/capacity-example-under-diagram.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
By adding Auto Scaling to this application, you have a third option available. You can add new instances to the application only when necessary, and terminate them when they’re no longer needed. Because Auto Scaling uses EC2 instances, you only have to pay for the instances you use, when you use them. You now have a cost-effective architecture that provides the best customer experience while minimizing expenses.
[fusion_imageframe image_id=”1526″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/capacity-example-with-as-diagram.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
Example: Web App Architecture
In a common web app scenario, you run multiple copies of your app simultaneously to cover the volume of your customer traffic. These multiple copies of your application are hosted on identical EC2 instances (cloud servers), each handling customer requests.
[fusion_imageframe image_id=”1525″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/as-sample-web-architecture-diagram.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
Auto Scaling manages the launch and termination of these EC2 instances on your behalf. You define a set of criteria (such as an Amazon CloudWatch alarm) that determines when the Auto Scaling group launches or terminates EC2 instances. Adding Auto Scaling groups to your network architecture can help you make your application more highly available and fault tolerant.
[fusion_imageframe image_id=”1524″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/as-sample-web-architecture-diagram-with-asgs.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
You can create as many Auto Scaling groups as you need. For example, you can create an Auto Scaling group for each tier.
To distribute traffic between the instances in your Auto Scaling groups, you can introduce a load balancer into your architecture. For more information, see Using a Load Balancer With an Auto Scaling Group.
Example: Distributing Instances Across Availability Zones
AWS resources, such as EC2 instances, are housed in highly-available data centers. To provide additional scalability and reliability, these data centers are in different physical locations. Regions are large and widely dispersed geographic locations. Each region contains multiple distinct locations, called Availability Zones, that are engineered to be isolated from failures in other Availability Zones and provide inexpensive, low-latency network connectivity to other Availability Zones in the same region. For more information, see Regions and Endpoints: Auto Scaling in the Amazon Web Services General Reference.
Auto Scaling enables you to take advantage of the safety and reliability of geographic redundancy by spanning Auto Scaling groups across multiple Availability Zones within a region. When one Availability Zone becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected Availability Zone. When the unhealthy Availability Zone returns to a healthy state, Auto Scaling automatically redistributes the application instances evenly across all of the designated Availability Zones.
An Auto Scaling group can contain EC2 instances in one or more Availability Zones within the same region. However, Auto Scaling groups cannot span multiple regions.
For Auto Scaling groups in a VPC, the EC2 instances are launched in subnets. You select the subnets for your EC2 instances when you create or update the Auto Scaling group. You can select one or more subnets per Availability Zone. For more information, see Launching Auto Scaling Instances in a VPC.
Instance Distribution
Auto Scaling attempts to distribute instances evenly between the Availability Zones that are enabled for your Auto Scaling group. Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances. If the attempt fails, however, Auto Scaling attempts to launch the instances in another Availability Zone until it succeeds. For Auto Scaling groups in a VPC, if there are multiple subnets in an Availability Zone, Auto Scaling selects a subnet from the Availability Zone at random.
[fusion_imageframe image_id=”1529″ style_type=”none” stylecolor=”” hover_type=”none” bordersize=”” bordercolor=”” borderradius=”” align=”none” lightbox=”no” gallery_id=”” lightbox_image=”” alt=”” link=”” linktarget=”_self” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=””]https://www.headsoft.ca/wp-content/uploads/as-sample-web-architecture-diagram-with-asgs-and-azs.png[/fusion_imageframe][fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”” bottom_margin=”50″ border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
Rebalancing Activities
After certain actions occur, your Auto Scaling group can become unbalanced between Availability Zones. Auto Scaling compensates by rebalancing the Availability Zones. The following actions can lead to rebalancing activity:
- You change the Availability Zones for your group.
- You explicitly terminate or detach instances and the group becomes unbalanced.
- An Availability Zone that previously had insufficient capacity recovers and has additional capacity available.
- An Availability Zone that previously had a Spot market price above your Spot bid price now has a market price below your bid price.
When rebalancing, Auto Scaling launches new instances before terminating the old ones, so that rebalancing does not compromise the performance or availability of your application.
Because Auto Scaling attempts to launch new instances before terminating the old ones, being at or near the specified maximum capacity could impede or completely halt rebalancing activities. To avoid this problem, the system can temporarily exceed the specified maximum capacity of a group by a 10 percent margin (or by a 1-instance margin, whichever is greater) during a rebalancing activity. The margin is extended only if the group is at or near maximum capacity and needs rebalancing, either because of user-requested rezoning or to compensate for zone availability issues. The extension lasts only as long as needed to rebalance the group typically a few minutes.
Auto Scaling Components
The following table describes the key components of Auto Scaling.
 |
Groups Your EC2 instances are organized into groups so that they can be treated as a logical unit for the purposes of scaling and management. When you create a group, you can specify its minimum, maximum, and, desired number of EC2 instances. For more information, see Auto Scaling Groups. |
 |
Launch configurations Your group uses a launch configuration as a template for its EC2 instances. When you create a launch configuration, you can specify information such as the AMI ID, instance type, key pair, security groups, and block device mapping for your instances. For more information, see Launch Configurations. |
 |
Scaling plans A scaling plan tells Auto Scaling when and how to scale. For example, you can base a scaling plan on the occurrence of specified conditions (dynamic scaling) or on a schedule. For more information, see Scaling Plans. |
Getting Started
If you’re new to Auto Scaling, we recommend that you review Auto Scaling Lifecycle before you begin.
To begin, complete the Getting Started With Auto Scaling tutorial to create an Auto Scaling group and see how it responds when an instance in that group terminates. If you already have running EC2 instances, you can create an Auto Scaling group using an existing EC2 instance, and remove the instance from the group at any time.
Accessing Auto Scaling
AWS provides a web-based user interface, the AWS Management Console. If you’ve signed up for an AWS account, you can access Auto Scaling by signing into the AWS Management Console. To get started, choose EC2 from the console home page, and then choose Launch Configurations from the navigation pane.
If you prefer to use a command line interface, you have the following options:
- AWS Command Line Interface (CLI)
- Provides commands for a broad set of AWS products, and is supported on Windows, Mac, and Linux. To get started, see AWS Command Line Interface User Guide. For more information about the commands for Auto Scaling, see autoscaling in the AWS Command Line Interface Reference.
- AWS Tools for Windows PowerShell
- Provides commands for a broad set of AWS products for those who script in the PowerShell environment. To get started, see the AWS Tools for Windows PowerShell User Guide. For more information about the cmdlets for Auto Scaling, see the AWS Tools for Windows PowerShell Reference.
Auto Scaling provides a Query API. These requests are HTTP or HTTPS requests that use the HTTP verbs GET or POST and a Query parameter named Action. For more information about the API actions for Auto Scaling, see Actions in the Auto Scaling API Reference.
If you prefer to build applications using language-specific APIs instead of submitting a request over HTTP or HTTPS, AWS provides libraries, sample code, tutorials, and other resources for software developers. These libraries provide basic functions that automate tasks such as cryptographically signing your requests, retrying requests, and handling error responses, making it is easier for you to get started. For more information, see AWS SDKs and Tools.
For information about your credentials for accessing AWS, see AWS Security Credentials in the Amazon Web Services General Reference.
Pricing for Auto Scaling
There are no additional fees with Auto Scaling, so it’s easy to try it out and see how it can benefit your AWS architecture.
PCI DSS Compliance
Auto Scaling supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being compliant with Payment Card Industry (PCI) Data Security Standard (DSS). For more information about PCI DSS, including how to request a copy of the AWS PCI Compliance Package, see PCI DSS Level 1.
Related Services
To automatically distribute incoming application traffic across multiple instances in your Auto Scaling group, use Elastic Load Balancing. For more information, see Elastic Load Balancing User Guide.
To monitor basic statistics for your instances and Amazon EBS volumes, use Amazon CloudWatch. For more information, see the Amazon CloudWatch User Guide.
To monitor the calls made to the Auto Scaling API for your account, including calls made by the AWS Management Console, command line tools, and other services, use AWS CloudTrail. For more information, see the AWS CloudTrail User Guide.