What’s Changed?

Greg Sterling did an excellent post that detail out the major visual changes from the Places to Google+ Local move. But to illustrate, I will use one from my city, Ottawa, Canada (yay, we didn’t get left in the dark for once).

Here, we see that suggested search in Google+ Local is different from the natural Google web search. I’ve confirmed that these suggested searches are not in relation to businesses ranked on the first page of Google under local results, they appear to be randomized and matching only titles with phrase match. For example, if your business does not have “photographers” with an “s” you will not be suggested.

The search under Google+ Local also presents two criteria; keyword and location.  At default, it appears as though Google is using the location you specified under your Google+ Account. Without including a location, it will use your city for the search.

Clicking through one of the results, I arrive at Parent Photography, where they appear to be a very reputable business to get wedding photographs from. On their Google+ Local page, we can see that the visuals are just popping! The page mirrors your Google+ Business Pages, which I suspect will merge with the Local pages as we see here (one of the piloted businesses to use Google+ Local first).

The one thing I noticed appearing on Google+ Local pages that was taken off of Google Places along with the “additional information” was the Hours of Operations. Hmm… makes sense for the to include it. Good job Google

New Rating System

“All scores in Google+ Local are determined by user reviews.”

The new rating system for users is based on a 0-3 point scale (source). The ratings are then averaged and multiplied by 10 to get an average score out of 30, where 0 being the poorest and 30 extraordinary. The rating system is based off of Zagat, which was acquired by Google in September 2011.

“Zagat believes that the shared experiences of large numbers of passionate consumers is inherently more accurate than the opinions of a few critics. Zagat’s editorial team curates user feedback worldwide into concise and unbiased reviews that help people make quick, smart decisions. In addition, consumers rate distinct criteria of an establishment (for example, restaurants are rated for food, decor, and service) on a scale of zero to three, which is then averaged, multiplied by 10 and presented on Zagat’s signature 30-point scale.” Read the Source

Also, looking through 100-1,000 reviews can be tedious and may not answer the question you have in your mind. The sorting feature under the reviews is a useful gadget, which allows you to read reviews by Most Helpful, Latest, Highest Score and Lowest Score.

Another thing I like about the new rating system is how the criteria are broken out into multiple components. For example, restaurants are scored in three areas; food, decor and service. Other businesses will have different options for the review. The benefit of this is it brings in more perspective than a single rate (i.e. what does 2.5/5 stars mean? was the food bad or was it just the service?).

But… the big question will be… will Ratings have any influence on rankings? Please leave your thoughts below.

Closing Thoughts

Google+ Local is an opportunity pool for local businesses to think outside the box and to engage more with their customers online. The layer of social + local will only benefit those who share their passion for great customer service.

But, I think the message is quite clear; Get on Google+! Over and over, I see these messages popping up on blog posts:

• If You’re Not On Google+, You’re Not A Suggestion.
• If you’re not on Google+, you can’t appear in the box.
• If you’re not on Google+ yet, you’re missing out.

Getting on Google+ does not simply mean to create a basic Google+ account and a business page. Instead, focus on developing an approach, think outside the box and start engaging with your customers. Whether you want your brand on social or not, people are talking about you. So jump on board!

I created a checklist of items to watch out for a while back, and I strongly believe they all still apply. The Google+ Local page is another piece to focus on. From an SEO standpoint, optimizing and linking to your Google+ Local page is something to consider as these pages will get crawled and indexed by Google.

Given this is a new roll-out, I would love to hear your feedback on the comments I made above. Please share your thoughts in the comments below.

I love Map My Ride. It’s an Android, iPhone, and Blackberry app which uses your phones GPS to map bike rides, giving you wonderful stats like speed, distance, calories burned, energy outputted, and graphs climbs and elevation. All in all, its an incredibly useful app.

Recently they updated their site and app, increasing user friendliness and enhancing features. In the process I also suddenly noticed something in my email:

Something struck me wrong about this. Why are they advertising to me? Did I click something at some point in the registration process? Did I “not opt out” while creating my account?

Going through the registration process again it seems that the latter.

Yep, looks like a hidden opt out. A common, if questionable, tactic. I know I am always trying to uncheck this stuff, and when I “miss one” and start getting email, I consider that spam.  And in this case it’s not even classic “soft marketing”, they’re specifically trying to sell me products. They provide a one click unsubscribe, so its probably not a big deal, but at the same time you have to wonder whether you should consider this underhanded. Is it enough to bring the ire of the spam button? They better hope not.

Part 2: Setting Up Auto Scaling

Within the overall umbrella of Amazon Web Services are dozens of individual technologies that you can use together to provision, launch, monitor and manage scalable web applications. Setting up intelligent auto scaling (AS) on AWS requires several of them, including:

