Category: Amazon EC2*


New Amazon EC2 Instance Type – The Cluster Compute Instance

A number of AWS users have been using Amazon EC2 to solve a variety of computationally intensive problems. Here’s a sampling:

  • Atbrox and Lingit use Elastic MapReduce to build data sets that help individuals with dyslexia to improve their reading and writing skills.
  • Systems integrator Cycle Computing helps Varian to run compute-intensive Monte Carlo simulations.
  • Harvard Medical School‘s Laboratory for Personalized Medicine creates innovative genetic testing models.
  • Pathwork Diagnostics runs tens of thousands of models to help oncologists to diagnose hard-to-identify cancer tumors.
  • Razorfish processes huge datasets on a very compressed timescale.
  • The Server Labs helps the European Space Agency to build the operations infrastructure for the Gaia project.

Some of these problems are examples of what are called embarrassingly parallel computing.  Others leverage the Hadoop framework for data-intensive computing, spreading the workload across a large number of EC2 instances.

Our customers have also asked us about the ability to run even larger and more computationally complex workloads in the cloud.

It is clear that people are now figuring out that they can do HPC (High-Performance Computing) in the cloud. We want to make it even easier and more efficient for them to do so!

Our new Cluster Compute Instances will fit the bill. With Cluster Compute Instances, you can now run many types of large-scale network-intensive jobs without losing the core advantages of EC2: a pay-as-you-go pricing model and the ability to scale up and down to meet your needs.

Each Cluster Compute Instance consists of a pair of quad-core Intel “Nehalem” X5570 processors with a total of 33.5 ECU (EC2 Compute Units), 23 GB of RAM, and 1690 GB of local instance storage, all for $1.60 per hour.

Because many HPC applications and other network-bound applications make heavy use of network communication, Cluster Compute Instances are connected using a 10 Gbps network. Within this network you can create one or more placement groups of type “cluster” and then launch Cluster Compute Instances within each group. Instances within each placement group of this type benefit from non-blocking bandwidth and low latency node to node communication.

The EC2 API’s, the command-line tools, and the AWS Management Console have all been updated to support the creation and use of placement groups. For example, the following pair of commands creates a placement group called biocluster and then launches 8 Cluster Compute Instances inside of the group:

$ ec2-create-placement-group biocluster -s cluster

$ ec2-run-instances ami-2de43f55 –type cc1.4xlarge –placement-group biocluster -n 8

The new instance type is now available for Linux/UNIX use in a single Availability Zone in the US East (Northern Virginia) region. We’ll support it in additional zones and regions in the future. You can purchase individual Reserved Instances for a one or a three year term, but you can’t buy them within specific cluster placement groups just yet. There is a default usage limit for this instance type of 8 instances (providing 64 cores). If you wish to run more than 8 instances, you can request a higher limit using the Amazon EC2 instance request form.

The Cluster Compute Instances use hardware-assisted (HVM) virtualization instead of the paravirtualization used by the other instance types and requires booting from EBS, so you will need to create a new AMI in order to use them. We suggest that you use our Centos-based AMI as a base for your own AMIs for optimal performance. See the EC2 User Guide or the EC2 Developer Guide for more information.

The only way to know if this is a genuine HPC setup is to benchmark it, and we’ve just finished doing so. We ran the gold-standard High Performance Linpack benchmark on 880 Cluster Compute instances (7040 cores) and measured the overall performance at 41.82 TeraFLOPS using Intel’s MPI (Message Passing Interface) and MKL (Math Kernel Library) libraries, along with their compiler suite. This result places us at position 146 on the Top500 list of supercomputers. The input file for the benchmark is here and the output file is here.

Putting this all together, I think that we have put together a true fire-breathing dragon of an offering. You can now get world-class compute and network performance on an economical, pay-as-you-go basis.  The individual instances perform really well, and you can tie a bunch of them together using a fast network to attack large-scale problems. I’m fairly certain that you can’t get this much compute power so fast or so economically anywhere else.

I’m looking forward to writing up and sharing some of the success stories from the customers who’ve been helping us to test the Cluster Compute instances during our private beta test. Feel free to share your own success stories with me once you’ve had a chance to give them a try.

