New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch

We are working to make it even easier for you to build sophisticated, scalable, and robust web applications using AWS. As soon as you launch some EC2 instances, you want visibility into resource utilization and overall performance. You want your application to be able to scale on demand based on traffic and system load. You want to spread the incoming traffic across multiple web servers for high availability and better performance. You want to focus on building an application that takes advantage of the powerful infrastructure available in the cloud, while avoiding system administration and operational burdens ("The Muck," as Jeff Bezos once called it).

Today, we are bringing you a lot closer to that world! The load balancing, auto scaling, and cloud monitoring features that I talked about earlier are now available. The features work together to help you to build highly scalable and highly available applications. Amazon CloudWatch monitors your Amazon EC2 capacity, Auto Scaling dynamically scales it based on demand, and Elastic Load Balancing distributes load across multiple instances in one or more Availability Zones. The measurements collected by Amazon CloudWatch provide Auto Scaling with the information needed to run enough Amazon EC2 instances to deal with the traffic load. Auto Scaling updates the Elastic Load Balancing service when new instances are launched or terminated to automatically scale the load-balanced capacity. You can instantiate, configure, and deploy these important system architecture components in seconds.

Amazon CloudWatch tracks and stores a number of per-instance performance metrics including CPU load, Disk I/O rates, and Network I/O rates. The metrics are rolled-up at one minute intervals and are retained for two weeks. Once stored, you can retrieve metrics across a number of dimensions including Availability Zone, Instance Type, AMI ID, or Auto Scaling Group. Because the metrics are measured inside Amazon EC2 you do not have to install or maintain monitoring agents on every instance that you want to monitor. You get real-time visibility into the performance of each of your Amazon EC2 instances and can quickly detect underperforming or underutilized instances.

Auto Scaling lets you define scaling policies driven by metrics collected by Amazon CloudWatch. Your Amazon EC2 instances will scale automatically based on actual system load and performance but you won't be spending money to keep idle instances running. The service maintains a detailed audit trail of all scaling operations. Auto Scaling uses a concept called an Auto Scaling Group to define what to scale, how to scale, and when to scale. Each group tracks the status of an application running across one or more EC2 instances. A set of rules or Scaling Triggers associated with each group define the system conditions under which additional EC2 instances will be launched or unneeded EC2 instances terminated. Each group includes an EC2 launch configuration to allow for specification of an AMI ID, instance type, and so forth.

Finally, the Elastic Load Balancing feature makes it easy for you to distribute web traffic across Amazon EC2 instances residing in one or more Availability Zones. You can create a new Elastic Load Balancer in minutes. Each one contains a list of EC2 instance IDs, a public-facing URL, and a port number. You will need to use a CNAME record in your site's DNS entry to associate your this URL with your application. You can use Health Checks to ascertain the health of each instance via pings and URL fetches, and stop sending traffic to unhealthy instances until they recover.

Here's how the services fit together:

All of this functionality is provided in web service and command-line form:

• You can call ListMetrics to get a list of statistics collected by Amazon CloudWatch, and then call GetMetricStatistics to retrieve them. Your call to GetMetricStatistics can include a number of parameters to specify the date range, desired metrics and statistics, metric granularity, and more. You can also use mon-list-metrics and mon-get-stats from the command line. There's a lot more info in the Developer Guide (HTML or PDF) and the Quick Reference Card.
• On the load balancing side, you start out by calling CreateLoadBalancer to create an Elastic Load Balancer, and will receive a DNS name in return. You can include a list of Availability Zones in the call or you can add them later using EnableAvailabilityZonesForLoadBalancer. From there you can add any number of health checks using ConfigureHealthCheck. A call to RegisterInstancesWithLoadBalancer will add your Amazon EC2 instances to the Elastic Load Balancer, and load balancing will commence. You can use elb-create-lb, elb-enable-zones-for-lb, elb-configure-healthcheck, and elb-register-instances-with-lb from the command line. Again, there's a lot more info in the Developer Guide (HTML or PDF) and the Quick Reference Card.
• For Auto Scaling you begin by calling CreateAutoScalingGroup, naming the group and providing the information needed to launch suitably configured Amazon EC2 instances. You then establish the scaling parameters using the CreateOrUpdateScalingTrigger function. The service will then launch Amazon EC2 instances as indicated by the scaling parameters. You can call DescribeScalingActivities at any point to fetch a list of recent scaling activities (instance launches and terminations). Command line equivalents are as-create-autoscaling-group, as-create-or-update-trigger, and as-describe-scaling-activities. Again, there's a lot ore info in the Developer Guide (HTML or PDF) and the Quick Reference Card.

