AMI and Instance Concepts

• Compresses the image to minimize bandwidth usage and storage requirements

• Encrypts and signs the compressed image to ensure confidentiality and authenticates the image against its creator

• Splits the encrypted image into manageable parts for upload

• Creates a manifest file that contains a list of the image parts with their checksums

• Do not rely on an instance's local storage for valuable, long-term data.

  When instances fail, the data on the local disk is lost. 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 they perform.

  For "Internet applications," you might define one image for database instances and another for web servers. Image creation and storage are cheap and easy operations, so you can individualize and customize as necessary. Specialized images can result in smaller AMI sizes, which boot considerably faster.

• Monitor the health of your instances.

  You can make your instances work for you by configuring them to monitor each other. For example, you could create an image that contains a monitoring tool (e.g., the open-source Nagios or OpenNMS on Linux and UNIX). Then, your other instances could report their health to the monitoring instance.

• Keep your Amazon EC2 firewall permissions as restrictive as possible.

  Only open up permissions that you require. Use separate groups to deal with instances that have different security requirements. Consider using additional security measures inside your instance (such as using your own firewall). If you need to log in interactively (ssh), consider creating a bastion security group that allows external login and keep the remainder of your instances in a group that does not allow external login.

The instance types described in the following table are available.

	Note
	The small instance type is the original Amazon EC2 instance type available since the launch of Amazon EC2. It is the default instance type for all customers. To use other instance types, you must specify them through the RunInstances operation.

	Important
	We strongly recommend using the 2.6.18 Xen stock kernel with the c1.medium and c1.xlarge instances. Although the default Amazon EC2 kernels work, the new kernels provide greater stability and performance for these instance types. For more information about kernels, see Kernels, RAM Disks, and Block Device Mappings FAQ.

Every instance includes a fixed amount of storage space on which you can store data. Within this document, it is referred to as the "instance store" as it is not designed to be a permanent storage solution.

If an instance reboots (intentionally or unintentionally), the data on the instance store will survive. If the underlying drive fails or the instance is terminated, the data will be lost.

We highly recommend backing up important data to Amazon S3.

This section describes the differences between standard On-Demand and Reserved Instances.

On-Demand Instance Concepts

On-Demand Instances let you pay for compute capacity by the hour with no long-term commitments. This frees you from the costs and complexities of planning, purchasing, and maintaining hardware and transforms what are commonly large fixed costs into much smaller variable costs.

	Note
	For information about pricing, refer to the Amazon EC2 Product Page.

Reserved Instance Concepts

With Amazon EC2 Reserved Instances, you can make a low one-time payment for each instance to reserve and receive a significant discount on the hourly usage charge for that instance.

Amazon EC2 Reserved Instances are based on instance type and location (region and Availability Zone) for a specified period of time (e.g., 1 year or 3 years) and are only available for Linux/UNIX instances.

Reserved Instance Process

1	Choose a region where you want to run the instance.
2	Search for offerings. To limit the results returned, you can specify the instance type or Availability Zone.
3	Purchase offerings that meet your requiremnts.
4	Run instances of the purchased instance type in the correct region and Availability Zone.

	Note
	For information about pricing, refer to the Amazon EC2 Product Page. For information on using Reserved Instances, see Reserving Amazon EC2 Instances.

How Reserved Instances are Applied

Reserved Instances are applied to instances that meet the type/location criteria during the specified period. In this example, a user is running the following instances:

• (4) m1.small instances in Availability Zone us-east-1a

• (4) c1.medium instances in Availability Zone us-east-1b

• (2) c1.xlarge instances in Availability Zone us-east-1b

The user then purchases the following Reserved Instances.

• (2) m1.small instances in Availability Zone us-east-1a

• (2) c1.medium instances in Availability Zone us-east-1a

• (2) m1.xlarge instances in Availability Zone us-east-1a

Amazon EC2 applies the two m1.small Reserved Instances to two of the instances in Availability Zone us-east-1a. Amazon EC2 doesn't apply the two c1.medium Reserved Instances because the c1.medium instances are in a different Availability Zone and does not apply the m1.xlarge Reserved Instances because there are no running m1.xlarge instances.

This section describes major concepts that you should understand when using Windows instances.

Amazon EC2 Running Windows

As part of this service, Amazon EC2 instances can now run Microsoft Windows Server 2003. Our base Windows image provides you with most of the common functionality associated with Windows. However, if you require more than two concurrent Windows users or need to leverage applications that require LDAP, Kerberos, RADIUS, or other credential services, you must use Windows with Authentication Services. For example, Microsoft Exchange Server and Microsoft SharePoint Server require Windows with Authentication Services.

	Note
	To get started using Windows instances, we recommend using the AWS Management Console. There are differences in pricing between Windows and Windows with Authentication Services instances. For information on pricing, go to the Amazon EC2 Product Page.

Transitioning to a utility computing model changes how developers are trained to think about CPU resources. Instead of purchasing or leasing a particular processor to use for several months or years, you are renting capacity by the hour. Because Amazon EC2 is built on commodity hardware, over time there might be several different types of physical processors underlying different virtual EC2 instances. Our goal is to provide a consistent amount of CPU capacity regardless of the actual underlying hardware.

Amazon EC2 uses a variety of measures to provide each instance with a consistent and predictable amount of CPU capacity. To make it easy for developers to compare CPU capacity between different instance types, we defined an Amazon EC2 Compute Unit.

	Note
	We use several internal benchmarks and tests to manage the consistency and predictability of the performance of an Amazon EC2 Compute Unit. For more information, go to the Instance page.

To find out which instance works best for your application, we recommend launching an instance and using your own benchmark application. This helps you determine which instance type works best for your specific use case.

Amazon EC2 provides virtualized server instances. While some resources like CPU, memory and instance storage are dedicated to a particular instance, other resources like the network and the disk subsystem are shared amongst instances. If each instance on a physical host tries to use as much of one of these shared resources as possible, each receives an equal share of that resource. However, when a resource is under-utilized you are often able to consume a higher share of that resource while it is available.

The different instance types provide higher or lower minimum performance from the shared resources depending on their size. Each of the instance types has an I/O performance indicator (moderate or high). Instance types with high I/O performance have a larger allocation of shared resources. Allocating larger share of shared resources also reduces the variance of I/O performance. For most applications, moderate I/O performance is more than enough. However, for applications that require greater or more consistent I/O performance, consider instances with high I/O performance.