Update – Here’s some additional info:

— Jeff;

New VPC Features: IP Address Control and Config File Generation

We’ve added two new features to the Amazon Virtual Private Cloud (VPC) to make it more powerful and easier to use. Here’s the scoop:

  • IP Address Control – You can now assign the IP address of your choice to each of the EC2 instances that you launch in your Virtual Private Cloud. The address must be within the range of addresses that you designated for the VPC, it must be available for use within the instance’s network subnet, and it must not conflict with any of the addresses that are reserved for internal use by AWS. You can specify the desired address as an optional parameter to the RunInstances function. This will allow you to have additional control of your network configuration, and has been eagerly anticipated by many of our customers. Two use cases that we’ve heard about already are running DNS servers and Active Directory Domain Controllers.
  • Config File Generation – VPC can now generate configuration files (example at right) for several different types of devices including the Cisco ISR and a number of Juniper products including the J-Series Service Router, the SSG (Secure Services Gateway), and the ISG (Integrated Security Gateway). The files can be generated from the command line or from within ElasticFox. Generating the config files in this way lets you avoid common configuration issues and allows you to be up and running in minutes.
 

If you want to connect a Linux-based VPN gateway to your Virtual Private Cloud, take a look at Amazon VPC With Linux. This article will show you how to set up IPSec and BGP routing and includes detailed configuration information.

If you are running OpenSolaris, take a look at the OpenSolaris VPC Gateway Tool.

— Jeff;

Big Data Workshop and EC2

Many fields in industry and academia are experiencing an exponential growth in data production and throughput, from social graph analysis to video transcoding to high energy physics. Constraints are everywhere when working with very large data sets, and provisioning sufficient storage and compute capacity for these fields is challenging.

This is particularly true for biological sciences after the recent quantum leap in DNA sequencing technology. These advances represented a step change for the field of genomics, which had to learn quickly about how housing and processing terabytes of data through complex, often experimental workflows.

Processing data of this scale for a single user is challenging, but moving to the cloud meant Michigan State University were able to provide real world training to whole groups of new scientists using Amazon’s EC2 and S3 services.

Titus Brown writes about his experiences of running a next-generation sequencing workshop using Amazon’s Web Services in a pair of blog posts:

“Students can choose whatever machine specs they need in order to do their analysis. More memory? Easy. Faster CPU needed? No problem.

All of the data analysis takes place off-site. As long as we can provide the data sets somewhere else (I’ve been using S3, of course) the students don’t need to transfer multi-gigabyte files around.

The students can go home, rent EC2 machines, and do their own analyses — without their labs buying any required infrastructure.”

After the two week event:

“I have little doubt that this course would have been nearly impossible (and either completely ineffective or much more expensive) without it.

In the end, we spent more on beer than on computational power. That says something important to me.”

A great example of using EC2 for ad-hoc, scientific computation and reaping the rewards of a cloud infrastructure for low cost, reproducibility and scale.

~ Matt

New: CloudWatch Metrics for Amazon EBS Volumes

If you already have some EBS (Elastic Block Store) volumes, stop reading this post now!

Instead, open up the AWS Management Console in a fresh browser tab, select the Amazon EC2 tab and click on Volumes (or use this handy shortcut to go directly there). Click on one of your EBS volumes and you’ll see a brand new Monitoring tab. Click on the tab you’ll see ten graphs with information about the performance of the volume.

For those of you without any EBS volumes (what are you waiting for?), here’s what you are missing:

Effective immediately, we now store eight metrics in Amazon CloudWatch for each of your EBS volumes. The metrics are stored with a granularity of five minutes and each data point represents the activity over the period. Here’s what we store for you:

  • VolumeReadBytes – The number of bytes read from the volume over the five minute period.
  • VolumeWriteBytes – The number of bytes written to the volume over the five minute period.
  • VolumeReadOps – The number of of read operations performed on the volume in the period.
  • VolumeWriteOps – The number of write operations performed on the volume in the period.
  • VolumeTotalReadTime – The total amount of waiting time consumed by all of the read operations which completed during the period.
  • VolumeTotalWriteTime – The total amount of waiting time consumed by all of the write operations which completed during the period.
  • VolumeIdleTime – The amount of time when no read or write operations were waiting to be completed during the period.
  • VolumeQueueLength – The average number of read and write operations waiting to be completed during the period.

