Release: Auto Scaling on 2010-12-02
This release includes support for scheduled actions, suspendable processes, scaling policies, Amazon Virtual Private Cloud, and Amazon CloudWatch alarms.
||With this version, you can now schedule scaling actions up to 31 days in advance.
|Amazon Virtual Private Cloud Support
||You can now use Auto Scaling with your Amazon Virtual Private Cloud (VPC). Specify your VPC with the new VPCZoneIdentifier parameter that is available for both the CreateAutoScalingGroup and UpdateAutoScalingGroup actions.
|Explicit Instance Health
||Instances now have an explicit health field, and customers can manually mark an instance as unhealthy.
|High Performance Computing (HPC) Cluster Support
||Auto Scaling now supports high performance computing (HPC) clusters.
|Integration with Elastic Load Balancing Health Check
||You can now use Elastic Load Balancing Health Check as the health check for Auto Scaling managed EC2 instances.
|Integration with CloudWatch Alarms
||Trigger functionality has been redesigned to work with the CloudWatch alarm feature. A trigger is now a combination of a CloudWatch alarm and an Auto Scaling policy.
|Integration with CloudWatch Metrics
||Auto Scaling can now launch instances with either basic or detailed Amazon CloudWatch monitoring. Auto Scaling can also send group metrics to Amazon CloudWatch.
|Suspend and Resume Processes
||You can now suspend and resume specific scaling processes.
|User Management Integration
||Auto Scaling now integrates with Amazon Identity and Access Management (IAM).
For more information about IAM, go to http://aws.amazon.com/iam.
|We no longer allow the ":" character in the name of any object.
||You can no longer use the ":" (colon) character in the name of any object. This includes Launch Configurations, Auto Scaling groups, Policies, and any other named object.
|The "Cooldown" parameter is now called "DefaultCooldown."
||The "Cooldown" parameter for the CreateAutoScalingGroup and UpdateAutoScalingGroup actions is now named "DefaultCooldown."
IMPORTANT: If you are upgrading from a previous version, please be sure to update any calls that involve this parameter. Although the CLI and the SOAP protocol will return an error if you do not rename this parameter, the Query protocol will silently ignore the misnamed parameter.
|Trigger functionality has been redesigned to work closely with CloudWatch alarms.
||You no longer create triggers with a single call to CreateOrUpdateTrigger.
Instead, you create a trigger by combining two AWS features: a CloudWatch alarm (configured to watch a
specified CloudWatch metric) and an Auto Scaling policy that describes what should happen if the alarm
threshold is crossed. In most cases, you will need two triggers—one trigger for scaling up and another
for scaling down.
|Migrating legacy triggers.
||Auto Scaling does not permit using both a legacy trigger and the new alarms-based scaling system on an Auto Scaling group. To use the new scaling system you will have to migrate any legacy triggers to the new system. For detailed instructions on how to migrate legacy triggers, go to the following thread in the Amazon Web Services Discussion Forums: Migrating legacy Auto Scaling Triggers to the new, CloudWatch Alarm based scaling system.
||Auto Scaling might, at times, suspend processes for Auto Scaling groups that repeatedly fail to launch instances. This is known as an "administrative suspension," and most commonly applies to Auto Scaling groups that have zero running instances, have been trying to launch instances for more than 24 hours, and have not succeeded in that time in launching any instances. To resume processes, whether the suspension was manual (using SuspendProcesses) or administrative, use either the ResumeProcesses API action or the as-resume-processes CLI command.