• Amazon Machine Image (AMIs) – snapshot templates defining a launchable EC2 server instance
• Elastic Load Balancer (ELB) – a virtual load balancer platform with configurable events
• CloudWatch (CW) – tools to monitor and check your EC2 instances
• Command line tools – simple Java programs that call out to the AWS API using your credentials. Unfortunately, Amazon hasn’t added all of the autoscaling configurations to the online AWS Console yet, so until further notice, you’ll have to use a few command-line scripts to finish out the autoscaling configuration. Download the Auto Scaling command line tool from the AWS developer portal and run them on the command line to configure your autoscaling setup.

Why Auto Scaling?

Online marketers spend hours, days, weeks and even months, planning marketing campaigns, both online and offline, to drive traffic to websites, and IT provisioning is difficult even when you know in advance when the traffic is coming. But what if you don’t know when a huge traffic spike will hit your server? The better a social or viral marketing campaign is, the more likely it could result in irregular traffic patterns or server load spikes at unexpected times. The flexibility of AWS autoscaling frees you from having to accurately predict and provision servers in advance of huge traffic spikes.

How it works

In general, Auto scaling with Amazon Web Services works like this:

• You define an AMI instance and create an Auto Scaling Group to launch instances into.
• You use CloudWatch to monitor your server(s) instance(s), and when certain configurable events happen, you can launch more instances based on the AMI template you define.
• EC2 instances launch behind the Elastic Load Balancer (ELB) you define.
• The ELB will send traffic in a round-robin pattern between all the instances assigned to it, and you can control in real time how many instances you want to launch to cover sporadic bursts of high-volume traffic, and keep at least one or two running during traffic lulls. If any of your EC2 instances fails to respond, the ELB will detect it and launch a replacement. When web traffic dies down, you can terminate instances automatically, too.
• CloudWatch lets you configure alarms that trigger auto scaling policies to launch additional EC2 instances into your auto scaling group when network traffic, server load, or other measurable statistic, gets too high—say, 80% usage. The number of servers you add is based on whatever your policy states—1, 3, 10 more servers—it’s up to you. Each server is a duplicate instance of the AMI you define in your auto scaling config. You can even use Amazon Simple Notification Service (SNS) to send yourself an email or text message when an auto scaling event occurs.
• Your ELB automatically spreads out the incoming visitors between all the servers in your Autoscaling Group. You can set a minimum and maximum number of instances in your group, offering you peace of mind that your site will not crash due to the influx of visitors, and also to limit the impact on your billing statement. You are also able to tell AWS to decrease the number of instances when network traffic drops below, say 20% usage for a measurable amount of time, to scale back the number of servers in your web server farm.

How many servers will I need?

That’s the toughest question to answer—a lot of variable factors are involved. It depends on the volume of traffic you receive, the type of EC2 instances you use, and the complexity of your application. For our simple PHP application, we estimated that a single t1.micro instance, Amazon’s smallest and least expensive EC2 option, should easily handle between 50 to 75 simultaneous users. We determined this based on the available amount of RAM available in a t1.micro instance, and comparing that to the average amount of memory taken by a typical PHP request on our application. We then did some actual load-testing and benchmarking with the command-line tool, siege. We’ll get into the details of that later. Ultimately we decided that we wanted no fewer than 2 servers and no more than 100, or support for up to 7,500 simultaneous users, based on using t1.micro’s in our autoscaling configuration.

What to monitor

AWS CloudWatch lets you monitor several different EC2 server performance metrics in real time, including…

• CPU Utilization (%)
• Memory Utilization (%)
• Network Out Utilization (MB)
• Memory Used (MB)
• Memory Available (MB)
• Swap Utilization (%)
• Swap Used (MB)
• Disk Space Utilization (%)
• Disk Space Used (GB)
• Disk Space Available (GB)

…and many more. It’s up to you what to monitor, but the metrics most useful for knowing when you should scale up and add another server or scale down by terminating a server are probably CPU utilization, memory utilization or network utilization.

It should also be noted that Amazon provides plenty of basic monitoring metrics for free. Basic monitoring has a 5 minute refresh interval. If monitoring every 5 minutes isn’t fast enough for your application, you can also look at the detailed monitoring option, which costs only fifty cents per metric per month. Detailed monitoring fires events at 1-minute intervals. Here’s a list of the EC2 metrics you can monitor using CloudWatch. If you don’t find a metric that will suit your application, you can even submit (via the Amazon AWS API) a custom metric from your app that CloudWatch should monitor.

How to configure auto scaling

Before we get started, let’s look at the two prerequisites you need to have in place before creating an auto scaling configuration.

Prerequisite 1: Choose an AMI to use. If you haven’t created an AMI from one of your running EC2 instances, go back to Part 1 and create an AMI now, or click over to your AMIs page on the AWS Console to retrieve the AMI ID to be used as a template, and write it down. You’ll need an AMI ID in Step 1.

Prerequisite 2: Fire up an ELB. The ELB name that is displayed on the AWS Console will also be passed to the command we run in Step 2. We used the AWS Console to create an ELB, and simply accepted the defaults on each of the Elastic Load Balancer setup screens. Once your ELB is up, you will most likely create a CNAME record at your DNS provider pointing your landing page or vanity domain to the DNS name given in the AWS Console. Visit the Elastic Load Balancing at Amazon AWS page for additional information.