You can access all of this from the CloudWatch API and the CloudWatch command-line (API) tools of course.

You can use these metrics to diagnose performance issues, learn more about the level of usage of each of your volumes, or to track long-term performance trends for your application.

There is no additional charge for monitoring EBS volumes and the metrics are stored for two weeks.

— Jeff;

Building three-tier architectures with security groups

Update 2 (27 Oct 2017): This post is no longer current. I would recommend that you start by reading the Network and Security documentation and read about Web Application Hosting in the AWS Cloud. You should also take a look at the Reference Architecture for Web Application Hosting and the Web Hosting Best Practices white paper.

Update 1 (17 June 2010): I’ve changed the command-line examples to reflect current capabilities of our SOAP and Query APIs. They do, in fact, allow specifying a protocol and port range when you’re using another security group as the traffic origin. Our Management Console will support this functionality at a later date.


During a recent webcast an attendee asked a question about building multi-tier architectures on AWS. Unlike with traditional on-premise physical deployments, AWS’s virtualization of compute, storage, and network elements requires that you think differently about how to build network segregation into your projects. There are no distinct physical networks, no VLANs, and no DMZs. So how can you construct the equivalent of traditional three-tier architectures?

Our security whitepaper alludes to the possibility (pp. 5-6, November 2009 edition). In my security presentations I show this diagram to illustrate conceptually how a three-tier architecture can be built:

 

EC2 three-tier architecture V2

Security groups: a quick review

Before we explore how to define the architecture, let’s take a moment to review some critical details about how security groups work.

A security group is a semi-stateful firewall (more on this in a moment) that contains one or more rules defining which traffic is permitted into an instance. Rules contain the following elements:

  • The permitted protocol (TCP or UDP)
  • The permitted destination port range (more on this in a moment, too)
  • The permitted source IP address range or originating security group

Now there are three particular aspects I’d like to call your attention to. First: security groups are semi-stateful because changes made to their rules don’t apply to any in-progress connections. Say that you currently have a rule permitting inbound traffic to port 3579/tcp, and that there are right now five inbound connections to this port. If you delete the rule from the group, the group blocks any new inbound requests to port 3579/tcp but doesn’t terminate the existing five connections. This behavior is intentional; I want to ensure everyone understands this. In all other respects, security groups behave like traditional stateful firewalls.

The second aspect is our terminology for port ranges. This often confuses people new to AWS. The traditional usage of the words “from” and “to” in security-speak describes traffic direction: “from” indicates the source and “to” indicates the destination. This isn’t the case when defining rules for security groups. Instead, security group rules concern themselves only with destination ports; that is, the ports on your instances listening for incoming connections. The “from port” and “to port” in a security group rule indicate the starting and ending port numbers for occasions when you need to define a range of listening ports. In most cases you need to allow only a single port, so the values for “from port” and “to port” will be the same.

This leads to the third aspect I’d like to discuss: how to define traffic sources. The most common method is to specify a protocol along with an individual source IP address, a range of IP addresses using CIDR notation, or the entire Internet (using 0.0.0.0/0). The other way to define a traffic source is to supply the name of some other security group you’ve already created. Here’s the magic jewel for creating three-tier architectures; it’s this capability that answered the person’s question on the webcast.

Defining the security groups for a three-tier architecture

If you’re an API aficionado, you can use these eight simple calls to create the three required security groups to implement this architecture:

ec2-authorize WebSG -P tcp -p 80 -s 0.0.0.0/0
ec2-authorize WebSG -P tcp -p 443 -s 0.0.0.0/0
ec2-authorize WebSG -P tcp -p 22|3389 -s CorpNet

ec2-authorize AppSG -P tcp|udp -p AppPort|AppPort-Range -o WebSG
ec2-authorize AppSG -P tcp -p 22|3389 -s CorpNet

