From Learn Amazon Web Services in a Month of Lunches by David Clinton Creating simple “Hello World” web pages is nice, but considering what’s on display, do you suppose anyone will drop by for a visit? Adding the kind of killer content that’ll have people falling over each other to get a good look at your site is your department, but assuming that the hordes are on their way, what’s next? Let’s learn how to prepare for those hordes by choosing the right blend of AWS resources to meet our unique needs.

Save 37% on Learn Amazon Web Services in a Month of Lunches. Just enter code fccclinton into the discount code box at checkout at manning.com.

Calculating Capacity Needs

How can we be sure that our humble AWS server has everything it needs to handle the expected load? What is the expected load? More often than not, a lot of servers need the support of additional technology like a Cisco c2960x-stack. This technology can be used to scale up smaller networks into bigger networks when data grows.

I’ll start with some basic assumptions about the nature of happiness.

• Our users are happiest when their browser requests are answered quickly and accurately.
• Our virtual server is happiest when it doesn’t have to strain to get its job done.
• We are happiest when we are confident that our users’ needs are being served, our server has things under control, and we’re not spending more money on our AWS resources than is necessary.

Now, let’s dig a bit deeper. To make sure that our server doesn’t have to strain its poor, delicate self, we’ll need to give it enough processing power (CPU capacity), storage space (hard drive capacity), system memory (RAM), and network bandwidth (the maximum amount of data that can be transferred into and out of our infrastructure at a given time). I’ll translate that into AWS-friendly terms to make sure we’re all speaking the same language.

Getting the Measure of EC2’s Core Compute Services

vCPU

In the Amazon universe, processing power is measured in vCPUs (virtual Central Processing Units). AWS tells us that a single AWS vCPU is roughly the equivalent of a “1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.” As modern consumer PCs will often come with four cores, each running at 2.5 GHz, in simplified terms we can say that our PC will deliver approximately eight times the processing power of a single vCPU. Having said that, because a virtual server doesn’t have to devote resources to most of the thirsty stuff running on your laptop – like a high-resolution video interface or a web browser with ten or fifteen tabs open – it can get more serious work done with a lot less power.

EBS

The AWS storage that is most comparable to the physical hard drive inside your PC is the EBS volume. EBS – which stands for Elastic Block Store – is a vast collection of hundreds of thousands of actual storage drives kept running within AWS’s data centers. An EBS “volume” is a logically defined amount of storage space carved out from one of the drives set aside for an EC2 customer – in this case, you.

Relatively speaking, renting space on an EBS volume is expensive, and you’ll generally want to keep application data (i.e. data generated either for or by your applications) elsewhere. Usually that “elsewhere” will mean AWS’s S3 storage service.

EBS volumes will usually be used for your operating system, your application code, and sometimes your database, but nothing more. Unlike the 500-1000 gigabyte drives you’ll see on bargain basement home PCs, an eight-gigabyte volume is often more than enough for Linux cloud servers. After all, who (besides YouTube) stores hundreds of cute cat videos on a server?

Memory

Memory is memory no matter where it lives. Because RAM memory is more accessible than any other widely available option, it’s usually used to temporarily store as much system process and application data as possible. If, for example, serving a single web page to a single customer requires one tenth of a megabyte (a.k.a. 100kb) of RAM, then you’ll want to make sure you’ve got at least 100kb * n of the stuff available (where n = the maximum number of pages you might need to serve at a single time). Naturally, you can run this calculation for yourself using your own page size and traffic volumes.

Bandwidth

The quality of an EC2 instance’s connectivity to its network is described as its Network Performance. For most instance types, the value will be “Low”, “Moderate”, or “High”. In the real world, the performance you experience will depend on a wide variety of factors. It has been estimated that you’ll get anywhere between 2 and 100Mb per second for Low, 10 to 250Mb per second for Moderate, and 95 to 1000Mb per second for High.

Compare those numbers with the amount of data you need to transfer in and out of your server to keep your customers happy to determine what level of Network Performance you’ll select.

