Usage of Amazon Auto Scaling to reduce costs of the project’s hosting service


It often happens that the costs of the project’s hosting service are higher than its other living expenses. It specifically refers to those projects using Amazon AWS extensively. But far from everyone knows that Amazon delivers various means to allow its users to pay less for the use of AWS services.

What Auto Scaling is and how it works

Auto Scaling is an Amazon technology which allows increase/decrease the number of your instances in EC2 depending on the set conditions: instance loads, traffic volume, etc. Thus you can always be sure that your project is going to live even with fast traffic growth, and even in the case of minimum number of visitors no cent is going to be wasted on idle capacities.

So, the basic advantages for the use of Auto Scaling are the following:

  • Less damage from malfunctioning instance. Auto Scaling can identify a malfunctioning instance, delete it and then run a substitute for the deleted one.
  • The operational scheme will be more fail-safe. Auto Scaling can be configured to use several subnetworks or Availability Zones. Thus, if one of the networks or an Availability Zone goes off-line, the Auto Scaling will start creating instances in another one in order to ensure external accessibility of the project.
  • On-demand increase and decrease of the number of instances used. The fact that Auto Scaling is free to use is very important, as you pay only for running EC2 instances.

How does Auto Scaling work? Standard example is provided on pic. 1.

Pic. 1. Auto Scaling example

Pic. 1. Auto Scaling example


We are starting with Auto Scaling Group, the desirable number of instances for which is set 2. The event of instance adding is taking place in the Auto Scaling Group. Auto Scaling receives instructions to launch a new instance within this event. The event can be either schedule planned or arise when CloudWatch events are triggered. After that, a new instance will be created, configured and added to the Auto Scaling Group. The procedure to initiate instance deletion happens just the same way: it is either triggered according to the schedule or based on CloudWatch measures.

Fine details

The Auto Scaling service is tightly connected with such three notions as Groups, Launch Configurations and Scaling Plans. Let’s discuss them a little bit more.

The Auto Scaling combines instances performing equal functions (e.g. www instances only or MySQL only) in order to manage them and increase/decrease their number. In other words, if your application needs to increase the number of instances of a certain type in order to achieve maximum performance, this will be done through the settings of a respective Auto Scaling Group. You can do it manually, you may specify a certain set of conditions according to which the instances will be added/deleted, the number of running instances will be under automated control. As previously mentioned, Auto Scaling can check for the “health” of each instance. If Auto Scanning deems an instance from any Auto Scaling Group “unhealthy” then it will be destroyed with a substitute instance created.

Launch Configuration is a total of parameters (such as ID image, instance type, SSH keys, security groups and block device mapping) which explicitly describe configuration of an instance to be created with the use of this Launch Configuration. When you create an Auto Scaling Group you need to bind it up with an existing Launch Configuration. An important aspect: No modifications can be introduced into Launch Configuration after it has been created. In other words, if you need new instances with some new parameters (e.g. redesigned AMI), then it is necessary to create a new Launch Configuration. After that you shall indicate a new Launch Configuration in the Auto Scaling Group settings, so new instances will be created with new settings. Old instances will not be modified.

The Scaling Plan can be used to indicate Auto Scaling and the conditions for creation of additional instances or deletion of the unnecessary ones.

Use of Auto Scaling

One shouldn’t think that the use of Auto Scaling under a project is another step to in-house system manager dismissal. 🙂 In fact there are some problems which are specific for Auto Scaling. Here I’m going to list some of those we had to face:

  1. Very long periods for deletion of old records out of ARP cash for those instances which interact with Auto Scaling instances. The default values were too high for us. It was stated in the following: Auto Scaling instance with IP was deleted twenty minutes ago. ARP cash within the MySQL server has reserved a record where IP is expressively bound to a specific MAC address. A new Auto Scaling instance with IP but another MAC address was created five minutes ago. Can you guess what came off in the end? Correct, due to the fact that ARP cash on the MySQL server wasn’t updated on time, we lost connection between www and MySQL as the packages from the MySQL server came to the old MAC address. It was settled through settings adjustment, decrease of time out for ARP cash clearing, but the situation wasn’t nice at all.
  2. The time for auto scales creation should be minimum. Creation of a Launch Configuration based on a reconfigured AMI is a very much of help here. From our experience: it is worth creating AMIs which will contain not only software with specific settings but also latest code review for large-scale projects. It allows the Auto Scaling instance to receive and process requests from visitors right after the operation system has been loaded. But the creation time of an auto scale is rather long and takes about five to ten minutes, then this may affect negatively the project’s performance. It matters especially when the customer’s advertising campaign has just started and produced a steady flow of visitors which is thrice bigger than a normal flow for this time and day of week.
  3. Fine adjustment for conditions where a new Auto Scaling instance will be created. Initially when working with Amazon Auto Scaling we faced this problem: when we found out that the conditions which we specified for Amazon to define necessity to create new auto scales when seeming correct are in fact far from reality. We didn’t take into account how long it takes to create one instance, the time during which the load on the existing instances jumped from “above the average” to “extra high” and some other minor details. As a result it took us several days to polish correct conditions for Auto Scaling.

These problems were principal. Sometimes small but annoying cases happen, e.g. recently we couldn’t assemble a new AMY with some adjustments due to problems on the side of API Amazon, which delayed compilation of a new issue in production.

When using Auto Scaling, such aspect as total monitoring for the created auto scales is very important. And it’s crucial that the instances are connected to the monitoring system automatically right after they have been created: with high values of project attendance several dozens of auto scales can be created / deleted every day, and it’s going to be difficult to add each of them to the monitoring system manually. The reason for monitoring is simple: once in a while an incorrect new auto scale is created. The code functions with errors, the connections to necessary addresses won’t come through. In such situations it’s necessary to exclude such instances from the Load Balancer once they have been detected. This should be done in order to prevent visitor requests to be directed to them.


Automation of a system manager’s work has always been a vital task. At first it included bash scripts, but then the level rose to implementation of tools of server setup automation, such as Puppet/Chef/CfEngine. Nowadays, a new level has appeared to life, which is called management automation for server hardware.

Yes, the hardware is virtual in this case, but now we have the opportunity to create virtual servers with higher capacity than most existing physical ones. Amazon Auto Scaling is a spectacular example of the technology which allows automated management of the servers engaged in your project performance with the help of convenient and flexible interface. One also should not forget that with Auto Scaling your company can save thousands of dollars on project hosting, which is a rather important aspect itself.

See you next time! Later we are going to talk about another technology that can help us make our life better. 🙂

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">