ec2-authorize DBSG -P tcp|udp -p DBPort|DBPort-Range -o AppSG
ec2-authorize DBSG -P tcp -p 22|3389 -s CorpNet
ec2-authorize DBSG -P tcp -p 22|3389 -s VendorNet

Note here the interesting distinction in the parameters used with the commands. If the rule permits a source IP address or range, the parameter is “-s” which indicates source. If the rule permits some other security group, the parameter is “-o” which indicates origin. Neat, huh?

The color coding in the rule list helps you visualize how the rules relate to each other:

  • The first three statements define WebSG, the security group for the web tier. The first two rules in the group permit inbound traffic to destination ports 80/tcp and 443/tcp from any node on the Internet. The third rule in the group permits inbound traffic to management ports (22/tcp for SSH, 3389/tcp for RDP) from the IP address range of your internal corporate network — this is optional, but probably a good idea if you ever need to administer your instances :)
  • The second two statements define AppSG, the security group for the application tier. The second rule in the group permits inbound traffic to management ports from your corpnet. The first rule in the group permits inbound traffic from WebSG — the origin — to the application’s listening port(s).
  • The final three statements define DBSG, the security group for the database tier. The second and third rules in the group permit inbound traffic to management ports from your corpnet and from your database vendors network (required for certain third-party database products). The first rule in the group permits inbound traffic from AppSG — the origin — to the database’s listening port(s).

Of course, not everyone’s a programmer (your humble author included), so here are some screen shots showing how to define these security groups using the AWS Management Console. Please be aware that using the Console produces different results, which I’ll describe in a moment.

WebSG permitting HTTP from the Internet, HTTPS from the Internet, and RDP from our sample corpnet address range:

 

Three tier - 1 - WebSG

 

AppSG permitting connections from instances in WebSG and RDP from our sample corpnet address range:

 

Three tier - 2 - AppSG

 

DBSG permitting connections from instances in AppSG and RDP from our sample corpnet and vendor address ranges:

 

Three tier - 3 - DBSG

 

Important. The AWS APIs and the Management Console behave differently when defining security groups as origins:

  • Management console: When you define a rule using the name of a security group in the “Source (IP or group)” column, you can’t define specific protocols or ports. The console automatically expands your single rule into the three you see: one for all ICMP, one for all TCP, and one for all UDP. If you remove one of them, the console will remove the other two. If you wish to further limit inbound traffic on those instances, feel free to use a software firewall such as iptables or the Windows Firewall.
  • SOAP and Query APIs: With the APIs, rules containing security group origins can include protocol and port specifications. The result is only the rules you define, not the three broad automatic rules like the console creates. This provides you with greater control and reduces potential exposure, so I’d recommend using the APIs rather than the Console. As of now, while the Console correctly displays whatever rules you define with the APIs, please don’t modify API-created rules because the Console’s behavior will override your changes. We’re working to make the Console support the same functionality as the APIs.

More information

The latest API documentation provides details and examples of how to configure rules in security groups. To learn more, please see:

I hope this short tutorial has been useful for you and provides information you can use as you plan migrations to or new implementations in AWS. Over time, I’d like to write more short security and privacy related guides which I’ll post here and in our Security Center. If you have comments or suggestions about content you’d like to see, please let us know. We’re here to make sure you succeed!

> Steve <

NASA JPL, robots and the AWS cloud

NASA Jet Propulsion Lab, NASA’s lead center for robotic exploration of the solar system is doing some pretty extraordinary things with the AWS cloud. I had the opportunity to meet with their CTO to discuss some of the interesting projects they are working on. Like the early explorers of Deep Space, they were also early explorers of the AWS cloud. Cloud computing is high up on JPL CTO’s radar and various teams are leveraging the cloud for various different projects related to missions.

They operate 19 spacecraft and 7 instruments across the solar system. Each instrument sends tons of data and images, which needs to be analyzed and processed. From one such instrument, they processed and analyzed 180,000 images of Saturn in the AWS cloud in less than 5 hours. This would have taken them more than 15 days in their own data center.

