As i said, i ventured into all this for quite some time and found it to be a pretty workable solution for rendering, when done the right way.
You should keep a few things in mind though:
Amazon does not only charge the usage-time, but also the transfer-volume…allthough this is almost a neglectable amount of money. Just to give you an idea of the price-range: For our last project, we had around 70 Nodes up for around 2-3 days of renderwork. The project itself was around 4-5 GB with all the XRefs and stuff…the renderoutput was much more, as we rendered Floating-Point RPFs and several passes per scene. With all that in mind, we paid only around 10$ for the I/O-Transfers in and out of the cloud. That compared to the full renderprice of the project wasn´t even noticable
Stick with EBS-Backed instances. You have the choice to not do so, but i would definitely recommend you to take the EBS ones. The first advantage is, that you can run the windows server 2008 version only with EBS-Backed instances and i found win server 2k8 much easier to manage. The second…and way more important advantage is, that you can handle the creation and maintenance of the AMIs (amazon machine images) much easier when on EBS. You have to do some tricks though to get an EBS-booted machine to also be able to access all of its volatile, non-persistent storage. I can´t tell you why, but that is only possible, if you boot the image up by API-calls rather then the web-interface.
Try to stay in one availability-zone! You have to pay for internodal transfers from one zone to another. You dont have to pay much, but it isn´t necessary to pay at all, if you organize what you do before you do it. Amazon considers EU-West1a and EU-West1b also as different availability zones.
I found it easier - especially in the beginning - to create one AMI for the backburner manager-node, that is located in the cloud and an AMI for the render-nodes. The advantage of the manager in the cloud is, that it has a much better bandwidth. When rendering with backburner, all the rendernodes get their jobs from the manager and keep those as a local copy. That can sum up to quite a few hundred MB per Job, that have to be transfered from manager to rendernode. Doing that from home via VPN is almost ridiculous, because the usual uploadbandwidth for consumer-class-connections is around 1-7 MBit/s.
When you start to get bigger projects with the need for more rendernodes, this comes into account even more, as there might be times, when a couple of nodes want their job data simultaneously. You can´t handle that from home, but a manager-node inside the cloud can easily do that.
In our last project, we had to use a 4core, 7Gig Node as manager, because the network-traffic was really punishing that little thing. When there are around 20 nodes, that want to access data simultaneously and that data is around 800MB for each node, the gigabit-interface on the manager-node is really starting to hurt
It´s better to let the amazon-infrastructure handle this kind of stuff…
I´ll stop here, because i could possible write a lot more, but i am not sure, if you are interested in it and it would take some time.
As i mentioned initially - i am writing my masters thesis about cloud-based rendering and all it´s quirks at the moment, so i did quite a lot of tests for sure and would share that knowledge…if you don´t put it into a master thesis about that exact topic and publish that as yours