I have an EBS based Amazon EC2 instance (m4.xlarge) up and running. This one, say example has been in use for a while and is in a state that we would like to have for all our future instances.
Which of the following two approaches would be more cost-effective?
-
Snapshot:
Create a snapshot ofexample. Then every time a new instance is needed, create a new volume from the snapshot and attach it to the instance. -
AMI:
Create an image fromexample. This image has everything needed, so keep spinning of new instances from this image.
Which one of these would be a better cost-effective strategy in the long run? Any implications between the two approaches? Are there are any other ways to achieve same goal?
Best Answer
The question is premised on incomplete information.
An AMI consists of one or more snapshots -- which are billed exactly the same as any other snapshot -- plus a few bytes of metadata. There is no documentation of a charge for storing the metadata that I am aware of. If it is billable, it will be such a small charge as to go unnoticed.
If you are going to be creating new instances, you have to start with an AMI. You can't create an instance without one. When you launch instances, you always choose an AMI, even if it happens to be an AMI with a base OS installation on it.
So, regarding cost, there's no meaningful difference, and regarding AMIs, there's no meaningful alternative... at least, for snapshot based provisioning. I mean, sure you could store compressed tarballs or raw disk images in your own files, and extract them on to disks, but those are less-than practical options.
Many would argue that, in a cloud environment particularly, a superior approach to snapshot/image-based provisioning is to use a tool like Ansible to automatically provision your machines starting from a base OS install and ending up with a working system with all dependencies and code in place -- which allows your configuration to exist as a set of reproducible steps, which you can manage in version control.
Of course, "automatically" sounds like magic. We're not talking about magic, we're talking about automated execution of a predefined set of steps that are tested and known to work and produce the desired result.
Up front, doing all of that setup and testing is likely to be more work, but on the long tail, the idea is that it's a much smoother ride, because you know exactly how your systems are supposed to get the way they are supposed to be.
My intention is not to endorse this as superior in this answer, but as an old dog from the old school, this new trick is growing on me.