I've found it easier to think of an EC2 image's 150GB of 'disk' as RAM, and Elastic Block as an actual hard drive. EC2's disk is there when it's powered on, but

I've found it easier to think of an EC2 image's 150GB of 'disk' as RAM, and Elastic Block as an actual hard drive. EC2's disk is there when it's powered on, but when you turn it off, all data disappears. Elastic block is really EC2's hard drive. Two issues that burned me a couple of months ago with EC2 and Elastic Block: I built my server and got it running just right. I then wanted to back it up, so I bundled it (save your instance to S3) but forgot to register it(list your S3 bundle as a privately available AMI). When I terminated my instance I wasn't able to restart it, because it wasn't available in my list of registered AMI's. I had to rebuild my server from scratch. The second problem that I had was in rebuilding my database after my instance terminated. Postgres keeps the log files (transactions the database has completed) in the install folder and the data file(what the database has stored) in the storage folder. When I terminated my instance, I lost all the log files that were stored on the EC2 'disk'. I had the data file on elastic block, but the log files were gone. The standard recovery process for postgres needs log files. It took me a day to figure out how to rebuild the database from just the data files. I now have both the database and the log files on my elastic block image. Hopefully that will help the next time I kill my server. :) I also now have automated backups of everything.