Auto Scaling is a key
AWS service. You can use it to build
resilient, highly scalable applications that react to changes in load by
launching or terminating Amazon EC2 instances as needed,
all driven by
system or user-defined metrics collected and tracked by
Today we are enhancing Auto Scaling with the addition of three
features that give you additional control over the EC2 instances
managed by each of your Auto Scaling Groups. You can now exercise
additional control of the instance launch and termination process using
Lifecycle Hooks. You can remove instances from
an Auto Scaling Group and you can now put instances into the new
Standby state for troubleshooting or maintenance.
Lifecycle Actions & Hooks
Each EC2 instance in an Auto Scaling Group goes through a defined set of
states and state transitions during its lifetime. In response to a Scale Out Event, instances are
launched, attached to the group, and become operational. Later, in response to a
Scale In Event, instances are removed from the group and then terminated. With today’s
launch we are giving you additional control of the instance lifecycle at the following
- After it has been launched but before it is
attached to the group (Auto Scaling
calls this state Pending). This is your opportunity to
perform any initialization operations that are needed to fully
prepare the instance. You can install and configure software,
create, format, and attach EBS volumes, connect the instance to
message queues, and so forth.
After it has been detached from the group but before it has been
terminated (Auto Scaling calls this
state Terminating). You can do any additional
work that is needed to fully decommission the instance. You can
capture a final snapshot of any work in progress, move log files
to long-term storage, or hold malfunctioning instances off to the
side for debugging.
You can configure a set of Lifecycle actions for each of your Auto Scaling Groups. Messages
will be sent to a notification target for the group (an SQS queue or an
SNS topic) each time an instance enters the Pending
or Terminating state. Your application is responsible for
handling the messages and implementing the appropriate initialization or
After the message is sent, the instance will be in the
Pending:Wait or Terminating:Wait state, as appropriate.
Once the instance enters this state, your application is given 60 minutes to
do the work. If the work is going to take more than 60 minutes, your application can
extend the time by issuing a “heartbeat” to Auto Scaling. If the time (original
or extended) expires, the instance will come out of the wait state.
After the instance has been prepared or decommissioned, your application must tell Auto Scaling
that the lifecycle action is complete, and that it can move forward. This will set the state of the
instance to Pending:Proceed or Terminating:Proceed.
Create or update a lifecycle hook for an Auto Scaling Group. Call this function to create a hook that
acts when instances launch or terminate.
Signify completion of a lifecycle action for a lifecycle hook. Call this function when your hook
has successfully set or up decommissioned an instance.
Record a heartbeat for a lifecycle action. Call this function to extend the timeout for a lifecycle
You can now move an instance from the InService state to the
Standby state, and back again. When an instance is
standing by, it is still managed by the Auto Scaling Group but it is
removed from service until you set it back to
the InService state. You can use this state to
update, modify, or troubleshoot instances. You can check on the state
of the instance after specific events, and you can set it aside in order
to retrieve important logs or other data.
If there is an Elastic Load Balancer associated with the Auto Scaling Group,
the transition to the standby state will deregister the instance from the Load Balancer.
The transition will not take effect until traffic ceases; this may take some time if
you enabled connection draining for the Load Balancer.
You can now remove an instance from an Auto Scaling Group and manage
it independently. The instance can remain unattached, or you can attach
it to another Auto Scaling Group if you’d like. When you call the
function, you can also request a change in the desired capacity for the group.
You can use this new functionality in a couple of different ways. You can move
instances from one Auto Scaling Group to another to effect an architectural change or update.
You can experiment with a mix of different
EC2 instance types, adding and removing instances in order to find the best
fit for your application.
If you are new to the entire Auto Scaling concept, you can use this function to do
some experimentation and to gain some operational experience in short order. Create a new Launch Configuration using the
and a new Auto Scaling Group using
supplying the Instance Id of an existing EC2 instance in both cases. Do your testing
and then call
take the instance out of the Auto Scaling Group.
You can also use the new detach functionality to create an “instance factory” of sorts. Suppose
your application assigns a fresh, fully-initialized EC2 instance to each user when they log in.
Perhaps the application takes some time to initialize, but you don’t want your users to wait
for this work to complete. You could create an Auto Scaling Group and set it up so that it
always maintains several instances in reserve, based on the expected login rate. When a user
logs in, you can allocate an instance, detach it from the Auto Scaling Group, and dedicate
it to the user in short order. Auto Scaling will add fresh instances to the group in order
to maintain the desired amount of reserve capacity.