Assessing your Application

For that information to be useful, you’ll need to get a sense of how much computing power your application needs. By far, the most reliable approach is to try it out for yourself. From within an SSH session on an AWS Ubuntu instance, Figure 1 shows the output of the top command with the system at rest.

Figure 1 A quiet EC2 webserver as measured by top

Top is a Unix/Linux program that reports on the processes that are currently using the most system resources, and can be a great way to quickly assess the state of your instance. The two columns that interest us the most are %CPU (the percentage of the total CPU capacity taken up by the most active processes) and %MEM (the percentage of system memory used by the most active processes). In this case, little of either resource is currently being used.

Figure 2 shows us the same top command run immediately after I loaded a web page served by this instance in my browser.

This time, the COMMAND column on the far right shows us that the two most active processes are associated with the Apache web server software and MySQL, which, between them, account for 4 percent of the CPU and around 7.5 percent of memory.

At this rate, we could certainly handle a dozen users launching requests within a short time, but after that, assuming we’re not using some clever optimization program, we’re hitting the limit. Or, if we’re expecting serious traffic to head our way, we’d better select a more robust instance type. Having said that, the virtualization underlying AWS makes it easy to upgrade resources later, should our needs change.

Naturally, you’ll also want to experiment with the quality of network response times and keep an eye on available storage on your EBS volume.

Choosing the Right Instance for Your Project

Besides storage – which is a separate decision – the CPU, memory, and network performance capacity you’ll get depend on the instance type you choose (Figure 3).

Figure 3 The EC2 “Choose an Instance Type” page

Now, keeping in mind what we’ve learned about these values, you should spend some time looking through the vCPUs, Memory, and Network Performance columns, and think about which Type you’re likely to need. To help you through that process, I’ll give you a bit of an overview of AWS’s Instance Type families.

Instance Type Families

Because they know that the specific needs of individual users’ projects will be wildly different from each other, AWS offers various categories of Instance Types (known as “Families”), each focusing on a specific profile range. Here’s a general overview that should help you interpret what might otherwise feel a bit overwhelming.

AWS currently organizes their instance types into eight different families (each designated by a single letter; “T”, “M”, etc). The identifying name of a type within a family consists of its family letter, along with a number – to differentiate it from any other types that might exist within the family. The missing numbers (where’s “T1” for instance?), are probably older types that have been deprecated. The “Focus” column describes the particular strength of each family.

Table 1 EC2 Instance Type Families:

Each member type (e.g. M4) will generally be available in a number of variations (e.g. M4.large, M4.xlarge, M4.2xlarge, etc.)

Based on all this, if you’re going to be running a large, high performance database operation, (for instance, it’s your job to keep Netflix.com’s customer account database running smoothly) you’ll want to choose some flavor of R3 Instance – or, more accurately, many hundreds of them. If, however, you’re responsible for a busy multi-tiered web server, (think: a blog that attracts more than a hundred thousand unique users each month), then M4, or even C3 instances might work better. The good news is that AWS has a profile to match your needs. The better news is that if you choose badly or your needs later evolve, updating your profile later isn’t that difficult.

Now that wasn’t complicated, was it? Maybe a little, but only because I left out some stuff. Take another look at the AWS console and let your eyes wander towards the top right corner and the drop down menu to the right of your account name. In my case (as you can see in figure 3), N. Virginia is its current title, but clicking on the menu will show you a long list of other geographic areas.

Figure 4 Select an AWS Region

Whichever area (or Region) you select will determine where in the world the resources you subsequently launch will be physically based. This is important for many reasons, including the fact that you might prefer to host your virtual servers on hardware as physically close as possible to your customers. But it’s also significant because not every Instance Type will be available in every Region. By the way: “N. Virginia” is not short for “North Virginia” – last I looked, there was no such state in the US. The AWS folk probably mean “Northern Virginia.”

For more information, check out the book on liveBook here and see this Slideshare presentation.