Last April, I was at EclipseCon and I was stunned when I saw the e4 Mars Rover Application, which was hosted in the AWS cloud, built by NASA folks, to control the movement of Mindstorm robots. I started to wonder what will be the result of when we combine the potential of NASA, the AWS cloud and robots.

The super smart folks at NASA Jet Propulsion Lab (Jeff Norris, Khawaja Shams and team) developed a system that allows developers to interact with a Mindstorm robot in 4X4 Arena. The system exposes a REST API that takes commands from e4 clients and sends them to the app (RESTful Server running Equinox) hosted on Amazon EC2. The app stores all the commands (using conditional PUTs) in Amazon SimpleDB. The Poller application on the robot (Arena server) pulls the commands sequentially from a developer  immediately by consistently reading from Amazon SimpleDB and executes the commands on robot which makes the robot move in the Arena. A sample command looks like Set the velocity of the robot to 5 and move to the left.  In essence, developers will be able to send commands to the app on the AWS cloud and move the robot (in the arena). The system also stores all the logs, game queues, registration and scores in different Amazon SimpleDB domains. The RESTful server app is sitting in front of a fault-tolerant Elastic Load Balancer so that it can serve multiple concurrent requests and route traffic to multiple EC2 Instances.  The setup is configured to use the Auto-Scaling service and is ready to scale in case they get sudden surge in traffic from clients. So, any developer can send commands using the API and make the robot move; the app will elastically scale with demand. Wait, it does not stop here. The Arena has a camera that is capturing and storing 4 images every second (4 FPS) to Amazon S3 (using the versioning feature) after processing them to find the robot’s actual co-ordinates in the Arena. Millions of images get versioned and stored on Amazon S3 which can then be downloaded almost in real-time to get a live photo feed of the location of robot and its movement in the 4X4 arena. So, with this, any developer, from any where in the world, can actually write a program to send commands to the auto-scalable app hosted on EC2 and see the robot move in the arena.

In summary, large numbers of developers can write innovative clients to interact with the robot and because architecture is scalable and running on scalable on-demand auto-scalable infrastructure.

Kudos goes to NASA JPL team who not only conceived this idea but also built the system using the some of the most advanced features of AWS. They were already using some features which were released just a weeks ago for e.g. consistent reads and conditional puts from Amazon SimpleDB, versioning feature in S3 etc. They have what I call the “full house” of AWS that includes ELB, Auto-scaling, EC2. They are also planning to put together a video feed of the robot movements from the images and stream the video using CloudFront.
 
Architecture of the system is as follows:
NASA e4 application Architecture
To entice developers to write innovative apps (client apps to manage robot movements, client apps to interpret the messages/logs from the robot and apps to move the robot itself to follow a path), they had announced a contest at Eclipsecon named “e4 Mars Rover Challenge”.  They made this system available to EclipseCon developers and opened up the server only to EclipseCon attendees using EC2 Security Groups and limiting the access only to EclipseCon CIDR IPs. I was amazed at the creativity. Contestants built innovative client apps ranging from iPhone Apps (that use the accelerometer to manage the velocity and direction of the robot’s movement) to e4 intelligent clients that displays the telemetry. Winners have been announced. The event at EclipseCon was Mars-themed, and they have made the arena look like Mars with panoramas of Mars acquired by Spirit (Husband hill), and it had an orbiter, LED lights, and cool sound effects. This event was the ultimate crowd-pleaser at EclipseCon.
 
Imagine the potential when any developer can actually play with the robot from anywhere in the world and build innovative apps.
 
The fact that NASA engineers are utilizing cloud computing services to develop the contest brings a significant level of credibility to the whole notion of the cloud.

I was so excited after seeing the Arena at EclipseCon that I had to take the interview of masterminds behind this project. See the video below

–Jinesh

enStratus Adds Support for Amazon SNS and Amazon RDS

My friends over at Minneapolis-based enStratus Networks emailed me yesterday to give me a heads-up on their newest release of their Cloud Management Solution.

They have had full support for Amazon EC2 instances, S3 storage, Elastic IP Addresses, CloudWatch, Elastic Block Storage, Auto Scaling, Simple Notification Service, and CloudFront for a while.

