Not to confuse with stateful vs stateless API....
As we know, EC2 has no state for the instances. If you power-off and terminate a machine, it's gone. You can't start up the exact same VM again. You *can* start up another copy of the same image, but it'll lack any changes you made, of course.
And I consider that to be a Good Thing, when doing cloud computing. If some virtualization fabric provides stateful machines (ie, RHEV-M, VMware), I think it's still best to ignore that if you're truly wanting to deploy using "the cloud methodology".
My view of the cloud is based upon homogeneity, particularly if you're wanting to scale up/down over time, or have instances simply fail. For example, in our JBoss demo, we start with a cluster of 2 AS nodes. As demand increases, we want to add 2 more node *just like* the existing 2 nodes. As demand falls, we want to be able to kill off any 2 of the now 4 nodes, to conserve resources.
If we assume statefulness of the VMs, it seems we're no longer thinking in terms of commodity/utility computing.
I do like EC2's EBS, though, for maintaining data, which should not be ephemeral. Glue that to your DB node. If the DB node fails, mount the storage partition on another copy of the DB node. Or mount it on an updated version of the DB node.
Ultimately, if you develop your images (or portfolio of cooperating images) to behave well in a stateless environment, I think you'll end up follow more "best practices" in terms of fail-over, scalability and management.
If you develop assuming your nodes are stateful, you're also more apt to "park" them somewhere "just in case". Or end up being too reliant upon a very particular instance as it's evolved over time.
Assuming statelessness helps ensure you separate compute resources from storage resources, and have something you can spin up multiple times in a meaningful way. Makes it more cloudy above and beyond just virtualizationy.
But that's just me, feel free to disagree.
-Bob