Okay, here we go! As we mentioned above, not all of the functions needed to implement autoscale are implemented in the AWS Management Console yet. So, roll up your sleeves and fire up Terminal (Mac) or CMD (Windows). We’ll be using a few different command line tools to finish our autos caling configuration.

Step 1: Create a launch config. The first command to setting up autoscale is as-create-launch-config. Using this command, you tell AWS:

• a unique name for the configuration,
• which AMI ID you want to use as your template for creating more EC2 instances,
• the EC2 instance type (the size and power of the server) to launch using your AMI,
• your access key,
• and a security group to deploy the instances into.

The API replies with: “OK-Created launch config.”

$PROMPT> as-create-launch-config {your_launch_config_name} --image-id {your_ami_id} --instance-type t1.micro --key {your_access_key} --group {your_group_name}
Return message: OK-Created launch config

Step 2: Create an auto scaling group.  Use the as-create-auto-scaling-group command to define the properties for your group of servers. Auto scaling groups are the core component of an auto-scaling configuration. This command takes the launch_config_name you defined from the step before as a parameter, the name of the ELB you want to use, and most importantly, lets you define the minimum and maximum number of servers you want to have in your cluster. In the example below, we define a group with a minimum of 2 servers and a maximum of 10.

$PROMPT> as-create-auto-scaling-group {your_scaling_group_name} --launch-configuration {your_launch_config_name} --availability-zones us-east-1d --min-size 2 --max-size 10 --load-balancers {your_load_blancer_name} --health-check-type ELB --grace-period 300
Return message: OK-Created AutoScalingGroup

The grace period is the number of seconds that AWS will wait after an autoscaling event occurs before possibly triggering another autoscaling event. This is an important consideration that prevents AWS from adding too many servers too quickly. AWS responds with “OK-Created AutoScalingGroup.”

Step 3: Create auto scaling policies. Once we have our EC2 AMI, an AS launch config, and an AS group defined to deploy our  instances into, we’re ready to define the auto scaling policies that will actually cause more (or fewer) EC2 instances to be launched and attached behind the ELB.

The command used to change the number of servers in the group is the as-put-scaling-policy command. With auto scaling, you use EC2 monitoring within CloudWatch to trigger a certain policy, but before we can do that, we need to define the actual policies that will be triggered. You can use this command to manually trigger scaling events as well, for testing before your traffic burst arrives, and in doing so, you can not only see the effect of scaling up and down, but you can watch AWS work its magic by refreshing your Instances view—new server instances appear in the AWS Management Console as your traffic increases beyond the thresholds you set.

The as-put-scaling-policy command takes the auto scaling group name we defined in step 1, a name for the policy, such a “scale-up” or “scale-down,” the type of scaling change the policy defines, and a cooldown period. Again, the cooldown period is used to prevent AWS from executing multiple policies within a very short time.

$PROMPT> as-put-scaling-policy --auto-scaling-group {your_scaling_group_name} --name scale-up --adjustment 1 --type ChangeInCapacity --cooldown 300
Return message: arn:aws:autoscaling:us-east-1:751374139099:scalingPolicy:e31ae79c-4210-42ad-8d86-60210aaf7a20:autoScalingGroupName/sg-breezes-gma:policyName/scale-up

Above you can see the basic upscale policy we defined, named “scale-up,” a ChangeInCapacity policy to add 1 server and wait 3 minutes before another policy can be triggered. Below is the reverse operation, or a “scale-down” policy to remove 1 server from our group.

$PROMPT> as-put-scaling-policy --auto-scaling-group {your_scaling_group_name} --name scale-dn "--adjustment=-1" --type ChangeInCapacity --cooldown 300
Return message: arn:aws:autoscaling:us-east-1:751374139099:scalingPolicy:07a0f71c-d214-4497-973f-c4cdcb15851f:autoScalingGroupName/sg-breezes-gma:policyName/scale-dn

In both cases, AWS replies with a return message including the unique auto-generated name of our two new auto scaling policies. We’ll use those unique policy identifiers to connect to our CloudWatch events in the final step.

Step 4: Link a CloudWatch event to an auto scaling policy. At the moment we have everything we need for an intelligent autoscaling configuration except one thing—the intelligence! The smarts come from choosing a CloudWatch event, such as 80% CPU utilization of an EC2 instance in our group, and wiring up that condition to automatically trigger the scale-up policy we defined. We’re also going to want to do the same in reverse for scaling back down at 20% CPU utilization.

The command to do this comes from the CloudWatch command line tools, and is called mon-put-metric-alarm. This command takes several parameters:

