3 ms·

I'm not a web developer but somewhat curious, so please excuse this potentially inane question: How much can I actually do with one Micro Instance? Is it compar

by apl 16y ago

I'm not a web developer but somewhat curious, so please excuse this potentially inane question: How much can I actually do with one Micro Instance? Is it comparable to, say, a VPS in terms of handling and capabilities? Or is it an entirely different animal?

bmelton 16y ago
This is pretty comparable to a Linode 512 slice, but with a little more memory. The configuration is VASTLY different however. EC2 instances are basically writable CD images -- which is to say, whatever you 'imprint' it with as the image is what it will be every time it's rebooted. You can store /tmp and /dev/null content on the instance just fine, so long as you know they won't be there when you reboot. You are free to take 'snapshots' of important changes (like, I just deployed my new app, let's create a new image). To supplement this, they're also offering Elastic Block, which is an on-demand, resizable static partition. This is your long-term disk, but it's sold seperately, and has different usage / pricing metrics. Generally speaking, you allocate your storage, then build your EC2 image, then create a mount, set up your application / server configuration / etc, then take a snapshot. That snapshot is the image you'll boot in the future.
- apl 16y ago
  Thanks. Is it feasible at all to (ab-)use this free Micro instance as a real development machine for running little experiments? Assuming I keep one instance running at all times, without adding any new ones, it seems like I could just ignore the fluid snapshot system and treat it like a bog-standard VPS.
  - bmelton 16y ago
    So, the reliability may not be there for that. If an instance crashes, or becomes unavailable, or is, at the whim of Amazon, turned off, you've completely lost your settings. You can still use them as a standard VPS, of course, if you just take a little care and mount a static file system up front, then use that for all dynamic content/database store/uploads/etc. The only real difference is that your persistent file store is completely separate from the instance, which threw me for a big loop when they were new, but has become old hat since then. I don't know what the reliability is nowadays, but there used to be (when it was very new) complaints that the instances would crash or come offline without notice, and that as with all things, it would happen at very inconvenient times. With care, and forethought, it's preventable, of course; but what happened then was people trying to do exactly what you suggest, only to be thwarted by the unreliability of the system. Of course, the beauty of it, if planned for, is that it doesn't NEED to be reliable. If you use the Elastic Load Balancer, you can spool up pre-configured instances at the drop of a hat that service demand, and if one crashes, it's easy enough to replace with a brand new instance. The instances can all share a persistent file store, they can all be dynamically registered with the load balancer. They can all function on their own with relative autonomy (which is how businesses like CloudKick make their money.) If nothing else, I'd advise you take advantage of this deal and play around with it. It's a neat little system, and their elastic IP addresses are something of a thought exercise at the beginning, and nothing short of brilliant after you've figured it out. You'll learn something, and that's always worth something.
- jberryman 16y ago
  That is correct for classic ec2 instances, but in this particular case the offer is for a "micro" instance which uses ebs booting. So it works less like your writable cd image analogy and more like what you'd have with linode http://aws.amazon.com/about-aws/whats-new/2009/12/03/amazon-ec2-instances-now-can-boot-from-amazon-ebs/ http://aws.amazon.com/about-aws/whats-new/2009/12/03/amazon-...

by apl 16y ago

bmelton 16y ago

This is pretty comparable to a Linode 512 slice, but with a little more memory. The configuration is VASTLY different however. EC2 instances are basically writable CD images -- which is to say, whatever you 'imprint' it with as the image is what it will be every time it's rebooted. You can store /tmp and /dev/null content on the instance just fine, so long as you know they won't be there when you reboot. You are free to take 'snapshots' of important changes (like, I just deployed my new app, let's create a new image). To supplement this, they're also offering Elastic Block, which is an on-demand, resizable static partition. This is your long-term disk, but it's sold seperately, and has different usage / pricing metrics. Generally speaking, you allocate your storage, then build your EC2 image, then create a mount, set up your application / server configuration / etc, then take a snapshot. That snapshot is the image you'll boot in the future.

apl 16y ago
Thanks. Is it feasible at all to (ab-)use this free Micro instance as a real development machine for running little experiments? Assuming I keep one instance running at all times, without adding any new ones, it seems like I could just ignore the fluid snapshot system and treat it like a bog-standard VPS.
- bmelton 16y ago
  So, the reliability may not be there for that. If an instance crashes, or becomes unavailable, or is, at the whim of Amazon, turned off, you've completely lost your settings. You can still use them as a standard VPS, of course, if you just take a little care and mount a static file system up front, then use that for all dynamic content/database store/uploads/etc. The only real difference is that your persistent file store is completely separate from the instance, which threw me for a big loop when they were new, but has become old hat since then. I don't know what the reliability is nowadays, but there used to be (when it was very new) complaints that the instances would crash or come offline without notice, and that as with all things, it would happen at very inconvenient times. With care, and forethought, it's preventable, of course; but what happened then was people trying to do exactly what you suggest, only to be thwarted by the unreliability of the system. Of course, the beauty of it, if planned for, is that it doesn't NEED to be reliable. If you use the Elastic Load Balancer, you can spool up pre-configured instances at the drop of a hat that service demand, and if one crashes, it's easy enough to replace with a brand new instance. The instances can all share a persistent file store, they can all be dynamically registered with the load balancer. They can all function on their own with relative autonomy (which is how businesses like CloudKick make their money.) If nothing else, I'd advise you take advantage of this deal and play around with it. It's a neat little system, and their elastic IP addresses are something of a thought exercise at the beginning, and nothing short of brilliant after you've figured it out. You'll learn something, and that's always worth something.
jberryman 16y ago
That is correct for classic ec2 instances, but in this particular case the offer is for a "micro" instance which uses ebs booting. So it works less like your writable cd image analogy and more like what you'd have with linode http://aws.amazon.com/about-aws/whats-new/2009/12/03/amazon-ec2-instances-now-can-boot-from-amazon-ebs/ http://aws.amazon.com/about-aws/whats-new/2009/12/03/amazon-...