Today’s release adds support for the Amazon Relational Database Service (RDS) and the Amazon Simple Notification Service (SNS). This support is available in all four of the AWS Regions.

You can see your existing SNS topics on this page:

And you can create a new topic by filling out this form:

Per the dialog above, you can associate a description and a billing code with the SNS topic, and you can also label the topic (and the other components of your application) to identify it as part of a particular application.

Their system also includes a number of other enterprise-grade features including key management, multiple user roles, automated failure recovery, reporting, and cluster-level management of EC2 instances. Learn more here or request a demo.

— Jeff;

Improving Global Application Performance

Today I would like to talk about ways to make your website run faster and more efficiently. There are several benefits from doing this including better search engine rankings, a better customer experience, and an increase in sales or conversions.

You can always improve your architecture, tune your database, and optimize your code. In each case you locate a bottleneck, figure out a way around it, and then proceed to do so. You basically spend your time answering the question “What part of my application is running too slowly and how can I speed it up?” This is the classical approach to performance tuning; many of the techniques to measure and to improve performance date back to the time before the web (you do remember those days, don’t you?).

In today’s web world, “where” can be just as important as “what.” Let’s talk about that.

The distance between the user and the application is a major factor in the performance of a website or a web-based application. Latency increases with distance, and increased distance also means that each network packet will take more “hops” through intermediate routers and switches as it makes its way from browser to server and back.

You probably can’t move your users closer to your application, but you can often deploy your application closer to the user. AWS provides you with two different ways to do this:

Choose a Region – You can put your application into any of four different AWS Regions. You should choose the AWS region that’s closest to the majority of your customers. As of this writing, you can choose to host your AWS-powered application on the east coast (Northern Virginia) or west coast (Northern California) of the United States, Europe (Ireland), or Asia Pacific (Singapore).

Use CloudFront Content Distribution – You can also speed up your application by using Amazon CloudFront to distribute web content (static HTML pages, CSS style sheets, JavaScript, images, file downloads, and video streams) stored in Amazon S3. Each user’s requests will be served up from the nearest CloudFront edge location. There are currently fifteen such edge locations: eight in the United States, four in Europe, and three in Asia.

You might be thinking that you run a “small” or “unimportant” site and that you don’t need or can’t benefit from CloudFront. Given that a lot of the value of the web is found in the long tail content, I disagree. There’s no harm (and plenty of potential benefit) from making your site quicker to load and more responsive. How do you think that the large, popular sites got that way? At least in part, they did so by being fast and responsive from the very beginning.

Or, you might think that CloudFront is somehow too expensive for you. Well, it’s not. I’ve been serving up all of the images for this blog from CloudFront for a while. Here’s my AWS account, reflecting an entire month of CloudFront usage:

That’s right, less than $2 per month to make sure that readers all over the world are able to get to the images in the blog as quickly as possible. If nothing else, think of this an inexpensive insurance policy that will protect you from overload in case your site shows up on SlashDot, Digg, Reddit, Hacker News, or TechCrunch one fine morning.

If you are interested in speeding up access to your application’s web content, start out by reading our guide to Migrating to Amazon CloudFront.This guide will walk you through the 5 basic steps needed to sign up for CloudFront and S3, download and install the proper tools, upload your content to an S3 bucket, create a CloudFront distribution, and link to the content.

If you are using a CMS (Content Management System), take a look at these:

  1. Joomla – CloudFront Joomla Plugin, Amazon WS Tools.
  2. Drupal – CloudFront Installation, CloudFront Drupal Module, Drupal Integration With Amazon CloudFront Streaming Video Demo.
  3. WordPress – Using Amazon CloudFront with WordPress and WordPress MU, W3 Total Cache, Simple Amazon S3 Upload Form, OSSDL CDN Off-linker, My CDN, and Amazon CloudFront CDN with a WordPress Blog

If you are doing video streaming, take a look at Use your Amazon CloudFront account, How to Get Started With Amazon CloudFront Streaming, and S3 News from the CloudFront: Private Streaming Video.

