Amazon Elastic Compute Cloud Developer Guide Using Instances Launching and Using Instances This section details how to launch instances and retrieve instance specific data from within the image. It also covers launching shared AMIs and security risks associated with running shared AMIs. Using Instances The instance is your basic computation building block. It is a medium-sized host that provides you with the same predictable performance you would expect from a physical host. You can run on as many or as few as you need at any given time. Each instance predictably provides the equivalent of a system with a 1.7Ghz x86 CPU, 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth. Once launched, an instance looks very much like a traditional host. You have complete control of your instances. You have root access to each one, and you can interact with them as you would any machine. Best Practices Here are some suggestions for making the best use of Amazon EC2 instances. • Do not rely on an instance's local storage for valuable, long-term data. Instances can fail, and when they fail, the data on the local disk is lost. You should use a replication strategy across multiple instances to keep your data safe or store your persistent data in Amazon S3. • Define images based on the type of work your instances perform. For "internet applications" you may choose to define one image for database instances and one image for your webservers. Image creation and storage are cheap and easy operations. Individualize and customize as necessary. Keeping your images specialized will mean that the resulting AMIs can be smaller. Smaller AMIs will boot considerably faster. • Monitor the health of your instances. Make your instances work for you by monitoring each other. You may choose to create an image which contains one of the various open-source monitoring tools such as Nagios or OpenNMS. Each worker instance, based on your other images, might then report its health to your monitoring instance. • Keep your Amazon EC2 firewall permissions as restrictive as possible. Only open up permissions you need to open. Use separate groups to deal with instances that have different network ingress requirements. Consider using additional security measures inside your instance including your own firewall. If you need to login interactively (ssh), consider creating a bastion security group that allows external login, while the remainder of your instances are in a group that does not allow external login. API Version 2007-03-01 18
The new reader is still in beta!
(c) 2013 Tizra. All Rights reserved.