When To Use Amazon EC2 t1.Micro Instances

Lets take a look at how Amazon EC2 t1.micro instances generally work so that we can understand how to apply them. By the end of reading this you should have a clear view of the instance’s behavior so you can understand its performance.

Amazon Web Services EC2 t1.micro instances provide a small amount of consistent CPU resources and allow you to increase CPU capacity in short bursts when additional cycles are available. They are well suited for lower throughput applications and web sites that require additional compute cycles periodically.

When NOT to use Amazon EC2 T1.Micro Instances

t1. Micro Bad Fit - Wide CPU usage

The figure above shows the profile for an application that isn’t appropriate for a micro instance. The application requires continuous data-crunching CPU resources for each request, resulting in plateaus of CPU usage that the micro instance isn’t designed to handle.

t1.Micro Bad Fit Frequent CPU Spikes

The above figure shows another profile that isn’t appropriate for a micro instance. Here the spikes in CPU use are brief, but they occur too frequently to be serviced by a micro instance.

t1. Micro Bad Fit High Background CPU Load

The final example that isn’t appropriate for a micro instance. Here the spikes aren’t too frequent, but the background level CPU between spikes is too high to be serviced by a micro instance.

When to use t1.Micro Instances

Related:  Tuning MySQL: my.cnf, avoid this common pitfall!

t1.Micro Good Fit

The t1.micro instance is designed to operate with its CPU usage at essentially only two levels: the normal low background level, and then at brief spiked levels much higher than the background level. Amazon allows the instance to operate at up to 2 EC2 compute units (ECUs). This is more than the m1.small and the same as the m1.medium. The above figure shows a CPU load profile that IS appropriate for a micro instance. Here the spikes in CPU use are brief and also far apart with very low background level CPU. This is usually a website with low traffic and/or well tuned with medium traffic where the spikes can be hours or days apart (cron backup scripts for example).

Your setup and web application will be different but for the most part your CPU profile should fall within one of these 4 examples.

AMI Optimization for Amazon EC2 T1.Micro Instances

If you’ve seleted to setup a t1.micro instance here make sure to design the AMI to run on “600” MB of RAM or less, limit the number of recurring processes that use CPU time (e.g., cron jobs, daemons), if you are running popular PHP applications such as WordPress, Drupal, Joomla, etc then make sure to install an opcode cache and add plugins which focus on moving processing from the CPU and caching them to RAM (tweak cache TTL and purging to avoid overloading RAM).

Related:  Memcache PHP Extensions for Memcached Caching Daemon

Two Websites I’ve setup using Amazon EC2 T1.Micro Instances

UPDATE: Since the article I’ve sold AltEnergyShift.com. Also, Bluecloudsolutions.com is now hosted by Stacklinux.com.

Altenergyshift.com CPU Last 24 hours

Currently the t1.Micro that runs AltEnergyShift.com web forum uses Ubuntu 8.04 AMI (i know, i know shh) that I striped down to use less than 50MB at boot! Next, I install LEMP and the RAM usage is still below 150MB at boot. However, because of nightly DB backup & especially the weekly web directory backup crons it uses all RAM.

Bluecloudsolutions.com CPU Last 24 hours

Next, I’m currently running Carter Thomas’ Bluecloudsolutions.com (over 100,000 page views per month) on a t1.Micro as well. Since this is not my website I could not play around or tweak as extreme as I did with the previous example. Therefore, I choose the default Amazon AMI (CentOS based). Stripped down to 90MB on boot and then loaded it up with LAMP. As with LEMP, I also stripped and custom tuned LAMP. However, after setup, Bluecloudsolutions grew in traffic within the first week, just enough to hit CPU steal due to the background level CPU being too high and thus triggered many high CPU CloudWatch alerts each day. So I re-sized to m1.small (site loaded slower but prolonged use of CPU capacity is more as explained above) then re-tuning Apache a bit more to address the spikes and was able to reduce and stabalize load significantly. Now, his website is back to t1.Micro.

Related:  Best Linux distro and Desktop Environment Combinations.

Sources: AWS Documentation | AWS EC2 Home