Cloud Zone is brought to you in partnership with:

Pascal is a senior JEE Developer and Architect at 4Synergy in The Netherlands. Pascal has been designing and building J2EE applications since 2001. He is particularly interested in Open Source toolstack (Mule, Spring Framework, JBoss) and technologies like Web Services, SOA and Cloud technologies. Specialties: JEE XML Web Services Mule ESB Maven Cloud Technology Pascal is a DZone MVB and is not an employee of DZone and has posted 56 posts at DZone. You can read more from them at their website. View Full User Profile

Set Up AWS Autoscaling

01.21.2013
| 6274 views |
  • submit to reddit

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-1.6.5.2
    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/">
  <ResponseMetadata>
    <RequestId>7f8d7f70-573c-11e2-8113-3701f4cd9944</RequestId>
  </ResponseMetadata>
</CreateAutoScalingGroupResponse>

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.

Published at DZone with permission of Pascal Alma, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)