Start Using Auto Scale Today

Today we launched Auto Scale, one of the most exciting new features of the Rackspace Cloud. Auto Scale is the easiest way to make your Rackspace Cloud react automatically to changes in the demand your users place on your application. By creating a few simple rules based on thresholds that you define and control, you let us know when and how to grow (or shrink) the web or application tiers in your cloud.

What can I do with Auto Scale?

With Auto Scale you can:

  • Deliver the best experience to your users: Your application can automatically add new servers to meet unexpected levels of demand.
  • Save money: Automatically remove servers when the load on your app is lower and servers are no longer needed. No need to over-provision.
  • Have peace of mind: Automate the tasks that you have to do manually today to reduce errors and focus on your application.

Using Auto Scale in the Cloud Control Panel

In this blog, I will walk you through the process of using Auto Scale. While using the API is probably what most developers will use, one of the advantages of our Auto Scale implementation is that it is really simple to use from the Control Panel. Let’s take a look.

Let’s assume I have a website and my web tier is based on the Performance 1 flavor of Performance Cloud Servers with a 1GB size.


Additionally, let’s assume I have my server fully configured, its content and code in place, and I have created an image of it. My image is called “MyWebServerImage” and it already exists.

Sign in to Control Panel. The first thing you will notice is the “Auto Scale” menu option on the right. Click on it and you will get to Auto Scale.


Auto Scale Groups

The first concept we will learn about is the Auto Scale Group, or scaling group. This scaling group refers to the set of servers that will shrink and grow, and their configuration. Click on the “Create Group” button and let’s take a look at it.

I will call my group “MyAutoScaleGroup” and select ORD for my region. I will also select a one hour cooldown period, as well as state the minimum and maximum number of servers I need for my web tier. I will explain the cooldown period below.

Let’s focus now on the configuration section of the scaling group. The configuration is composed of four elements:

  • We need to select the server image we will use to scale and provision new servers
  • We will also inform Auto Scale of the server flavor we will use when provisioning those servers
  • We will select the networks that new servers need to be configured with
  • Finally, we will also select the load balancer that the new servers need to be attached to

Let’s go ahead and click on “Select Image.”

Notice the “MyWebServerImage” that I had mentioned above. I simply select that and click on “Save Image.”

See below how simple it is to select your size, networks and load balancer.

Scaling policies

Let’s now talk about the second important concept of Auto Scale: the scaling policy. Scaling policies are essentially rules that tell Auto Scale how and when you want it to act. Think about scaling policies as the commands or orders you want Auto Scale to follow. Remember that the role of Auto Scale is only to do what you tell it to: you are in control. Let’s take a look. First, click on the “Create Policy” button.

A scaling policy is generally defined by the kind of trigger that would be used and the action to take (defined as a number of servers that will be added or removed from the scaling group).

For this scenario, let’s assume that my web site is really only used during the week, but not really used by that many customers during the weekend. To save money, I would like to shrink my tier ahead of the weekend, but be ready and grow it ahead of Monday. For these two policies, I will use the “cron” trigger, which is very flexible.


I will create two scaling policies:

  • One for Friday evening when I know my traffic starts to slow down. Since Auto Scale uses the UTC timezone for times, I am going to call this policy “SAT-1AM-DOWN” and configure it to remove six servers at 1 a.m. UTC. I am using the handy cron expression helper to generate the “00 1 * * 6” string to indicate that this policy should run “Every Saturday at 1 a.m.” The number 6 represents Saturday, while the 00 and 1 represent the time, in minutes and hours, when the trigger will fire.
  • One for Sunday afternoon, called “SUN-11PM-UP” when I know my traffic starts to ramp up.  “00 23 * * 7” is the string that tells Auto Scale that the policy runs “every Sunday at 11 p.m.” Sunday is represented by the number 7 in the string, while 11:00 p.m. is represented as “00 23”.

Again, notice the times are in the UTC timezone.

We’ll save the first policy. You can see it below. Let’s create our second policy.

Notice how I elected to scale by 6 servers (see the “Amount” setting) for both the up and down policies. This allows me to shift from 14 to 8 servers and back during the weekends (since we used 8 and 14 as the minimum and maximum number of servers in the definition of the Scale group above).

At the end of this step, both scaling policies look like this:

 We are done configuring our scaling group. At this time, we just click the “Create Scaling Group” button, and Auto Scale will get to work.

