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.

A quick, easy way to help reduce the amount of spam attempts to your domain is in the use of “bad” MX records. With the correct MX setup, properly-formatted mail servers will still send e-mail to you, while a large portion of spammers will bypass your domain.

First, a quick tutorial. A DNS MX record is a “mail exchanger” record for your domain; it tells mail servers how to send e-mail to your domain. The MX record is set to either your own mail server, or (in the case of smaller domains) your ISP’s mail server. There can be more than one MX record per domain, which is why each MX record contains a number indicating its priority. For example, the MX records for cnn.com are:

cnn.com mail exchanger = 30 lonmail1.turner.com.
cnn.com mail exchanger = 40 hkgmail1.turner.com.
cnn.com mail exchanger = 10 atlmail3.turner.com.
cnn.com mail exchanger = 10 atlmail5.turner.com.
cnn.com mail exchanger = 10 nycmail1.turner.com.

As you can see by the records, any mail server trying to send e-mail to someone@cnn.com needs to connect to the machines “atlmail3.turner.com” or “atlmail5.turner.com” or “nycmail1.turner.com”. If those machines are offline, e-mail should go to “lonmail1.turner.com” and finally, if that machine is down, e-mail should go to “hkgmail1.turner.com”.

Now, many spammers choose to ignore this rule and will instead only attempt to go to one of the MX records and then give up. In our case, if a spammer tried to connect to “atlmail3.turner.com” and it was offline, the spammer would move onto the next spam target and CNN wouldn’t get that piece of spam.

Armed with the knowledge that well-behaved mail servers will always try the next MX record, and many spammers will abandon their attempt, a simple strategy appears: always have the first MX record fail. If the first MX record for your domain always rejects connections, the amount of spam attempts should drop, while legitimate e-mail will still go through.

So, let’s say your e-mail server is located at “mail.yourdomain.com”. Your MX records probably look like:

yourdomain.com mail exchanger = 10 mail.yourdomain.com.

We need to add an MX record that always rejects e-mail connections, like so:

yourdomain.com mail exchanger = 5 badmx.yourdomain.com.
yourdomain.com mail exchanger = 10 mail.yourdomain.com.

(Obviously in this scenario you would need to set up the IP address for “badmx.yourdomain.com” and have it point at a machine that did not have e-mail service on it.)

Now– this will reduce the amount of spam attempts, but many spammers will actually choose the highest priority MX record as the target of their attack. In our case, a spammer will go directly to mail.yourdomain.com without trying badmx.yourdomain.com. To solve this issue, we add a second MX record with a higher priority than your mail server. To revisit our previous example, the MX records would then look like:

yourdomain.com mail exchanger = 5 badmx.yourdomain.com.
yourdomain.com mail exchanger = 10 mail.yourdomain.com.
yourdomain.com mail exchanger = 20 badmx2.yourdomain.com.

This would catch a large amount of spammers, and should still allow valid e-mail servers to send you e-mail.

For smaller domains that don’t have the ability to arbitrarily add or remove hosts but can still make changes to their DNS, Heluna offers two MX records that perform exactly this function. “reject1.heluna.com” and “reject2.heluna.com” both refuse any e-mail connections, so your list of MX records can look like so:

yourdomain.com mail exchanger = 5 reject1.heluna.com.
yourdomain.com mail exchanger = 10 mail.yourdomain.com.
yourdomain.com mail exchanger = 20 reject2.heluna.com.

Be sure to adjust the records to fit your domain; make sure that one of the Heluna servers is a lower priority than your mail server, and that the other Heluna server is a higher priority than your mail server.

Did this solution help you? Are you using the Heluna reject servers to reduce your incoming spam attempts? Let us know in the comments!