First pattern from our series about EC2 Design Patterns.
Give API access to an EC2 instance created from a publically available virtual image (AMI).
Sometimes it is necessary that a server deployed on the EC2 platform has access to the EC2 API itself. Examples include access to persistent storage, instantiate other machine images to scale an application, reassign IP addresses, monitor other instances, change security groups, create key pairs, create snapshots for backup, and more. Any access to the API requires the EC2 credentials. Those credentials allow complete control over the whole platform of an Amazon account and must therefore be stored and communicated in a secure and reliable manner. Amazon EC2 provides a console via a web-interface that allows to deploy and startup Amazon Machine Images, but it does not allow to pass AWS credentials to the upstarting image.
Since the image is public and can be instantiated by many different accounts, the credentials cannot be stored on the image itself. Credentials can be passed as so called user data when an image is started via the API.
Use ExternalConsole when
- you want to apply an AMI that needs access to the EC2 API
- you want to facilitate deployments and especially avoid any manual interventions for the user who deploys the image (e.g. avoid starting the image using API command line tools, edit configuration files on the image, etc.)
- External Console: piece of software running outside Amazon EC2 with access to the EC2 credentials (by asking the user to enter them or by retrieving it from a database, for example). The main task of the external console is to deploy a virtual image on EC2 while passing the AWS credentials to it.
- AMI: Amazon Machine Image, e.g. a virtual image that needs access to the EC2 API.
- AMI Instance: the actual virtual machine instance resulting from deploying the AMI. The AMI Instance
- Image Provider: a person or organism that create the AMI
- Image User: a person or organism that deploys the AMI and manages AMI instances
- The Image User that wants to deploy an image connects to the External Console and instructs it to deploy a certain AMI
- The External Console retrieves the AWS credentials (e.g. from a database), connects to the EC2 API, and deploys the selected AMI while passing the AWS credentials to the upstarting AMI instance
- The AMI instance gets the AWS credentials as user data and stores them on local storage. It uses the credentials to perform API methods (e.g. to have access to persistent storage). Upon a reboot, it retrieves the credentials from its storage
The ExternalConsole offers the following benefits:
- From the perspective of the image provider: flexibility to provide abstraction to the image users from all possible EC2 dependencies. The External Console component is under the control of the software provider and can be adapted transparently for the end-user to any API modifications or new features
- From the perspective of the image user: ease of use. The credentials must be entered only once
At the other hand, it may have the following drawbacks:
- From the perspective of the image provider: additional costs to implement and run software outside EC2
- From the perspective of the image user, the AWS Credentials are given into the hand of an external provider and its measures to secure the access to the credentials
A couple of companies specialiced on managing EC2 deployments, life-cycle of images, and ease of configuration by providing an alternative web-interface to Amazon EC2 Console. All those companies have in common to store the AWS credentials on behalf of the user in their own database and use it for all operations involving the EC2 API. A list of those companies include RightScale, Enstratus, CloudKick, or Kaavo. Their approach uses the ExternalConsole pattern.
Note: this is work in progress. Any feedback, questions, or corrections is welcome and might be integrated in an updated version. If you use this pattern, let me know!