Set up AWS Autoscaling

In this post I will setup autoscaling for the EC2 WordPress server I created previously. With autoscaling you can tell Amazon to launch or terminate instances based on a set of rules/ conditions. For example if a server has a certain CPU utilization for a certain period you can decide to instantiate an extra instance and put it behind the load balancer so you can spread the load over more machines.

To setup and configure the autoscaling you cannot use the Management Console as this doens’t support it. I will use the command-line interface to set up the autoscaling. To install the command-line tool take the following steps.

  • First install the default EC2 API tools as described here
  • Next download the autoscaling tool from here
  • Unzip the zip file and copy the files in the ‘bin’ and ‘lib’ folders to the corresponding folders in the installation directory of the EC2 API tools.
  • Add the environment variable ‘AWS_AUTO_SCALING_HOME’ and let it point to the installation directory of the EC2 API tool. I added the following line to my ‘.bash_profile’ file:
    export AWS_AUTO_SCALING_HOME=/Users/pascal/develop/ec2-api-tools-
    Don’t forget to reload the profile before you continue.

Now we can use the API tool to setup the autoscaling. Before we do that make sure the existing instances are removed from the load balancer and terminated. Now we can start to setup a Launch Configuration. We need the AMI name of our custom image. To get a list of all the AMI’s owned by me enter the command:

ec2-describe-images -o self

Note: If you don’t see the expected result it might be you are looking in the wrong region. To setup the default region to look in with the command-line tools add the following to you r.bash_profile:
export EC2_URL=

One of the resulting lines looks like:

IMAGE	ami-96d3dfe2	024658091597/Wordpress Image	024658091597	available	private	[marketplace: d9ctq8cuo1svb3v0n02ht2m1k]	x86_64	machine	aki-62695816			ebs	paravirtual	xen

Now I can create the Launch Config with my ami-id by executing the following command:

as-create-launch-config --image-id ami-96d3dfe2 --instance-type t1.micro -–key 4synergy_palma --group "Wordpress Web Tier" --launch-config wp-config --region eu-west-1

The parameters in this command are as follows:

  • Image-id: The AMI name of my personal WordPress AMI
  • Instance: Type The virtual hardware we want to run on. I am using t1.micro here
  • Key: The keypair that you want to use
  • Group: The security group
  • Launch-config: The name of this configuration
  • Region: The region where the autoscaling group is created. Also used to lookup the AMI (wether the EC2_URL is set or not)

With the launch-config created we can create the Autoscaling Group with the following command:

as-create-auto-scaling-group wp-as-group --availability-zones eu-west-1a, eu-west-1b --launch-configuration wp-config --load-balancers WPLoadBalancer --max-size 3 --min-size 2 --region eu-west-1 --show-xml

This should give a response like:

<CreateAutoScalingGroupResponse xmlns="">

That is it. After a few minutes you will receive mails from the SNS we set up when an instance was booted and you will see two instances in the EC2 Console:
Screen Shot 2013-01-05 at 15.16.06
And both instances are registered with our Load Balancer:
Screen Shot 2013-01-05 at 15.29.55
You can see the two instances are now running each in a different availability region to maximize the durability. Now if we destroy one of these instances a few moments later a new one will be instantiated. The next test would be to define rulesets and have a performance testing tool like JMeter to perform some load tests. Another interesting item to show is the use of CloudFormation but I save that for another post.

About Pascal Alma

Pascal is a senior IT consultant and has been working in IT since 1997. He is monitoring the latest development in new technologies (Mobile, Cloud, Big Data) closely and particularly interested in Java open source tool stacks, cloud related technologies like AWS and mobile development like building iOS apps with Swift. Specialties: Java/JEE/Spring Amazon AWS API/REST Big Data Continuous Delivery Swift/iOS
This entry was posted in AWS, cloud and tagged , . Bookmark the permalink.

3 Responses to Set up AWS Autoscaling

  1. zgrega says:

    Your configuration will always have two instances, new instance will be started only if one is e.g. terminated via aws api.
    There are two things missing here:

    – connect autoscaling with ELB health check which will start new instance when e.g. your server is not reachable ( add –health-check-type ELB into auto scaling group cfg)

    – add trigger which will start new instances when some metric is higher than your setting e.g. CPU is higher then 80% and scale down when load is normal


    as-create-or-update-trigger TEST_trigger –auto-scaling-group TEST_auto_scale_grp –namespace “AWS/EC2” –measure CPUUtilization –statistic Average –dimensions “AutoScalingGroupName=TEST_auto_scale_grp” –period 60 –lower-threshold 20 –upper-threshold 80 –lower-breach-increment=-1 –upper-breach-increment 1 –breach-duration 300 –region eu-west-1

    In your configuration you have min instances 2 and max instances 3, which means that you have always two instances up&running If you use trigger mentioned above fires (CPU is more than 80% for 60 seconds) third instance will be fired. Similar is also with scale down.

    • Pascal Alma says:

      Yes, you are correct this post is only to set up the autoscaling. Next step would be to configure the rules like you mention to increase and decrease the instances and test the rules. I have planned that for another post but of course you’re input is very welcome!

  2. Pingback: Amazon ELB and multiple Availability Zones « The Pragmatic Integrator

Comments are closed.