autoscaling 3.3 spec

Table of Contents Overview Types of Scaling Autoscaling Components Launch Configuration Auto Scaling Group Auto Scaling Policy Cloud Watch Alarms Scaling Activity IAM IMPLICATION EC2 IMPLICATION ELB IMPLICATION Scaling Processes Health Check Policy Scheduled Questions

Overview

Automatically Scale Server Farms Scale Up/Down (Re)Balance Across AZs Add/Remove from ELB Scaling Thermostat

Types of Scaling

Manual Send an API call or use CLI to launch/terminate instances Only need to specify capacity change (+/-) By Schedule Scale up/down based on date and time By Policy Scale in response to changing conditions Based on user configured real-time monitoring and alerts Health checks and CloudWatch Automatic Rebalance Instances are automatically launched/terminated to ensure the application is balanced across multiple AZs

Autoscaling Components

Launch Configuration

• Describes how to add instances instances
  • AMI
  • Instance Type
  • Security Group
  • Instance Key Pair
• Only one active launch configuration at a time
• Auto Scaling will terminate instances with old launch configurations first
  • Rolling software updates

Auto Scaling Group

Auto Scaling managed grouping of EC2 instances Automatic health check to maintain pool size Automatically scale the number of instances by policy Min, Max, Desired Automatic Integration with ELB Automatic Integration with AZs Automatic distribution & balancing across AZs

Auto Scaling Policy

Parameters for performing an Auto Scaling action Scale Up/Down By how much ChangeInCapacity (+/- #) ExactCapacity (#) ChangeInPercent (+/- %) Cool Down (seconds) Policy can be triggered by CloudWatch Events

Cloud Watch Alarms

Monitors a CloudWatch metric Threshold (> 50% CPU) Period (for 3 minutes) Alarm States OK - Within defined threshold ALARM - Outside defined threshold INSUFFICIENT_DATA - Metric does not have enough data to determine state Available Actions Trigger Auto Scaling Policy (scale up/down event) Send SNS notification

Scaling Activity

Instance Launch Instances are launched (not started) from a “gold” image  Bootstrapping is important!  Automatically added to ELB (if configured) Instance Termination Instances are terminated (not stopped)  Longest running instance from the oldest launch config first  Automatically removed from ELB (if configured) Cooldown The period after an Auto Scaling activity during which no other scaling activity can take place Gives the system time to perform and adjust to before executing a new scaling activity 300 seconds (5 minutes) by default Suspend/Resume Processes Allows you to manually suspend and resume Auto Scaling activities

IAM IMPLICATION

• IAM needs updating to reflect the added keys, actions, resource types from this service
• autoscaling allocates resources on behalf of the user

EC2 IMPLICATION

• tagging

ELB IMPLICATION

• add to scaling group to load balancer (ELBility)

= Scope Limitations

• vpc out
• spot instances out

Scaling Processes

Health Check

Policy

• load generation tools would be needed for test & dev.

Scheduled

Auto Scaling guarantees execution order for scheduled actions within the same group, but not for scheduled actions across groups.

    A scheduled action generally executes within seconds. However, the action may be delayed up to two minutes from the scheduled start time. Because Auto Scaling executes actions within an Auto Scaling group in the order they are specified, scheduled actions with scheduled start times close to each other may take longer to execute.

    You can schedule a scheduled action for up to a month in the future.

    You can create a maximum of 125 scheduled actions per Auto Scaling group. This allows scaling four times a day for a 31-day month for each Auto Scaling group.

Questions

• workload examples; esp. for testing, user story creation
• survival group use case (no dependency)
• scheduled scale-out use case (
• triggered scale-{out,in} use case (cloud watch, sns maybe?)

---

tag:rls-3.3