Encoding.com has put together a guide to Apple HTTP Streaming with Amazon CloudFront. The guide includes complete step-by-step directions and gives you all the information you’ll need to stream video to an iPad or an iPhone.

Carson McDonald has also put some work into an HTTP Segmenter and Streamer for Apple’s HTTP Live Streaming Protocol. Learn more in his series of three blog posts.

Last but not least, don’t forget about Using the JW Player with Amazon Web Services. JW Player is a very popular open source video player that’s also easy to embed and use. Use the JW Player test page to experiment with the configuration and setup options.

There are a number of good testing tools that you can use to measure the speed of your site while you are in the process of migrating to CloudFront. Here are two:

  • Yahoo’s YSlow is a Firefox add-in and one of the best-known browser-based performance measurement tools. You’ll need to install FireBug and spend some time learning how to use YSlow and to interpret the results. YSlow will measure performance as seen from your desktop. If you plan to use YSlow, don’t forget to tell it that you are using CloudFront as a CDN by following these instructions.
  • Cloudelay measures and displays several different CloudFront performance metrics including request latency and network throughput.
  • BrowserMob‘s free Website Performance Test. I really like this one. You can run a test from four locations around the world and see how it performs when viewed from that location.

As an example of just how location affects perceived website performance, take a look at this chart from the BrowserMob test:

There’s a 4:1 ratio between the fastest and the slowest location. I compared the detailed output for two separate objects: the blog’s home page and the volcano picture that I posted last week. The results show that CloudFront produces results that are reasonably consistent,regardless of where the test is run from:

Location Home Page Volcano
Washington, DC 323 ms 140 ms
 Dublin 631 ms 227 ms
San Francisco 45 ms 210 ms
Dallas 200 ms 252 ms

You can also see the amount of time it takes to look up each item’s DNS address, the time until the first byte of data arrives, and the amount of time spent reading the data:

Still need more info? Take a look at some of these case studies:

  • UrbanSpoon – “CloudFront took a day or two to implement. Switching to CloudFront helped us stay within our bandwidth caps, which saves us several thousand dollars a month.”
  • Linden Lab – “The Second Life Viewer is an application that each Resident runs on their own computer to interact with the Second Life world. Downloads of the Viewer were ideally suited for CloudFront delivery. The Viewer can be downloaded over 40 thousand times each day by different users all over the world and using CloudFront helps Residents download their software faster by storing copies at edge locations close to them.”
  • Playfish – “Playfishs infrastructure operates 100% on Amazon Web Services (AWS), primarily using Amazon EC2, Amazon S3, and Amazon CloudFront.”

One more thing, and then I’ll shut up! We recently recorded a webinar, Increasing the Performance of your Website With Amazon CloudFront.

If you have a CloudFront success story of your own, please feel free to post a comment or send me some email (awseditor@amazon.com).

— Jeff;

Now Open: AWS Region in Asia Pacific

Businesses and developers in the Asia Pacific part of the world can now obtain their processing, storage, and other services on an economical, pay-as-you-go basis from resources located nearby.

We’ve just opened up an AWS Region in Singapore, with two Availability Zones. The new region supports Amazon EC2 (including Elastic IP Addresses, Amazon CloudWatch, Elastic Block Storage, Elastic Load Balancing, and Auto Scaling), Amazon S3, Amazon SimpleDB, the Amazon Relational Database Service, the Amazon Simple Queue Service, the Amazon Simple Notification Service, Amazon DevPay, and Amazon CloudFront. The page for each service includes full pricing information for the Singapore Region.

Existing toolkit and tools can make use of the new Region with a simple change of endpoints. The documentation for each service lists all of the endpoints for each service. 

I know that RightScale will be supporting the new Region and will be migrating their templates and images in the next  couple of weeks. They already have their infrastructure up and running in the Region to provide fast communication between managed instances and their platform. Read more about how they are accelerating cloud adoption with support for the new Region, Windows, and simplified image creation.

George Reese of enStratus wrote to let me know that all 46 of their AMIs are already up and running in the new Region. This includes all of the AWS services, user management, financial controls, infrastructure automation with automatic application deployment, multiple auto-scaling options, automatic recovery, encryption, and key management.