If you're signed up for the Amazon EC2 service, you're already registered to use all of these new features and can begin using them via the web service APIs or Command Line tools. These new features are currently available in the U.S. region with EU region availability coming in the next few months.

You can use these services to make your AWS applications perform better without sacrificing application control freedom of development, choice of tools, speed of deployment, or any other kind of flexibility. You can be up and running with these new services in a matter of minutes. All of these new features are supported through our public forums and also through AWS Premium Support.

Morning Update:As always, a few interesting things came up after I put this post out last night:

1. Amazon CTO Werner Vogels wrote about these new features in his blog post, Automating the management of Amazon EC2 using Amazon CloudWatch, Auto Scaling and Elastic Load Balancing.
2. RightScale founder Thorsten von Eiken also wrote about them in his post, Amazon adds Load balancing, Monitoring, and Auto-Scaling..
3. There's a good discussion taking place on a Hacker News thread.

-- Jeff;

Comments

[Thomas]

this is great ... hope EU doesn't have to wait too long

[Pierre]

This is a great news and will help us to build great apps even faster! :) Thank you AWS!

[Ismael]

Hi,

It's great to see this introduced. It's a bit sad that there's always a lag between the introduction of services to the US region versus the EU region. Maybe one of these days, EU will get something first. ;)

Best,
Ismael

[Roger]

Its available in US, and not in EU... i dont understand what it means.

Are you talking of where the end users of your service are located OR where the Amazon EC2 servers are located?

Neither of them should matter.. right?

[Alex MacCaw]

It's exciting to see these features - I've been waiting a while for them.

However, the documentation isn't good - and there doesn't seem to be any documentation for the command line parameters - I had to play around quite a bit to get things to work.

Also, how is ConfigureHealthCheck meant to work - do I need to specify a /ping apache handler? Can I point it at /server-status?

I haven't got onto the auto scaling yet, but I have noticed the command line tool is called 'as' which conflicts with the Mac OS assembly tool.

I'm also having trouble with my DNS provider setting the CNAME for the root address, even though I can edit the bind file. I presume it's possible - and it's just my DNS provider's validation that is at fault. In either case, it would probably be a good idea to give some documentation for this - especially for less technical users.

[Damian]

Ismeal, it can matter depending on the type of data, particularly financal data. Not a technical issue, but a regulatory and legal one.

[Alex MacCaw]

So, it turns out you can only use the load balancing for subdomains, not your main domain.

I think this is a serious limitation and will be a deal breaker for many people.

Hopefully if enough people highlight this issue than Amazon will put it high on their priority list.

[Ismael Juma]

Damian, I think your comment was meant for Roger. I know it matters and my comments reflects that. :) Furthermore, it matters for technical reasons too, latency in particular.

Alex, that is a good point. It's a bit strange that they would limit it in that way.

Best,
Isamel

[frederic sidler]

This is great news, but…
But there is really something more important that is missing with AWS: email.
No businesses can run without email.

This is maybe not the place to talk about that, but you are constantly saying that you are listening to AWS customers. I can see posts everywhere in the forums talking about email problems from Amazon (old ones, new ones, always the same problem with Live, Yahoo, Gmail destination)

Is it so difficult to do? Do you prefer to relay on external email gateway. Do you fear spam from EC2. Finally thanks to the guys at Rightscale, we found a really good email gateway provider, but I really would prefer to be able to send email from Amazon directly. Such problems don't seem to exist with other cloud provider, isn't it?

[Mito]

CNAME issue is a deal breaker. To use this solution you'll have to hack something together, might as well stick to haproxy, pound etc. This need to be fixed before it will become useful.

[Holden Karau]

CNAME is challenging for me, I'm interested in setting up a load balancer for incoming mail, which rules out CNAMEs. Out of interest what was the reasoning behind requiring CNAMEs? Will this be changed in the future?

[PPC Management Service]

I must say it's very exciting to see all of these new features laid out! Thanks for presenting them to us in this fashion, as this really helps when it comes to understanding exactly how all of the new services actually work and fit together. This was really helpful, Jeff. Thanks! The Amazon CloudWatch feature is especially helpful. No telling how much time that will save in the long run.