Introduction to EC2 Auto Scaling
Amazon EC2 Auto Scaling is a core service for managing the capacity of EC2 instances dynamically.
Amazon EC2 Auto Scaling is a service that automatically adjusts the number of EC2 instances within an Auto Scaling Group to meet application demand. This ensures high availability and scalability by dynamically launching or terminating instances based on predefined rules. It manages EC2 instances automatically, adjusting the number of servers based on application traffic, automatically scaling out (adding instances) during high demand, and scaling in (removing instances) during low traffic periods. It also replaces unhealthy instances automatically.
An Auto Scaling group is a collection of EC2 instances treated as a logical grouping for the purpose of auto-scaling and management. It's a key component of EC2 for dynamically adjusting the number of EC2 instances based on demand, and a collection of instances treated as a single unit for scaling and management purposes.
EC2 Auto Scaling provides several key benefits including high availability, cost optimization, fault tolerance (by handling unhealthy instances and replacing them), and improved performance (by distributing workload for optimal response times). It allows users to pay only for resources when needed and ensures sufficient capacity to meet demand.
EC2 Auto Scaling works with Launch Templates or Launch Configurations to define instance specifications. Auto Scaling Groups require a launch template, networking configuration, load balancer, scaling policies, and notifications. CloudWatch is a key component for monitoring metrics and triggering scaling actions.
Auto Scaling Group Capacity Management
Auto Scaling Groups allow you to define explicit capacity boundaries to control the number of instances running.
The lowest number of EC2 instances your Auto Scaling group will ever run. Its purpose is to ensure baseline capacity and prevent application outages during off-peak hours when demand drops. It defines the scaling boundaries.
Technical Specs: Example: Minimum capacity is 2, guaranteeing at least two instances are always running.
The target number of EC2 instances an Auto Scaling group aims to maintain at a given point in time for steady-state workload. This can be set manually or adjusted automatically through scaling policies. It cannot be lower than the minimum capacity. It defines the target number of instances for the ASG.
Technical Specs: Example: Desired capacity is 4, meaning the group aims to have exactly four instances running.
The highest number of EC2 instances your Auto Scaling group will allow. Its purpose is to control costs and prevent overprovisioning by limiting instance launches even during extreme traffic spikes. It defines the scaling boundaries.
Technical Specs: Example: Maximum capacity is 8, preventing the group from exceeding eight instances.
Launch Templates vs. Launch Configurations
comparison-table
Launch Templates are the AWS recommended method for defining the configuration of EC2 instances launched by Auto Scaling Groups, replacing the older Launch Configurations.
Launch Templates are the AWS best practice and offer more advanced features and flexibility compared to Launch Configurations.
| Option |
Status |
Editability |
Versioning |
Advanced Features |
Networking Information |
Recommendation |
| Launch Configurations |
Older, deprecated approach (since December 31, 2023). |
Cannot be edited after creation; requires creating a new one for updates. |
Do not support versioning. |
Supports only basic parameters; lacks advanced features. |
Do not include any networking information. Tenancy is controlled by VPC or explicitly set. |
Older and less flexible. Not recommended for new setups. |
| Launch Templates |
Newer, AWS-recommended method. |
More flexible. |
Supports multiple versions for easy updates, allowing creation of subsets of parameters and reuse. |
Supports advanced options: Spot instances, T2/T3 unlimited instances, Elastic Graphics, multiple instance types in a single ASG, on-demand, and spot capacity in the same target group. Required for Amazon EC2 Dedicated Hosts. |
Networking information cannot be included in launch templates if they will be used in auto scaling groups. |
AWS best practice and should be favored over launch configurations. |
Scaling Policies
Scaling policies are rulebooks that dictate when and how to scale, automating the creation and destruction of instances in an Auto Scaling group.
Amazon EC2 Auto Scaling offers various policy types to handle different scaling needs, from predictable load changes to real-time metric responses, often using CloudWatch alarms.
Manual Scaling
Allows you to manually adjust the minimum, maximum, and desired capacity of the Auto Scaling Group. You can manually scale up or down with the AWS console.
Use Cases:
- Simple, ad-hoc adjustments
- Initial setup
Scheduled Scaling
Allows you to plan scaling actions in advance based on predictable traffic patterns. You specify a particular time period during which resources should scale up or down to accommodate predictable load changes.
Use Cases:
- Increase capacity on weekdays from 9 AM to 5 PM
- Seasonal events
Dynamic Scaling
Scales automatically in response to real-time changes in metrics, such as CPU utilization. This type of scaling uses CloudWatch alarms.
Use Cases:
- Responding to fluctuating demand
Target Tracking Scaling
The most common and easiest dynamic scaling policy to set up. You set a target metric (e.g., average CPU utilization at 50%), and Auto Scaling adjusts the instance count to stay near that target. It works like a thermostat maintaining a constant temperature.
Use Cases:
- Maintaining a specific average CPU utilization
- Consistent application performance
Step Scaling
Scaling happens in steps based on how far a metric is from a threshold, allowing for more granular control. It adjusts the capacity based on the severity of a metric breach, using a set of step adjustments.
Use Cases:
- Aggressive scaling for severe metric breaches
Simple Scaling
An older dynamic scaling method with a single threshold and action. It is less flexible as it can only perform one action per alarm. It adjusts the capacity by a fixed number of instances, with a cooldown period between each scaling activity.
Use Cases:
- Basic, single-action responses to metric thresholds
Predictive Scaling
Uses machine learning to forecast future traffic based on historical data and schedules scaling actions proactively. It's more flexible and can adapt to changes in traffic patterns, helping to ensure enough resources are available before peak traffic without causing latency issues.
Use Cases:
- Proactive capacity adjustment for predictable, yet complex, traffic patterns (e.g., weekday spikes, weekend drops)
Maintain Current Instance Levels
Ensures that no instances are added unless an instance fails its health checks and needs to be restarted or replaced.
Use Cases:
- High availability for critical resources where only a single instance should run unless it fails
Instance Health and Lifecycle Management
EC2 Auto Scaling continuously monitors instance health and manages their lifecycle, including termination and replacement, to maintain group stability and availability.
Robust health checks, configurable termination policies, and protective measures like scale-in protection and lifecycle hooks ensure instances meet performance and availability standards.
Instance Health Checks
Amazon EC2 Auto Scaling regularly checks the health of instances. Unhealthy instances are terminated and replaced. Load balancers (ALB, NLB, Classic Load Balancer) can perform health checks on backend EC2 instances; if an instance fails a health check, the load balancer marks it as unhealthy. The Auto Scaling group then launches a replacement instance, and the unhealthy instance is removed from the target group. This process helps maintain the desired capacity and ensures application availability.
Types
Amazon EC2 status checks (default), Elastic Load Balancing (ELB) health checks, Custom health checks.
Health Check Grace Period
Minimum time a new instance is kept in service before termination. Default 300 seconds in console, 0 seconds with AWS CLI/SDK. Applies to newly launched, put back in service, and manually attached instances. If an instance is no longer in 'running' state during grace period, it's immediately marked unhealthy and replaced.
Termination Policies
Policies with termination criteria are used to determine which instances are terminated first during scale-in events. This defines which instances are terminated first during a scale-in event (e.g., OldestInstance, NewestInstance, OldestLaunchTemplate, ClosestToNextInstanceHour).
Default Termination Policy Behavior
1. Determine which Availability Zones have the most instances, and at least one instance that is not protected from scale in. 2. Determine which instances to terminate so as to align the remaining instances to the allocation strategy (for ASGs that specify allocation strategies). 3. Determine whether any instances use the oldest launch template or configuration (Launch Configurations terminated before Launch Templates). 4. After other criteria, if multiple unprotected instances remain, terminate those closest to the next billing hour; if still multiple, terminate one randomly.
Custom Termination Policies
Option to choose or create your own termination policies.
Instance Scale-in Protection
Prevents instances from being terminated during scale-in events. Can be enabled on creation or changed on running instances. If enabled on an existing group, all new instances launched thereafter will have it enabled.
Limitation
Does not prevent manual termination. For accidental termination, use Amazon EC2 termination protection (which doesn't prevent unhealthy checks or accidental group deletion).
Lifecycle Hooks
Allow you to perform actions before an instance is launched (scale-out) or terminated (scale-in). This is useful for tasks like software updates or data backups.
Auto Scaling Cooldown and Warmup Periods
These periods are critical to prevent overreaction to metric fluctuations and ensure system stability during scaling events.
A period of time after an auto-scaling action (adding or removing an instance) during which no further scaling actions are triggered. Its purpose is to prevent rapid or repetitive scaling due to quick metric fluctuations and to give newly launched instances time to start up and stabilize, ensuring metrics reflect true system load. It prevents the Auto Scaling group from launching or terminating additional instances before the effects of previous activities are visible.
Technical Specs: Default Cooldown: Applied automatically to all scaling actions. Custom Cooldown: User-defined. Default value for simple scaling policies is 300 seconds (5 minutes) if not provided. Honored by simple scaling policies, but not other scaling policies or scheduled scaling.
A period after an instance launch during which its metrics are ignored for scaling decisions. This allows time for new instances to become fully operational before they are considered in metric calculations. It primarily applies to Step Scaling.
Technical Specs: Significantly impacts the immediate effect of scaling actions; new instances are not immediately counted. Example: One instance is added, but the total instance count remains unchanged until the warmup period ends.
Integration with Other AWS Services
EC2 Auto Scaling integrates seamlessly with other AWS services to build robust, scalable, and highly available architectures.
These integrations ensure dynamic capacity management, intelligent traffic distribution, and comprehensive monitoring.
Elastic Load Balancing (ELB)
ELB acts as a 'traffic cop' to distribute incoming requests across multiple backend instances within an Auto Scaling Group, preventing single instances from becoming overloaded and creating bottlenecks. It improves both performance and availability by performing health checks and routing traffic only to healthy instances. Load balancers work in conjunction with Auto Scaling groups to manage capacity dynamically, enabling zero-downtime deployments and eliminating the need for static IPs for varying server counts.
Process Flow
1. User requests application. 2. ALB intercepts request. 3. ALB distributes traffic to EC2 instances within ASG.
Health Check Functionality
Load balancers perform health checks; unhealthy instances are marked, ASG launches replacement, unhealthy removed from target group.
Amazon CloudWatch
CloudWatch monitors EC2 instance metrics (CPU, memory, network, etc.) and is a critical tool for monitoring and adjusting desired capacity based on scaling policies. If a metric crosses a predefined threshold, CloudWatch triggers an alarm which then notifies the relevant Auto Scaling policy, instructing the Auto Scaling group to perform a scaling action.
Role in Scaling
Triggers scaling actions based on specified metric thresholds.
Best Practice
Use a 1-minute frequency for CloudWatch metric data collection for faster response times. Turn on Auto Scaling Group metrics for accurate capacity forecasting.
Amazon Route 53
Route 53 is a highly available DNS service that directs users to applications. While it doesn't directly scale EC2 instances, it plays a crucial role in directing user traffic to Elastic Load Balancers, which then distribute traffic to instances within Auto Scaling Groups, thus contributing to a highly available and scalable architecture.
Amazon Simple Queue Service (SQS)
For applications handling consumer orders in an SQS queue, Auto Scaling can use a target tracking scaling policy based on a custom Amazon SQS queue metric (backlog per instance metric). This allows dynamic scaling to adjust to the application's demand curve more effectively. The backlog per instance is calculated by dividing ApproximateNumberOfMessagesVisible by the number of instances in the InService state for the Auto Scaling group.
Autoscaling Demonstration: Setup and Configuration
procedure
This section details the process of setting up and demonstrating EC2 autoscaling, including the creation of necessary AWS resources and simulating various scenarios.
The primary goal is to show how EC2 instances automatically scale based on demand and health checks by configuring a Launch Template, Auto Scaling Group, Target Group, and Application Load Balancer.
1
Create Launch Template
Defines the configuration for new EC2 instances launched by the autoscaling group.
2
Create Autoscaling Group
Manages the collection of EC2 instances, ensuring a desired number are running and scaling as needed.
3
Observe Initial Instance Launch
Verify that the autoscaling group launches instances based on the desired capacity, making the web application accessible.
4
Create Target Group
Routes traffic to registered targets (EC2 instances) and configures health checks.
5
Create Application Load Balancer (ALB)
Distributes incoming application traffic across multiple targets and links to the target group.
6
Update Autoscaling Group to Attach ALB
Integrates the ASG with the ALB to enable traffic distribution and load balancer-based health checks.
7
Access Application via ALB's DNS Name
Confirm that traffic is correctly routed through the ALB to the backend instances managed by the ASG.
8
Simulate Outage Scenario
Demonstrates the ASG's fault tolerance by stopping an instance, detecting unhealthiness, and automatically launching a replacement.
9
Simulate Instance Recovery
Shows how the ASG manages capacity when a stopped instance is restarted and becomes healthy again, terminating redundant instances.
Best Practices and Cost Optimization
Implementing best practices and cost-effective strategies is crucial for efficient and reliable EC2 Auto Scaling deployments.
Prioritize high availability by spreading resources across at least two Availability Zones. Favor horizontal scaling over vertical scaling. Get ahead of predictable workloads by spinning up instances in anticipation of spikes. Bake everything inside of the AMI to reduce instance provisioning time. Turn on Auto Scaling Group metrics for accurate capacity forecasting.
Technical Specs: Use a 1-minute frequency for CloudWatch metric data collection for faster response times. Avoid burstable performance instance types (like T2 and T3) to prevent performance limitations.
Thrashing occurs when instances are constantly added and removed due to rapid fluctuations in metrics. To prevent this, configure alarms to trigger only after a sustained period of metric breach (alarm sustain period), implement a cooldown period after a scaling event (for Simple Scaling), and allow for an instance warmup period for newly launched instances to become operational before their metrics affect scaling decisions (for Step Scaling).
To minimize EC2 costs for applications with predictable baseline usage and variable spikes, use Reserved Instances (RIs) for the baseline and Spot Instances for additional capacity. RIs offer significant savings for steady, predictable loads, while Spot Instances are highly cost-effective for fault-tolerant, interruptible workloads.
Technical Specs: RIs offer up to 72% discount. Spot Instances offer up to 90% discount.
A steady-state Auto Scaling Group has its minimum, maximum, and desired capacity all set to 1. This configuration is suitable for highly available critical resources that cannot have multiple copies or for legacy resources where only one resource can be online at a time.
Technical Specs: min, max, desired capacity all set to 1
If an instance needs troubleshooting, you can put it into Standby mode. This allows the group to scale up if needed, and then you can troubleshoot the instance. Once troubleshooting is complete, you can put it back into the InService state.