Amazon Elastic Block Store (EBS) provides block level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes are off-instance storage that persists independently from the life of an instance. Amazon Elastic Block Store provides highly available, highly reliable storage volumes that can be attached to a running Amazon EC2 instance and exposed as a device within the instance. Amazon EBS is particularly suited for applications that require a database, file system, or access to raw block level storage. Features of Amazon EBS volumes: Amazon EBS allows you to create storage volumes from 1 GB to 1 TB that can be mounted as devices by Amazon EC2 instances. Multiple volumes can be mounted to the same instance. Storage volumes behave like raw, unformatted block devices, with user supplied device names and a block device interface. You can create a file system on top of Amazon EBS volumes, or use them in any other way you would use a block device (like a hard drive). Amazon EBS volumes are placed in a specific Availability Zone, and can then be attached to instances also in that same Availability Zone. Each storage volume is automatically replicated within the same Availability Zone. This prevents data loss due to failure of any single hardware component. Amazon EBS also provides the ability to create point-in-time snapshots of volumes, which are persisted to Amazon S3. These snapshots can be used as the starting point for new Amazon EBS volumes, and protect data for long-term durability. The same snapshot can be used to instantiate as many volumes as you wish. Read more at http://www.amazon.com/b/ref=sc_fe_c_0_201590011_1?ie=UTF8&node=689343011&no=201590011

Man the Amazon stuff is cool... I love this idea of cloud computing. Oh crap! Now Dell is going to sue me. :) Congrats to Amazon on the ESB. Keep the cool stuff coming.

It's a nice feature, but it's not really "cloud compatible". Note that the devices are in "availability zones". And availability zones are effectively mechanisms that Amazon is promoting to let folks effectively co-locate resources. Because that's what they are, co-located. Which means that if you have a ESB bit in AZ1, you won't be able to connect to it from a machine in AZ2. If AZ1 is hit by something catastrophic (power, natural disaster), one of the major benefits of the cloud is gone, because ESBs aren't part of the cloud. They're part of a node in the cloud. And nodes fail. Again, it's a fine service, but it's completely different from something like S3 or SimpleDB, which are both Cloud Aware. So, you know, just be careful out there.

...Again, it's a fine service, but it's completely different from something like S3 or SimpleDB, which are both Cloud Aware. So, you know, just be careful out there.

Although there are tools to move ESBs to S3 and vice versa.

...Again, it's a fine service, but it's completely different from something like S3 or SimpleDB, which are both Cloud Aware. So, you know, just be careful out there.

Although there are tools to move ESBs to S3 and vice versa.

Sure, but that's a recovery option, not an availability option. The Clouds primary goal is availability and scalability.

...because ESBs aren't part of the cloud. They're part of a node in the cloud.

ESB's aren't part of the could, but they're part of the node which is in the cloud. So what plane of existence do these node reside? Even S3 goes down sometimes, and thus a true Cloud doesn't solve all your problems. Nothing does, but it's a good option for small companies that need variable resources or that might expand rapidly. ESB is a functional extension, and it works well for what it does. I'd certainly try it out in many circumstances.

TheSOABlog.com has some interesting details about EBS (see the GeekZone link off there). Can anyone answer the question about security on the new persistent storage to replace the non-persistent solution? No answers yet on TSB