• a name for the alarm that you choose
•  a description for what the alarm is monitoring,
• the namespace for the alarm (in this case, AWS/EC2)
• the name of the [namespace] metric that you want to monitor
• the statistic type of the monitoring metric, such as Average or Percent,
• a period or time interval,
• a threshold for the statistic you choose,
• a comparison operator, such as greater than or lesser than
• a dimension, which is the ID of an EC2 instance to monitor
• and the number of evaluation periods during which the metric you choose has to consistently return over or under the average or percent unit you define

As you can see, there’s a lot to this command, but once we look at every parameter, you can see that without each of them, you wouldn’t have the ability to control auto scaling changes with enough granularity. The name and description are shown back to you later when using the mon-describe-alarms command. The statistics you’re watching, and the thresholds and time intervals, are important to test for your particular application. For example, we chose to monitor average CPU utilization for a period of 60 seconds, and an evaluation period of 3 intervals (or 3 minutes), for an event of 80% or greater level. Here’s the command to achieve this.

$PROMPT> mon-put-metric-alarm --alarm-name sample-scale-up --alarm-description "Scale up at 80% load" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average  --period 60 --threshold 80 --comparison-operator GreaterThanThreshold --dimensions InstanceId=i-37b12752 --evaluation-periods 3  --unit Percent --alarm-actions arn:aws:autoscaling:us-east-1:751374139099:scalingPolicy:78d05062-0eda-436c-864e-d93776461eba:autoScalingGroupName/sg-sample-group:policyName/scale-up
OK-Created Alarm

In English, the above command says, “If the average CPU utilization of instance i-37b12752 is measured at 80% or greater 3 times over 3 minutes, then trigger our scale-up policy.”

Here is the reverse mon-put-metric-alarm command we used to terminate one of the servers if the CPU utilization drops below an average of 20% over 3 minutes.

$PROMPT> mon-put-metric-alarm --alarm-name sample-scale-dn --alarm-description "Scale down at 20% load" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 60 --threshold 20 --comparison-operator LessThanThreshold --dimensions InstanceId=i-37b12752 --evaluation-periods 3 --unit Percent --alarm-actions arn:aws:autoscaling:us-east-1:751374139099:scalingPolicy:78d05062-0eda-436c-864e-d93776461eba:autoScalingGroupName/sg-sample-group:policyName/scale-dn

For more information and examples, refer to the Auto Scaling section on the Amazon developer documentation.

Testing with siege

As mentioned above, we used the command line tool siege to work through the configuration setup and to verify whether our policies were working as we wanted. Using siege on a different server or EC2 instance, you can easily simulate tons of website traffic for a short period of time. Siege does this by creating dozens or even hundreds of concurrent HTTP requests to your URL for the duration you specify. This gives you a chance to see what will happen to your auto scaling policies when real users flood your web server with traffic and CloudWatch alarms start triggering.

Siege can be installed with the package manager on your system. We simply ran

sudo apt-get install siege

on our Ubuntu/Debian system, and that was it. TechRepublic.com has a great article on installing from source and using siege.

Siege is simple to use—just give it the number of concurrent connections you want to create (-c), the length of time (-t) to run the test, and your URL, as shown:

siege -c25 -t10M  www.example.com

One thing to note here is that CloudWatch basic monitoring refreshes every 5 minutes, and our auto scaling policies above require a metric to be met for 3 consecutive minutes, so we had to run siege tests for at least 6 to 10 minutes to ensure that our policies had enough time to trigger at least twice. While siege was running, we refreshed the CloudWatch tab in AWS Management Console to verify that more servers were indeed getting launched.

Time-lapse showing the effect of Siege testing on auto scale

1. Two instances running prior to launching Siege
2. Siege test starts; new instances automatically launched as the scale-up policy is triggered
3. Additional instances launched to handle continued Siege test
4. No more instances needed, load is handled and stable
5. Siege test is completed
6. Shutting down an instance as bottom threshold is met
7. Two instances now terminated after scale-down policy, returns system to initial state

Making changes

It should have come as no surprise that we would need to make changes to our landing page and micro-site at the last minute, right before our client’s scheduled appearance on a national TV show. To make changes to the landing page, we need to upload some new files to our EC2 instance. No big deal, right?

Under a normal web hosting scenario, this is no problem, but when you have an AMI defined to be the source template for an auto scaling configuration, and the entire micro-site content is baked into the AMI, it’s an issue because the moment one of our events is triggered and CloudWatch triggers our auto scaling policy to launch a new instance, it’s going to be copied from our now-stale AMI with the outdated content.

It’d be nice to simply create a new AMI with the changes and re-run the as-create-launch-config script where we define the AMI to use, however trying that gives the following error:

configuration already exists with the name sample-launch-config-name

So that won’t work. Next, we thought maybe could just delete the auto scaling group, using the as-delete-auto-scaling-group command, and AWS asks, “Are you sure you want to delete this AutoScalingGroup?” When we replied “Y,” we got this error:

as-delete-auto-scaling-group:  Malformed input-You cannot delete an AutoScalingGroup while there are instances still in the group.

