Most people like to “customize AMIs”, which basically means to:
a) Stop The Instance
b) Create a Snapshot
c) Store the AMI (which is basically a manifesto + Default Amazon Kernel Image (AKI) Id + Root Filesystem Image + EBS Snapshot) into the EC2 Registry
d) Start the Instance
I strongly advise you *NOT* to do that for medium-to-large projects (key aspect: Beyond a single Region), for one sole reason: AMIs are bound to a single Region, so this id is valid only at this region.
Also, this process is so error-prone and wasteful (you’ll have to do that in EACH REGION) that it makes my eyes roll whenever I hear about it
OTOH, it makes much more sense to develop some good habit and use chef scripts + user-data-fu in order to bring versionable (I’m a huge fan of Software Change Management), portable (you just keep reference of the AMI ids), and well-behaved modification scripts. Done correctly, most will boot under 15 mins from zero to hero.
THEN you could consider generating an AMI, but I think chef + user-data is enough for 80% of the cases of customizations.
A good primer on user-data comes from… me:
http://www.newvem.com/need-for-automation-cloud-style-building-ubuntu-appliances-on-ec2-with-cloud-init/
(While we use Ubuntu, now even Amazon Linux as well as some CentOS Images now support cloud-init)
Also, go for chef:
http://chef.opscode.com/
|