May 2012
« Apr   Jun »

Amazon EC2 Auto scaling :- Some Concerns and Feasibility

This is the one of the awesome features of Amazon I ever met. This auto scaling feature will automatically add any number of pre-packaged instances whenever the load meets the threshold limit and destroy the instances when system back to normal.

Why do we need to choose auto scaling, What I’m thinking is

1. You have an application which is ready for production move and further development are freezed.

2. Application doesn’t store anything in local disk ie all the updates should be stored in remote database/S3 storage.

3. NFS is a right choice if you wish to keep/update the files shared among diff. instances. Security is a major concern in that case and VPC is best choice to illuminate. One of the interesting thing I found is, none the amazon instance does not have any static private IP. Private IP’s are changing on each boot.

4. you may need to use command line to get this done. So you will have good patient for testing, have to read many article and forums before stat. Amazon does not have any real-time scenario wise example. They still supporting users to depend Rightscale like platform to do the same by costing us additional expense as we have to pay service charge to them even though Amazon charging us in backend.

Each newly created instances are isolated ie ..

a. We can’t bind any application to a private IP.

b. Cant limit NFS/MySQL access over firewall. Opening ports infirewall helps others( to access our servers over private IP. They promoting S3 storage for sharing files 🙂

c. Can’t access any Amazon mapped public IP directly from none of instances 🙂 This is the best sales mechanism that Amazon did. So each instances are completely isolated and we may need to buy/depend more services from them.

I had to use RDS (for remote database access), Loadbalencer ( to switch the diff. instances that are created by auto scale), Route53 ( only way to add the CNAME record associate with root domain), S3 for uploading and sharing files and Cloudwatch service to setup Alarms to work Auto scaling effective. All 4 are chargable except auto scaling:-)

Total services used : 4 Services and Technology involved are,

a. RDS
b. Elastic Loadbalencing
c. Route53
d. S3 storage
e. CloudWatch How brilliant Amazon guys are 🙂 Well done !!!

ie Godaddy won’t allow users to set ‘@’ to be an ‘CNAME” record and only allow you to set ‘A’ type host record which pointing to an IP

There will be lot things that I can be done if each of the private instances have static private IP which would make the process simpler and cost effective to us.

Major Steps involved in a Auto scaling mechanism are,

1. Launch configuration setup.
2. A Loadbalencer setup.
3. Scaling Group creation.
4. Scaling UP policy creation.
5. Scaling Down policy creation.
6. Setting up Alert Up Alarm [Cloudwatch API] note free 🙂
7. Setting Down Alert Alarm [Cloudwatch API].
8. Route53 DNS setup.

1 comment to Amazon EC2 Auto scaling :- Some Concerns and Feasibility

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>