Amazon EC2 monitoring, auto scaling & load balancing

Update 17th Jan 2010: Server Density now supports CloudWatch and can automatically pull in data from it.

Amazon have this morning announced the availability of the beta for their most frequently request features for their Elastic Compute Cloud (EC2) service – monitoring, auto scaling and load balancing.

Monitoring

Amazon CloudWatch is a web service that provides monitoring for AWS cloud resources, starting with Amazon EC2. It provides you with visibility into resource utilization, operational performance, and overall demand patterns—including metrics such as CPU utilization, disk reads and writes, and network traffic.

Auto scaling

Auto Scaling allows you to automatically scale your Amazon EC2 capacity up or down according to conditions you define. With Auto Scaling, you can ensure that the number of Amazon EC2 instances you’re using scales up seamlessly during demand spikes to maintain performance, and scales down automatically during demand lulls to minimize costs.

Load balancing

Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon EC2 instances. It enables you to achieve even greater fault tolerance in your applications, seamlessly providing the amount of load balancing capacity needed in response to incoming application traffic.

These services look like exactly what users of EC2 need to build their fully scalable and redundant infrastructure systems because prior to the availability of these products, all the above had to be done manually (either by hand or by writing a management system to handle it).

Where does Server Density fit in now Amazon does monitoring?

Our server monitoring application, Server Density, partly competes with the Amazon monitoring service. If you want to use the Amazon Auto Scaling service then their monitoring service, CloudWatch is required. This is clearly because the auto scaling is performed based on the statistics generated by the monitoring. CloudWatch is fully integrated into the AWS platform which means the APIs are similar and billing is centralised. I’m guessing it is also done at the physical machine level which is why the statistics can be generated without the need for any additional software. However, there are a number of advantages to using Server Density:

• CloudWatch provides no graphical interface. You must use the Amazon API to get the statistics from the service. Of course, you could use the API to write your own or use one of the products that will likely appear as a result.
• Monitoring data is only stored for 2 weeks, after which it is deleted. Even with our free service, Server Density stores data for 1 month, and 18 months with the paid service. This means that using Server Density, you can compare periods of time in the past to predict future seasonal demand.
• Since CloudWatch is not running on the virtual instance, it cannot get process information nor drill down to application specific metrics. CloudWatch provides details for CPU usage, network I/O and disk I/O. Server Density includes additional metrics such as memory usage, process count and Apache status. We have plans to add additional metrics and service specific monitoring.
• In addition, the Server Snapshot feature of Server Density gives you a graphical representation of the exact resource breakdown on your server at a particular point in time, as well as listing all the processes running. CloudWatch does not give you such a detailed breakdown to help troubleshoot, for example, high load events.
• CloudWatch integrates into the Auto Scaling service to launch new instances but it doesn’t have alerting so unless you roll out your own system, you cannot get e-mail or SMS alerts once metrics go over certain thresholds (e.g high CPU load). This is one of the core features of Server Density.
• Server Density is not specific to one platform so you can have a single dashboard to display the health of all your servers across multiple providers.

Which one should I use?

Clearly, CloudWatch has its uses. If you wish to use the Auto Scaling / Load Balancing services then since they are dependent on CloudWatch, it is necessary to use it. However, it should not be your entire monitoring setup just like Server Density should not be used in isolation.

Server Density provides a lot more detailed information about the health of your server, real time as well as historically. It also combines the essential alerting to ensure you’re notified when things go wrong. We use it combined with Pingdom to allow us to monitor our services up/down status from multiple locations. This combines the external monitoring of Pingdom with the internal monitoring of Server Density.

To ensure your servers are always running optimally, to handle demand spikes and to get alerted to and troubleshoot problems, you need a complete monitoring setup; one part of which can be Server Density.

If you have any questions, feel free to get in touch.