I just spent half a day (at least) looking at replacing ActiveMQ with Amazon SQS.

Short answer: don’t do it.

I’m using ActiveMQ as a message queue component in a dev system that will gradually be replaced by Amazon Web Services as we move towards a production system.

The message queue is being populated with messages from a Flash AS3 client, these messages contain data we are interested in storing but require more complex processing and doesn’t have to happen in real time.

Amazon SQS (and message queues in general) offers some great benefits over handling requests in real time: the most important to me being that it is already a managed load balanced service (meaning no single point of faliure), can store your messages for up to 4 days (which allows you to process all the data offline in chunks when you want) and reduces load on your central real-time gateway.

But alas, reality is not so rosy.

Problem #1
Amazon SQS is the ‘pay as you go’ message queue. There is no Amazon control panel for SQS, instead there is a simple Query/SOAP API and you are charged for every call into the API. It’s not much per request but it adds up, especially when you understand the fuzziness (and randomness) of load-balanced message queue systems.

Amazon don’t guarantee that you will ever get an really accurate idea of the number of messages on a queue. They also can’t guarantee that, when you poll the service for messages, you will receive all or any of the messages on the system (especially if the number of messages in the queue is < 1000).

So you may need to poll the system say 10 times (or more?) in order to get SQS to sample all the possible machines that may house messages on your queue, which means more calls into the API. And when you poll you need to ask how many approximate messages are available, another call, and then receive the messages and then delete them, more calls.

You can at least request up to 10 messages per call to receive(), which is at least something. Why not more or all?

I got to thinking, if I wanted to use SQS and have my message processors reasonably up to date then I may need 10 or so consumer instances continuously polling the queue, so multiple the above cost by 10, what if those 10 can't keep up?

Problem #2
Complexity. In 2009 Amazon added authentication to GET/POST requests, you get a secret key, you compute a hash of your 'message' and add it to the message, send it all across and keep your fingers crossed.

At the end of day, I've seen this working in 3 or 4 different languages, I've studied them, understood them and am still unable to get this working in AS3.

Maybe it's the fact that Amazon Web Services just say 'No, wrong signature, try again', or maybe it's just that documentation is far too explicit about the wrong things. Mayve the com.adobe.crypto and com.adobe.hurlant AS3 libraries aren't doing the right thing?

Most likely of course is that I am doing the wrong thing, but the very fact that I've been a professional contractor coding Flash and PHP for over 10 years and I still cant get this working means I've either suddenly taken a beating with the stupid stick (not ruling that out in the slightest) or it's just too damned complicated (when it should be very straight forward).

Problem #3
Let's say you generate this hash correctly, given enough time and brute force this is a reasonable assumption (I got as far as 12 HMAC-SHA permutations).

So your Flash app is sending messages to your message queue; someone looks at their network traffic and spots the call to an Amazon queue server, 'hmmm interesting' they say.

Because they know that somewhere in that Flash client is your secret key, which is required to compute an HMAC-SHA hash.

So they decompile the swf or use some fancy method of locating your key (since at some point it has to be in memory on the client machine). They are also able to easily grab the other essential parameters from the network calls which are required to formulate calls to SQS.

At this point they can spam your message queue and since you are charged for all calls to the server, it could get costly.

Very costly.

Also this is your secret key, you don't want this in the wrong hands.

Conclusion
There are a few places we can go now.

We can look for an alternative managed messaging queue service that provides some additional layers of security (perhaps something like a period call back on sampled messages to let us inspect traffic without continuous polling). Any message queue service we use would have to have a different cost infrastructure, the Amazon SQS approach leaves all the responsibility with the developers without giving them the tools to protect themselves.

We can replace the messaging queue with an 'online' consumer, load balanced and lean (we lose some of the luxuries of the message queue of course).

We can attempt to setup our own open source messaging queue system on something like ActiveMQ, load balance it and attempt to manage it, not really something that anyone wants to do.

We can route messages through a gateway, which defeats at least part of the point of using a managed load balanced message queue.

Don’t connect to Amazon SQS directly through Flash, if you really have to use it, route messages through a gateway with additional authentication, session checks and throttling. If you are sending your message to the server to get it signed, then just forward the message on from there.