Attention developers: I’ll create a list of updated tools and toolkits soon! Please send info to awseditor@amazon.com.

A number of customers are already planning to migrate their applications to the new Region. Here’s a sampling:

Singapore

Kim Eng, one of Asia’s leading securities brokers, is using AWS to host a trading application for the iPhone that will be launched in the near future. They chose AWS and the Singapore Region in order to minimize latency and to make sure that they can provide quick and efficient service even if there’s a sudden spike in usage.

iTwin, creators of the iTwin remote device for plug and play access to remote files, recently started using EC2. Lux Anantharaman, Founder and CEO, told us that “After evaluating multiple cloud service providers, we realized AWS is the only one which is globally available and which satisfies our deployment needs. AWS is extremely simple to configure and use, provides a comprehensive suite of web services which are unmatched by any other provider, and the billing system is convenient. Last but not least, our engineers love AWS.”

Australia

Altium provides software for electronic design. They have moved their content delivery over to Amazon S3 and CloudFront, reducing their bandwidth and storage costs to just 25% of that charged by their former provider. As their CIO, Alan Perkins, said, “At times we have thousands of clients asking for 1.5GB files at the same time and AWS has delivered without a glitch. ” They have also moved a lot of their research and development work to AWS.

Also in Australia, 99designs.com runs their crowdsourced graphic design site on AWS. They use a cluster of application servers on EC2, backed up by database servers and proxy servers that also run on EC2. They count on Amazon S3 to store massive amounts of data — a new design is uploaded every seven seconds. Lachlan Donald, CTO of 99designs.com, told us that “AWS has virtually eliminated our infrastructure concerns and allowed us to focus on our core business.”

India

Rediff provides online news, information, communication, entertainment, and shopping services. They’ve been using AWS for highly demanding data processing such as data mining and analytics. Sumit Rajwade, Rediff’s Vice President of Technology, told us that “The flexibility and scalability of the AWS platform is unparalleled and we are pleased that AWS is opening up a region in Asia Pacific.”

Indiagames decided to use AWS to launch and run their popular T20Fever game on Facebook. They turned to AWS as an alternative to building and scaling their own infrastructure. As a result, they were able to keep their staffers focused on development instead of on managing physical hardware. Their application makes use of EC2, S3,RDS, and CloudFront. According to Vishal Gondal (CEO), “By leveraging Amazon EC2, Amazon S3, Amazon Relational Database Service (RDS), and Amazon Cloudfront, we’ve been able to handle thousands of gamers concurrently without having to spend a rupee on physical infrastructure.”

— Jeff;

PS – We’ve been ramping up our marketing and business development activities in Singapore and we’re hiring a Marketing Manager, a Regional Account Manager for the International Market, and a Regional Account Manager for the Indian Market

We also need to hire some Solutions Architects, Technical Sales Representatives, a Data Center Manager, and some Data Center Technicians in Singapore. If you are interested in any of these positions, please send your resume or CV to tina@amazon.com .

SOASTA OLAP Engine for Performance Testing

Tom Lounibos from SOASTA sent me a heads-up on their new OLAP Engine.

The new product, CloudTest Analytics, builds on SOASTA’s existing CloudTest product. It consists of  data extraction layer that is able to extract real time performance metrics from a number of existing APM (Application Performance Management) tools from vendors such as IBM, CA, RightScale, Dynatrace, New Relic, Nimsoft. The data is pulled from the entire application stack, including resources that are in the cloud or behind the firewall or at the content distribution layer. All of the metrics are aggregated, stored in a single scalable data warehouse, and displayed on a single, correlated timeline. Performance engineers can use this information to understand, optimize, and improve application and system performance.

Of course, CloudTest runs on Amazon EC2 and is available on a cost-effective, on-demand basis.

If you are interested in learning more about cloud-powered load and scale testing, you may find this recent article to be of value. SOASTA used 800 EC2 instances (3200 cores) to generate a load equivalent one million concurrent active users. This test ultimately transferred data at a result of 16 gigabits per second (6 terabytes per hour).

— Jeff;