This JIRA is a container JIRA that will capture any sub-tasks required for AMI documentation.

Initial basic triage done by Elspeth Thorne would suggest the following topics.

Set up EAP Image

• need to have the AMI on amazon
• Configure security groups - ports and services that can access/transmit from the instance.
• SSH/HTTP(/HTTPS?/Database?) depending on what services the EAP instance is intending to use (post installation
  config)
• authorise specific IP addresses for access to these ports (admin config guide, security)
• can connect via ssh. Once this is set up, there is commandline access to the cloud instance.
• GUI (eg JON, Admin Console) unknown, or possibly by standard remote access methods.

Updating

• updating/adding components such as native libraries will be slightly different, if not shipped with the image.
• Will require doing a scp over the ssh tunnel to make the files availble on the instance machine.
• Persistent data - EBS volume required, database store. Possibly also for config of EAP.
  From "AWS Cloud Best Practices", http://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf.

Roles:

Every Instance should have a role (“DB server”, “app server”, “slave server” in the case of a Web application) to play
in the environment. This role may be passed in as an argument during launch that instructs the AMI when instantiated the
steps to take after it has booted. On boot, instances should grab the necessary resources (code, scripts,
configuration) based on the role and “attach” itself to a cluster to serve its function.
...
3. Store and retrieve machine configuration information dynamically: Utilize Amazon SimpleDB to fetch config data during
boot-time of an instance (eg. database connection strings). SimpleDB may also be used to store information about an
instance such as its IP address, machine name and role.

Ephemeral Storage and AMI Customization

Customising AMIs (from http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/):
If you customize your instance with ephemeral storage devices or additional EBS volumes besides the root device, the new
AMI contains block device mapping information for those storage devices and volumes. When you then launch an instance
from your new AMI, the instance automatically launches with the additional devices and volumes.

• Processes for windows and linux appear to be quite different.
• To create a customised EAP AMI:
• create a vanilla EAP AMI
• follow the amazon process for customisation and making those customisations persitent in a customer AMI.

• EAP AMIs will probably not come with ESB precofigured - from the 'Creating Paid AMIs' section of
  http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/:
  "Amazon DevPay does not support Amazon EBS-backed AMIs. All paid AMIs must be backed by Amazon S3."
  This will impact instructions for persistent data store.