Recently Amazon announced a new Micro Instance for EC2 which costs significantly less then a standard small, and contains the ability to "burst" CPU usage. This new instance type leads developers more and more to using many instances to perform tasks since it's far easier to scale out.
This also marks the first Instance that doesn't contain any ephemeral storage at all, meaning you have to set up each instance on an EBS volume, and you can't simply run one off of an AMI. Additionally, if your instance dies, you'll have to fix or replace that EBS volume, instead of simply tossing it away.
Amazon points out that this method of booting from EBS is faster then copying from S3, and does provide a few advantages. While it's true that the Initial boot process will be faster, it's been tested and proved that the Ephemeral disks are faster then EBS volumes. This means that if you're doing any sort of heavy disk IO, especially temporary writes, EBS will be much slower for you, and you've got no other option for Micro instances.
I love the idea of Micro instances, and I understand that Amazon was saving money (and passing that savings on to the consumer) by not proving a large Ephemeral disk with each instance, but really not even a 10GB root partition? This new step in Amazons recent history seems to be a major step backwards, showing that EBS-backed instances will be their future supported instance of choice, instead of providing support for the disposable instance model.
If anyone at Amazon is listening, I'm not asking for much, just let us have 10GB of free Ephemeral storage for these Micros. This Ephemeral storage gives us a lot of usability for free, which is exceptionally useful for things that are temporary.
This also marks the first Instance that doesn't contain any ephemeral storage at all, meaning you have to set up each instance on an EBS volume, and you can't simply run one off of an AMI. Additionally, if your instance dies, you'll have to fix or replace that EBS volume, instead of simply tossing it away.
Amazon points out that this method of booting from EBS is faster then copying from S3, and does provide a few advantages. While it's true that the Initial boot process will be faster, it's been tested and proved that the Ephemeral disks are faster then EBS volumes. This means that if you're doing any sort of heavy disk IO, especially temporary writes, EBS will be much slower for you, and you've got no other option for Micro instances.
I love the idea of Micro instances, and I understand that Amazon was saving money (and passing that savings on to the consumer) by not proving a large Ephemeral disk with each instance, but really not even a 10GB root partition? This new step in Amazons recent history seems to be a major step backwards, showing that EBS-backed instances will be their future supported instance of choice, instead of providing support for the disposable instance model.
If anyone at Amazon is listening, I'm not asking for much, just let us have 10GB of free Ephemeral storage for these Micros. This Ephemeral storage gives us a lot of usability for free, which is exceptionally useful for things that are temporary.
Comments
This isn't correct. EBS-backed instances still use AMIs. You just create AMIs from EBS snapshots (i.e. register-image ) rather than from S3 paths.
Additionally, if your instance dies, you'll have to fix or replace that EBS volume, instead of simply tossing it away.
Also incorrect. The launch/terminate semantics are identical between EBS-backed instances and S3-backed instances. If your instance dies you are just as free to toss it away, and the volume will be deleted for you (unless you gave a specific deleteOnTermination=false flag to RunInstances).
With EBS-backed instances, however, you have the option of stopping your instance to do diagnostics / forensics / troubleshooting on its root volume by attaching it to another instance - a major advantage!
You point out two minor mis-communications as a "tragic flaw in my logic". Let me rephrase:
This isn't correct. EBS-backed instances still use AMIs. You just create AMIs from EBS snapshots (i.e. register-image ) rather than from S3 paths.
You can't use Existing non-EBS based images (for which there are a TON of useful images) for EBS-rooted images. I don't consider EBS-snapshots AMIs, but if you do then simply put, you can not use non-EBS AMIs for EBS instances. You'd have to copy the root disk over to an EBS snapshot (which is still in S3 isn't it?).
With EBS-backed instances, however, you have the option of stopping your instance to do diagnostics / forensics / troubleshooting on its root volume by attaching it to another instance - a major advantage!
Ok, you don't have to, but I'm betting that 90% of people will. It promotes that sort of behavior, which is the only functionality that I see out of it, hence why I don't like it at all.