Over a million developers have joined DZone.

Set Up AWS Autoscaling

· Cloud Zone

Download this eBook outlining the critical components of success for SaaS companies - and the new rules you need to play by.  Brought to you in partnership with NuoDB.

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=https://ec2.eu-west-1.amazonaws.com

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="http://autoscaling.amazonaws.com/doc/2011-01-01/">

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.

Learn how moving from a traditional, on-premises delivery model to a cloud-based, software-as-a-service (SaaS) strategy is a high-stakes, bet-the-company game for independent software vendors. Brought to you in partnership with NuoDB.


Published at DZone with permission of Pascal Alma, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}