Server creation

The first thing you will notice is that servers start being created immediately. See below.

Notice the server naming convention, which uses our Scaling Group name, a dash and a random set of characters. During this time, you will see the Scaling Group in “Scaling” state:

Obviously, you can also see the servers listed on your Cloud Servers section. While you may be tempted to act on these servers directly (for example, to delete them), don’t do it. Use the Auto Scaling rules to modify the number of servers you want available. You can, for example, set the minimum and maximum number of servers to zero to remove them all. At this time, deleting the scaled servers outside of the Auto Scale group is not supported as Auto Scale will not, as of today, be aware of those deletions. We are working to improve on that.

Now, wait a few moments and you will see all the servers created relatively quickly (courtesy of the new and improved Performance Cloud Servers flavors!).

At that point the Scaling group state will turn to “Active” as seen below.

We are done!

Final comments

Let me just add a few final comments. First, let’s explain the cooldown period. As your scaling policies increase in sophistication, it is possible that you may be telling Auto Scale to perform complex operations that take some time. During that time, it is possible that another scaling policy needs to be triggered based on your rules. The cooldown period avoids that collision, and makes sure that an action stabilizes before executing another one.

Second, please notice that the maximum set of servers you can provision may be limited by your account. For example, here at Rackspace every Racker gets a little bit of money to develop on our cloud. Well, I clearly did not have a huge amount of money in one of my test accounts! When that happened, the servers just were not being created. But that is a whole different issue that I am taking on with the Finance department. Just be aware of that and reach out to our Support teams if you want to expand those limits for your test and development accounts. Your account may be tapped at 100 servers, or 60GB to 130GB of total size for Cloud Servers.

Third, make sure you have your load balancer properly configured and in active state. If that is not the case, the servers will also be deleted. This avoids you having to pay for servers you are not really using. Also, remember that the default limit for Cloud Load Balancers is 25 server connections, so for complex designs you will need to connect multiple load balancers in cascade.

Finally, in this blog we did not cover other scenarios for Auto Scale: using scheduled policies, or using Cloud Monitoring metrics to trigger them, or using the API. Be sure to explore our development docs.

Go ahead and start exploring Auto Scale, and as usual, reach out to me @jrarredondo and let me know what interesting apps you are working on.


  • Eric Pardee

    I wouldn’t really call this an example scenario of Auto Scaling, more like Proactive Scaling, i.e. scaling to meet your anticipated demand by understanding your traffic patterns. I like that Rackspace has an GUI out the gate though.

  • Stuart

    I would find far more useful is if we could scale an instance’s resources instantly rather than spinning up more servers. E.g. have an instance increase its own allocation of RAM/CPU/DISK etc. I have set this up on my own hardware with OpenVZ, which is quite easy and takes < 1 second since its actually a "container".

    It seems that most cloud providers are steering away from this or only partially implementing. AWS lets you scale an RDS fairly well, but not EC2 instances. D.O. lets you scale RAM/CPU, but not disk, which is the only thing its really missing.

  • Hi, I would like to know what is the best to handle code sync with auto scale server, from master server to the scaled ones.
    Thank you!

  • stanzikratel

    Hi Federico,

    I ran your question by the AutoScale dev team and they came up with the following suggestions:

    1. Use custom server image that, when it boots up,
    talks to a well-known job server, from which the slave receives its role
    and configures itself accordingly.

    2. OpenStack has an ability to place custom shell
    scripts that execute up bootup on servers that are spun up; these scripts are
    called “personalities.”

    3. Create specialized images for the spawned
    servers, and adjust your launch configuration over time as it’s needed. This requires
    a bit more pre-planning (you have to take the time to build each kind of image
    you need), but it’s probably the simplest approach to take, and definitely
    results in the fastest start-up time for new servers (no need to automatically
    install dependencies on first boot, no need for “first boot”
    detection logic to back it, etc.).


    – Create a “master” server that is outside of the AS group.
    – Configure the master server accordingy.
    – Create a server image and create the AS Group
    – Install Lsyncd on the master
    – Install the lsync-rsautoscale script (
    – Set up a cron job on master to run the script every minute

    The lsync-rsautoscale script is a
    Python script. You pass it the Rackspace cloud account credentials and the
    AS Group ID and it will use Jinja to generate the Lsyncd config file.

    I hope one of these options works for you.



    Information Developer at Rackspace