Well that’s good to know—you cannot inadvertently delete an auto scaling group while instances are running inside it. What instances are running inside it? You can use the as-describe-auto-scaling-instances command for that. This command is nearly identical to ec2-describe-instances, but instead of showing all your instances, it lists the ones running inside each autoscaling group you have configured.

In order to actually terminate the instances, though, we have to change the minimum number of instances allowed. Remember, when we ran the as-put-scaling-policy earlier, we defined minimum instances as two. If we terminate the instances in the group, AWS will just launch more to replace them to meet the minimum. So, next, we had to change the minimum number of servers in our auto scaling group to zero. This is most easily done with the as-update-auto-scaling-group command, as shown:

$PROMPT> as-update-auto-scaling-group sample-sg-name --min-size 0
OK-Updated AutoScalingGroup

Once we did that, we could terminate our instances using the as-terminate-instance-in-auto-scaling-group command. Finally, we could run as-delete-auto-scaling-group followed by as-delete-launch-config.

Granted, this manual work to build up and tear down an auto scaling configuration is kind of a pain point, but in our case we didn’t have time to use a proper deployment script, as is normally the case for cloud deployments. On the other hand, it did force us to learn all the command line tools to reverse, undo, tear down and delete an auto scaling configuration and document them here.

Auto scaling command summary

To build up an auto scaling group

1. as-create-launch-config
2. as-create-auto-scaling-group
3. as-put-scaling-policy (for scaling up)
4. as-put-scaling-policy (for scaling down)
5. as-execute-policy (for testing the policies)
6. as-update-auto-scaling-group (for changing policies)
7. mon-put-metric-alarm (for triggering policies)

To tear down an auto scaling group

1. as-update-auto-scaling-group (to set a minimum of 0 instances)
2. as-describe-auto-scaling-instances (to see the instance IDs)
3. as-terminate-instance-in-auto-scaling-group (terminate each ID)
4. as-delete-auto-scaling-group
5. as-delete-launch-config

Reference documentation

• AWS Developer Documentation
• Getting Started with the Command Line Tools
• Get Started with Auto Scaling
• Auto Scaling Developer Guide
• Set Up the Command Line Interface

1. “I don’t have the budget to purchase testing software.”

Visual Website Optimizer starts at $49 per month. Google Website Optimizer (GWO) is free. Budget is no excuse.
 

2. “I don’t have the technical expertise to set up a test.”

Though it’s true that technical implementations can get complex, that doesn’t have to be the case. Setting up a simple A/B test on a tool like GWO is easy and can take only minutes. So take the initial plunge with a simple A/B test. For example, test some revised headlines.
 

3. “I don’t know how to run a statistical analysis on the results.”

There’s no need, as basic statistical analyses are built into all the major testing tools. Sure, you can run more sophisticated analyses on the results and learn more from the data, but you can leave that for later tests.
 

4. “I fear that running tests could lower my conversion rate.”

Yes, it’s possible that a poor-performing variation could temporarily lower conversion rates. But all testing platforms allow you monitor your tests on an ongoing basis, and to either stop the test or disable poor-performing variations. Also, you can reduce risk by specifying that only a certain percentage of your traffic will take part in the test. The greater risk lies in NOT running tests.
 

5. “There’s no guarantee I’ll get a positive result.”

True. But the flipside of that argument is that if you do nothing, it’s guaranteed you won’t get results. Stick with testing, and you’re bound to get positive results soon enough.
 

6. “I don’t have a UX designer to come up with the alternate variations.”

Then either hire one on contract, or (as mentioned above) test on simple things like text. (Headlines, subheads, bullet points, calls to action, etc.)
 

7. “I don’t need to test, I know what works best for my customers.”

Nobody gets it right every time. I’ve seen lots of test where everyone’s prediction was wrong and the winner is a total surprise. So never assume that your page is perfect; you might be surprised at the changes that lead to better performance.
 

8. “I prefer the simplicity of sequential testing.”

Sequential testing (i.e. running one version for a while, then running a revised version and seeing if it performs better) doesn’t have the accuracy of true “Split A/B” testing. (You’ll never know whether external factors may have influenced the results.) The whole point of testing is to base decisions on data rather than hunches; data must be reliable.
 

9. “My Website doesn’t get enough traffic.”

For very low traffic websites, this might actually be a valid excuse. However, testing just one variation against the original does not take all that much traffic, especially if the two versions are dramatically different. It’s not uncommon to achieve statistically significant results with a total of fewer than 1,000 visitors to the page.
 

10. “It’s too early for us.”

If you have a live website with significant traffic, then it’s time to start testing. The sooner the better. New businesses can actually benefit the most from conversion testing, as they’re likely to have a less complete understanding of their customers and what makes them tick.
 

Dozens, if not hundreds, of ISPs have spawned special business units dedicated to cloud hosting, and many of them support scalability features that claim to automatically increase your server’s capacity, whenever it is needed. Sounds great, right? That’s exactly what you need!

