Amazon’s CloudWatch and other features

Catching up on some commentary…

Amazon recently introduced three new features: monitoring, load-balancing, and auto-scaling. (As usual, Werner Vogels has further explanation, and RightScale has a detailed examination.)

The monitoring service, called CloudWatch, provides utilization metrics for your running EC2 instances. This is a premium service on top of the regular EC2 fee; it costs 1.5 cents per instance-hour. The data is persisted for just two weeks, but is independent of running instances. If you need longer-term historical graphing, you’ll need to retrieve and archive the data yourself. There’s some simple data aggregation, but anyone who needs real correlation capabilities will want to feed this data back into their own monitoring tools.

CloudWatch is required to use the auto-scaling service, since that service uses the monitoring data to figure out when to launch or terminate instances. Basically, you define business rules for scaling that are based on the available CloudWatch metrics. Developers should take note that this is not magical auto-scaling. Adding or subtracting instances based on metrics isn’t rocket science. The tough part is usually writing an app that scales horizontally, plus automatically and seamlessly making other configuration changes necessary when you change the number of virtual servers in its capacity pool. (I field an awful lot of client calls from developers under the delusion that they can just write code any way they want, and simply putting their application on EC2 will remove all worries about scalability.)

The new load-balancing service essentially serves both global and local functions — between availability zones, and between instances within a zone. It’s auto-scaling-aware, but its health checks are connection-based, rather than using CloudWatch metrics. However, it’s free to EC2 customers and does not require use of CloudWatch. Customers who have been using HAproxy are likely to find this useful. It won’t touch the requirements of those who need full-fledged application delivery controller (ADC) functionality and have been using Zeus or the like.

As always, Amazon’s new features eat into the differentiating capabilities of third-party tools (RightScale, Elastra, etc.) with these services, but the “most, but not all of the way there” nature of their implementations mans that third-party tools still add value to the baseline. That’s particularly true given that only the load-balancing feature is free.

Bookmark and Share

Posted on May 28, 2009, in Infrastructure and tagged , . Bookmark the permalink. 2 Comments.

  1. Lydia,

    Thx for this. I am currently looking at what is being done by diffferent vendors to predict operational cloud costs and have some ideas for my company I think will be fruitful.

    Your comment that developers are disillusioned thinking cloud offerings will automatically give their application scale – do you have an idea about what types of applications can be moved to the cloud and scale?

    Are there application architectures that automatically ready you for the cloud?

    Steve Dykstra
    Product Manager Micro Focus


  2. Anything that scales horizontally on relatively small slices (in terms of cores/GHz and RAM), and that performs well under virtualization, should scale well on the cloud.

    Clean decomposition of the architecture into layers, and horizontal scalability of each layer, ought to lead to the cleanest cloud scaling.

    Highly recommend: The High Scalability blog, if you don’t currently read it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: