Release: Auto Scaling on 2012-01-26

Release Notes>Amazon EC2>Release: Auto Scaling on 2012 01 26
This release of Auto Scaling adds support for tagging of Auto Scaling groups.


Release Date: January 26, 2012 11:00 PM GMT
Latest Version: 2011-01-01
Latest WSDL:
Created On: January 27, 2012 11:31 PM GMT
Last Updated: January 31, 2012 2:38 AM GMT

New Features

Tagging Auto Scaling Groups and Amazon EC2 Instances

You can now tag Auto Scaling groups with your own metadata. You can also apply these tags to Amazon EC2 instances that the Auto Scaling group launches. For more information, see Tagging Auto Scaling Groups and Amazon EC2 Instances.

Version History

Release Date WDSL Description
2011-12-20 2011-01-01.AutoScaling.wsdl Support for multiple Amazon Virtual Private Cloud subnets within a single Auto Scaling group.
2011-07-25 2011-01-01.AutoScaling.wsdl Support for Amazon SNS notifications, the ability to set up recurring scaling activities, and more.
2010-12-02 2010-08-01.AutoScaling.wsdl Support for scheduled actions, suspendable processes, scaling policies, Amazon Virtual Private Cloud, and Amazon CloudWatch alarms.
2010-04-10 2009-05-15.AutoScaling.wsdl Support for Asia Pacific (Singapore) Region.
2010-03-22 2009-05-15.AutoScaling.wsdl New AWS SDK for Java
2009-12-02 2009-05-15.AutoScaling.wsdl Support for new US-West (Northern California) Region.
2009-11-11 2009-05-15.AutoScaling.wsdl New SDK for .NET.
2009-05-18 2009-05-15.AutoScaling.wsdl Initial public beta release of Auto Scaling.

To view earlier Release Notes, please see

Known Issues

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.

Administrative suspensions. 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.
©2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.