Amazon EC2 Limitations
Amazon’s Elastic Cloud Computing utility service has the capability to drastically change how Internet services are deployed, but it has some weaknesses that developers should consider before switching their applications to use EC2 functionality.
Today, Amazon rolled out their EC2 computing-as-a-utility cloud as an “unlimited beta”, which essentially means “anyone can sign up for EC2, but if things break, don’t blame us.” EC2, and virtualization in general, will undoubtedly change the future of Internet application deployment– even the smallest website, after a small list of code changes, will have the ability to scale to huge proportions. Amazon’s “pay for what you use” model is drastically different than the traditional “rent-a-box” model of hosting providers, and ultimately will likely become the route that more hosting providers take. For example, MediaTemple’s Grid Server is a more rigid container, but in that same utility model.
However, EC2 has some limitations that make it currently cost prohibitive vs. traditional hosting models, especially for specialized applications such as Heluna.
First, let’s be clear: for performance spikes, EC2 is a great equalizer. The ability to automatically bring up instances when needed, and bring them down after you’re done with them, gives developers a unique view into what resources their applications actually need.
The Heluna antispam service, as you might imagine, mostly requires CPU cycles in order to run the large amount of tests against every e-mail. Those CPU cycles follow a predictable pattern– just look at our statistics graphs– so EC2 instances could be brought up and down, however we also require a base amount of CPU cycles that grow over time and with each client that signs up. Also, the Heluna service has been planned out so that we are able to deal with all but the largest e-mail spikes, without having to bring up additional computing resources on the fly.
We have a rough idea of how many cycles the average message takes to scan, so based upon our current workload we can say how many Ghz of computing resources we need. The trouble with EC2 here is that the cost of CPU cycles is high (compared to the cost of memory and disk space availability, which is relatively low). While Amazon may reward the developer that gets lots of large activity spikes, they penalize the service that has a predictable amount of always-needed capacity.
Per Amazon’s documentation, “One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.” With a cost of $0.10 per 1Ghz per clock hour, a base “always in use” requirement of 5Ghz would run $0.50 per hour, or $360 per month. Contrast that with a hosting provider offering a dual processor dual-core 2Ghz-per-core solution (essentially, 4×2Ghz or 8Ghz) for $339 per month.
The EC2 model would offer more memory, but currently Heluna is not a memory bound application. Our goal is to get messages into memory, process them, then either dump them into our database (per the user’s quarantine), discard them, or ship them off to the client’s mail server. Either way, operation of the service does not require an enormous amount of memory.
Lastly, Heluna does require a fair amount of bandwidth. Again, as you can imagine, most of our bandwidth is incoming (completely different from almost every other Internet application) but for each message we process, there are a collection of network tests performed, including DNS checks, distributed checksums, having to make round trips to our database, etc, and finally routing a clean message to its rightful place. 1000GB of inbound bandwidth would cost $100. In contrast, almost every hosting provider will include a set amount of bandwidth with their monthly fee; in many cases, it can be at least 2000GB.
In summary: if your application requires a considerable amount of memory, with little to no CPU consumption, and you either do a very small amount of bandwidth or a very, very large amount of bandwidth, EC2 may be the perfect platform for you. Also, if your application is still using a very small amount of resources, the base single-EC2 unit would be very useful. However, until the cost of CPU cycles comes down at Amazon, Heluna will continue to be hosted using a more traditional hosting model.

[…] Read the rest of this great post here […]
Pingback by amazon » Amazon EC2 Limitations — October 18, 2007 @ 3:54 pm
Amazon EC2 falls well short of UK-based FlexiScale that was just launched at Future of Web Apps earlier this month and has so many benefits that Amazon fails to offer. To mention just a few, support for MS Windows, static IP, access to API, 99.99% SLA. Basically it knocks the socks of Amazon and some EC2 users are already moving over to it so what better endorsement could there be.
Comment by Christine Gupta — October 19, 2007 @ 2:35 am
The fact that most production applications have predictable resource requirements hasn’t gone unnoticed. At 3tera, we’ve chosen to partner with hosting providers to build our utility computing service partially for that reason.
Partnering with hosting providers also enables our users to run in multiple data centers for both redundancy and scaling - another requirement for serious production use.
Comment by Bert Armijo — October 28, 2007 @ 9:59 pm
ElasticHosts is another competitor - we provide UK-based virtual servers for all PC operating systems along with a complete suite of web hosting services. Our virtual servers are controlled from a simple web interface, which allows users to instantly scale up or down and to take snapshots of the entire running machine state for backup.
Comment by ElasticHosts — June 23, 2008 @ 3:29 pm