Be sure to read the fine print! Some of the most popular cloud-based web site hosting providers include VPS.net, RackspaceCloud.com and FireHost.com  — although many lists of the top cloud hosting providers don’t even mention Amazon Web Services! Why? Cloud hosting features and options at various cloud hosts are quite different from each other, and not all cloud-based auto-scale works as you might expect it to work. Do your homework before switching from your current ISP—it can really pay off.

Case in point: We’ve recently learned that some ISPs which claim to offer auto-scaling server solutions actually don’t auto-scale anything at all! Instead, they’ll monitor your server, and when it reaches a peak load of, say 80% CPU utilization, they’ll actually shut off your site! Surprised? It’s true. Of course they’ll spin up a new larger instance of your app server a few seconds later to handle the load, which is how they can legally put wording such as ‘…automatically scale resources…’ on their sign up pages, but what about those critical moments of down time, right when you need it most?

Still other cloud hosts will automatically scale up your web server during a traffic spike, which is great, but they don’t notify you, and they also don’t automatically scale it back down when the traffic dissipates, leaving you with a bigger-than-expected bill at the end of the month and hours of wasted time on a support ticket thread to sort out billing confusion. Again, read the fine print, check for reviews online, and chat or email their sales team with every question you can think of before selecting any hosting provider.

Auto-Scaling Requires Preparation

In preparation for a recent television airing, we helped one of our clients deploy a microsite on a load-balanced, auto-scaling cluster of web servers using Amazon Web Services. AWS offers a true auto-scale solution that is capable of delivering your site flawlessly with zero downtime, yes, that’s 100% uptime, and fast response times—even during short periods of huge traffic bursts. Better yet, they provide these tools at incredibly affordable rates that keep getting lower all the time.

Sounds great, right? Using our guide below, you’ll be autoscaling in no time.

Part 1: Creating your EC2 Instance Template

In this first section, we’re going to create an EC2 instance to run our web application, upload our content to it, and create an AMI, or Amazon Machine Image. From this template, we can clone additional web servers to build our autoscale cluster.

Create an Amazon.com account

It may seem obvious, but the first step in using Amazon Web Services is to create an account on Amazon.com. If you’ve bought a book or own a Kindle,  you most likely already have one, and if so, you’re half done with this step. Your Amazon.com account links you to all of AWS. Just click over to Amazon, login, and redirect your browser to aws.amazon.com, accept the prompts, enter your credit card and so on. Note that you pay nothing until you actually start utilizing services. Furthermore, you don’t need to worry about accidentally spinning up some expensive server: with Amazon’s Free Tier usage plan, the first 750 hours of compute time, per month, every month, are 100% free.

Obtain x.509 credentials and API key

To use the AWS command line tools, first you’ll need to obtain your AWS ID keys, the necessary security credentials needed to connect and manage the services in your account from the command line. Visit the Amazon AWS Security Credentials for more in depth information.

Generate your access keys:

1. Login to your AWS Management Console
2. Hover over “My Account/Console” link on the top right of your screen and select the “Security Credentials” option
3. Scroll down and select the “X.509 certificates” tab
4. Click on the “Create a new Certificate” link.

5. Amazon will generate two files:

   • A PEM encoded RSA private key named something like pk-xxxxxxx.pem – you must download this Private Key before navigating away from the page
   • A PEM encoded X.509 certificate named something like cert-xxxxxxx.pem
6. Download both PEM encoded files
7. Download the Amazon EC2 API Tools
8. Create a “.aws” folder in your home directory
9. Copy the certificate and RSA private key into your ~/.aws directory
10. Unzip the Amazon EC2 Command-Line Tools, look in the new directory and move both the bin and lib directory into your ~/.aws directory. This directory should now have the following:
    • The cert-xxxxxxx.pem file
    • The pk-xxxxxxx.pem file
    • The bin directory
    • The lib directory

Install the tools

Most of the following tasks can be performed using the AWS Management Console, Amazon’s online, web-based interface to create, configure and deploy server instances on the Elastic Compute Cloud (EC2). Only a few steps require the command line tools. Download each of the tools, extract their contents, and create the following folder structure by copying each tools into these corresponding folders:

