This is nifty. Monitor EC2 instances and load balancers; CPU, data transfer rates, disk usage, disk activity, HTTP/TCP request counts/latency, “healthy/unhealthy” instances (see below). This data is both exposed via web service APIs, but also usable as input for their new “Auto Scaling” elastic scaling feature. Ideal for someone to write a Nagios plugin for. Also, I’m looking forward to some kick-ass sysadmin dataviz for this.
Elastically scale out (or in) your grid of EC2 instances, based on Amazon CloudWatch metrics. An officially-supported form of a myriad of third-party apps. I expect to hear of people accidentally spending a fortune due to accidental misuse of this ;)
Load balance across multiple EC2 instances, report metrics to Cloudwatch such as requests/second and request latency, and — most usefully of all in my opinion — shift traffic away from EC2 instances that fail to respond to a “health-check” HTTP GET with a 200, or fail to accept a TCP connection.
In other words, this provides a way to do decent HA on EC2, which is something that’s been much needed for a long time, and is quite tricky to set up using Linux-HA. I’ve done the latter, and found it full of potential reliability pitfalls; I found that Elastic IP addresses were not useful for quickly failing over to backup servers; in some cases, I found it taking about 5 minutes to fail over :( The only (relatively) snappy way to implement it was to set up a dynamic DNS record with a short TTL, point to it using a CNAME, and use “ddclient” to switch it when failing over. And even that could leave sites down for as long as it takes the DNS client to time out the existing cached CNAME.
Elastic Load Balancing supports HTTP or generic TCP connections. Unfortunately, it doesn’t support “real” termination of HTTPS connections, which is unfortunate. (You can terminate them as generic TCP connections, though.)