Tips, Points to consider while building EC2 AMI's

This article is syndicated from Sanket's Blog : http://sanketdangi.com/post/52050147104/points-to-consider-while-bundling-ami

According to AWS, “Amazon Machine Images (AMIs) are the basic building blocks of Amazon EC2. An AMI is a template that contains a software configuration (operating system, application server, and applications) that you can run on Amazon’s proven computing environment.”

For example, an AMI might contain the software to act as a web server (Linux, Apache, and your web site) or it might contain the software to act as a Hadoop node (Linux, Hadoop, and a custom application).

There are three types of AMI’s :

A.      Public AMI – These are the ones which are freely available, advertised and shared with all AWS accounts. AWS has a huge collection of Public AMI’s.

 B.      Paid AMI – These are the ones which you can purchase from AWS marketplace, developers or service contract with any organization like RedHat.

 C.      Private AMI – These are the AMI’s which are generated from Public AMI’s and customized by us for our future use. They are available in only our AWS account. If we want we can share these AMI’s with other AWS accounts too. Also, if we want to share our private AMI with whole AWS community, we can convert that into a public AMI.

Below mentioned are some pointers which one can consider before bundling AMI’s :

1.       Remove Authorized Keys

Before bundling an AMI out of your current instance, please make sure to remove existing entries in .ssh/authorized_keys else the key from which the instance is launched will be automatically included. In case you forget to remove that entry, login into new instance (coming from newly bundled AMI) is only possible through old keypair. New keypairs won’t work.

For e.g.,  if the current instance is launched using keypair-1.pem and before bundling AMI, you have forgot to remove entries from authorized_keys, then access to new instance from newly bundled AMI is only possible through keypair-1.pem only. If you launch new instance using keypair-2.pem, we won’t be able to login into instance using keypair-2.pem file.  

Important : You will lose access to your current instance if you remove authorized_keys and exit from your current ssh session. Hence, ssh into same instance won’t be allowed.

2.       Delete history

It is always good to clear your command history.  before bundling an AMI. For clearing your command history, remove .bash_history or issue command “history –c”. There are possibilities that you might have issued commands using your access key and secret keys, private key pairs or other sensitive information.

3.       Provide meaningful names

It is advisable to provide meaningful names to your AMI’s and also post small description. It provides easy search for other users. This is strongly recommended if you plan to make your AMI as Public AMI.

4.       Empty log files

It is always good habit if you clear your existing log files before bundling AMI. Your instance might have logs files from various packages like apache, tomcat etc.

5.       Remove sensitive data

Don’t forget to remove any private keypairs and x.509 certificates or any additional confidential sensitive data if used.

6.       Delete all downloaded packages and files

If you have downloaded some packages (like s3cmd tools) or additional files and configured them on your instance, please remove them before bundling AMI.

7.       Disable SELINUX while bundling instance store backed AMI’s

If you are bundling instance store backed AMI’s, please remember to disable SELINUX before issuing ec2-bundle-vol command.