• Amazon EC2 API Tools → ~/.aws/ec2/*
• Auto Scaling Command Line Tool → ~/.aws/as/*
• CloudWatch Command Line Tool → ~/.aws/cw/*
• AMI Tools → ~/.aws/ami/* — not covered in this article, but may want to download for future use

Setup paths for Amazon EC2 Command-Line Tools

Edit your .bash_profile to setup the corresponding paths

export EC2_HOME=~/.aws/ec2
export EC2_PRIVATE_KEY=`ls ~/.aws/pk-*.pem`
export EC2_CERT=`ls ~/.aws/cert-*.pem`
export AWS_AUTO_SCALING_HOME=~/.aws/as
export AWS_CLOUDWATCH_HOME=~/.aws/cw
export AWS_AMITOOLS_HOME=~/.aws/ami
export AWS_CREDENTIAL_FILE=~/.aws/credentialsfilepath.txt
export PATH=$PATH:$EC2_HOME/bin:$AWS_AUTO_SCALING_HOME/bin:$AWS_CLOUDWATCH_HOME/bin:$AWS_AMITOOLS_HOME/bin

Launching EC2 Instances

If you have some knowledge of Linux system administration, you won’t believe how quick it is to set up your Web site on EC2. Thousands of Amazon Machine Images (AMIs) are available, in practically every flavor of OS you can imagine. Nearly all of them come with a variety of pre-installed software besides the OS, including many with Apache, PHP and MySQL. For a more detailed, step-by-step guide to this process, follow this Official Guide to using Amazon EC2. In a nutshell, here’s the process.

From the AWS Management Console:

1. Login to your AWS Management Console
2. Click the EC2 tab
   
3. Click the Launch Instance button
   
4. If this is your first time, choose the Classic Wizard and click Continue. This option will let you see and set every option, about 7 steps.
   
5. Choose your distro. Under the Quick Start tab, you can instantly see the option for RedHat, SUSE and Ubuntu. If you’re comfortable configuring Apache, PHP and MySQL by hand, these are stock OSes with no fluff. For an even faster setup time, if you’re going to be running WordPress, Magento or another popular framework, search for it under Community AMIs—chances are someone has already preconfigured it with a LAMP stack ready to go. We chose the Bitnami WordPress stack.
   
   We also chose an ebs-backed, 32-bit AMI so we can use it with Amazon’s t1.micro instance, the least expensive instance type. You can always restart this small instance as a larger instance size later. Click Select on the row that has the AMI you want to launch.
6.  Launch 1 instance of a t1.micro. Don’t worry about which Availability Zone for now, just pick one and use the same one you choose here in later steps. Click Continue.
   
7. You can leave all the defaults on the Advanced Instance Options screen. Just click Continue.
8. On the next screen, Keys, you’re asked if you want to tag the server instance with any key value pairs. These are not security keys, and no keys are required. These keys are just tags to help sort and identify your servers quickly when you have lots of them running. If this were a web server only or a database server only, for example, you could add a key named type with a value of webserver or database respectively. Click Continue.
9. On the next screen, I’d recommend that you create a new key-pair and download it to your ~/.aws/* folder, unless you have already created and downloaded another one, which will be listed and preselected under existing key pairs. If you’re going to be hosting multiple clients in your AWS account, create and use a unique key pair for each client. This key may just a text file with a .pem extension, but it’s very important! Don’t lose it!You will likely need to update your file permissions, otherwise you’ll receive a “Permissions 0644 are too open” when you try to ssh.

   $PROMPT> chmod 0600 clientname-key.pem

   After downloading the key, click Continue.
   

10. On the Configure Firewall screen, you have to configure a Security Group. This is your firewall. You’ll want to be sure to open the port for HTTP (80) and SSH (22).
    
    You don’t need any other ports open unless you plan to use other services. Common services are listed, and the default port numbers are automatically opened. The Source field default of 0.0.0.0/o means to allow all IPs and subnets on the entire Internet access to these ports. If you’re really careful with security, the SSH port is a good one to close down. To do this, enter your firewall IP address followed by “/0”. This way, the only way you can access the server instance via shell is from your office or home computer. No other computer on the net will be able to SSH into your server.
    
11. The final screen just shows you a summary. Click Launch and your server will be online in about one minute!

Now that you have an idea of all the configuration options for an EC2 instance from using the online management console, it’s worth noting that you can perform the exact same procedure as show above from the command line by using the ec2-launch-instances command:

$PROMPT> ec2-run-instances ami-2f2afb46 -k clientname-key

There are a plethora of additional command line tools that allow you to create key pairs, search for AMIs and perform all the other steps of the process described visually above.

Connecting to your instance

Your EC2 instance is starting. When will it be up and running so you can connect to it?

1. Click the Instances link in the left column
   
2. Click the Refresh button in the upper right corner of the instance list periodically until your instance Status says Running.
3. Check the checkbox in the left hand column of the instances list, and then expand the lower pane showing your 1 EC2 Instance selected details by dragging the horizontal divider upwards.
4. In the instance details panel, you’ll see a line like this:
   EC2 Instance: i-2afd6f5c ec2-10-20-30-40.compute-1.amazonaws.com
5. The first blob, i-2afd6f5c, is this specific Instance’s unique ID. The next blob, ec2-10-20-30-40.compute-1.amazonaws.com, shows you the instance’s public DNS name. Note also that the four numbers are the instance’s public IP address.
6. Launch a terminal and issue the following command:

$PROMPT> ssh -i ~/.aws/clientname-key.pem username@ec2-10-20-30-40.compute-1.amazonaws.com

Note that username is most often “root” but other distros or AMIs may require a different username. Check with the creator of the AMI for community AMIs. If you see a message about an RSA key fingerprint, just type “Yes” at the prompt and press enter. This is a one-time message.

You should now be connected, and viewing your server instance’s welcome message with a command line prompt.

Setup Elastic IP

At this point you can now navigate to your instance’s URL, something like ec2-10-20-30-40.compute-1.amazonaws.com and you’ll see the initial welcome screen of your EC2 instance. While you can continue to use Amazon’s auto-generated DNS name of your server moving forward, we usually upgrade to a static (reassignable) IP to make things simpler for VirtualHost definition and SSH access. Elastic IP addresses are static IP addresses designed for dynamic cloud computing. An Elastic IP address is associated with your account, not a particular instance, and you control that address until you choose to explicitly release it.

1. Click the Elastic IPs link in the left column under Network & Security
2. Click the Allocate New Address button to assign a static IP address to your account (Note: an Elastic IP address is associated with an account and billed accordingly until the address is released)
3. After checking the box of the Elastic IP you want associated, select the Associate Address button which will allow you to associate that Elastic IP Address to a running instance

If you’ve gotten this far, you should now be able to point your local hosts file to the IP address of your EC2 instance, launch a browser and check to see that your site is working as expected.

Upload your content

Congratulations! You’re now connected to your cloud instance at Amazon AWS. What next? If you created a server instance based on a default image of Red Hat or Ubuntu, the next step is to install and configure your LAMP stack. If you’re not root, sudo su and you should be good to go with apt-get, dpkg or yum as you’re used to. Your EC2 instance is indistinguishable from a dedicated server.

As you install software, test it and determine it to be working as expected, we recommend that you save your server image to an AMI, also called a snapshot, from the management console, after each step.

An AMI is an Amazon Machine Image, which is basically a copy of your entire server at the moment in time you request the snapshot to be created. Having this snapshot available at any time in the future will save you from having to reconfigure things over again, should your instance unexpectedly terminate (this has never happened to me, but it’s a good practice anyhow).

For our server instance, we used a Bitnami WordPress stack, so we can skip some software installation steps here—our Bitnami AMI comes with Apache, PHP, MySQL, phpMyAdmin and WordPress already installed and configured. Examples like this are one of the many time-saving features that make Amazon AWS great.

Create your own AMI (Amazon Machine Image)

Once you have your site or landing page running and tested from an EC2 instance, you then save a snapshot of the entire cloud server to your own private AMI.

Amazon’s giant library of community AMIs consist of user-contributed server templates created this same way by users just like you. Creating a private AMI periodically while you experiment with AWS is not only useful as a backup strategy, these AMIs also serve as future server templates, available only to you, from which to spawn additional server instances. When developing your server, be sure to name AMIs with a number at the end, e.g. LAMP-01, LAMP-02, etc. You can always go back later and delete previous AMIs. Good naming conventions become even more critical when building an auto-scaling cluster, as we’ll discuss a little later.

Your server will go down for a minute while the AMI snapshot is created, but sit tight, it comes back up automatically. Once your AMI snapshot is ready, you can use it to spawn one, two, three, ten, fifty, or even more instances in record time.

Create Database, MySQL User and Password

Here’s an example command line session that shows how to run MySQL and create your database, then create the username and password with a GRANT statement.

$PROMPT> mysql -u root -p
mysql> create database sitedb;
mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON sitedb.* TO
'siteuser'@'localhost' IDENTIFIED BY 'siteuserpassword';
mysql> exit

Transfer your site files to your EC2 Instance

You may have noticed above that we didn’t open the port for FTP when we set up our Security Group. It’s more secure to use SFTP (file transfer protocol over SSH), or even simpler: scp— the Secure Copy command line utility.

To use scp to upload files to your EC2 instance, first let’s create a single backup of our site. In a new terminal on your local machine, export the site contents from your SVN or Git repository, or download all the files from your current host. Next, use Tar and GZip to bundle the site files using the following command as shown:

$PROMPT> tar -czvf sitefiles.tgz /path/to/site/files

After that finishes, we can send the .tgz file you created to your server instance using the scp command. Note the use of the -i flag to provide the SSH key you created on step 9 above:

$PROMPT> scp -i ~/.aws/clientname-key.pem sitefiles.tgz \
username@ec2-10-20-30-40.compute-1.amazonaws.com

Once your .tgz is uploaded to the server, switch back over to your terminal still connected to your EC2 instance and unstuff it like so:

$PROMPT> tar -xvf sitefiles.tgz

Then, move the sitefiles into the htdocs or www directory. The location of this directory is different on various systems.

$PROMPT> sudo mv sitefiles/* /opt/bitnami/apache2/htdocs/

You might need to set the owner and permissions using something like:

$PROMPT> sudo chown bitnami:daemon /opt/bitnami/apache2/htdocs

You are done! …
Well, half done. Ok, we did say at the beginning that this was Part 1 right? Currently your EC2 Instance is setup and running, just as your website would be hosted anywhere else.

Coming up in Part 2, we’ll show you how we used CloudWatch, AutoScale Events and an Elastic Load Balancer to turn this single EC2 instance into a an intelligent, auto-scaling web server farm—all using AWS.