AMI and Instance Concepts

From Amazon Elastic Compute Cloud: 2009-10-31

previous page next page

AMI and Instance Concepts

This section describes AMIs and instances, the basic building blocks of Amazon EC2. Before accomplishing anything with Amazon EC2, you must understand the concepts in this section.

An Amazon Machine Image (AMI) is an encrypted machine image that contains all information necessary to boot instances of your software. For example, an AMI might contain all the software to act as a web server (e.g., Linux, Apache, and your web site) or it might contain all the software to act as a Hadoop node (e.g., Linux, Hadoop, and a custom application).

You launch one or more instances of an AMI. An instance might be one web server within a web server cluster or one Hadoop node.

AMIs

An Amazon EC2 instance can be launched from an AMI backed by Amazon S3 or an AMI backed by Amazon EBS. Instances launched from AMIs backed by Amazon S3 use an instance store as the root device (e.g., / or C:\). Instances launched from AMIs backed by Amazon EBS use Amazon EBS volumes as their root devices.

The following table describes the differences between AMIs backed by Amazon S3 and AMIs backed by Amazon EBS.

Root Device	Instance Store	Amazon EBS
Boot Time	Usually Less than 5 minutes	Usually Less than 1 minute
Size Limit	10 GiB	1 TiB
Location	Instance storage	Amazon EBS volume
Data Persistence	Data persists for the life of the instance; non-root devices can use Amazon EBS	Data persists on instance failure and can persist on instance termination
Upgrading	Instance attributes are fixed for the life of an instance	The kernel, instance type, and ramdisk can be changed while the instance is stopped.
Charges	Instance usage and AMI storage	Instance usage, Amazon EBS volume usage, and AMI Storage
AMI Creation	Requires installation and use of AMI tools	Uses a single command/call
Stopped State	Cannot be in stopped state; instances are running or not	Can be placed in stopped state where instance is not running, but state is maintained in Amazon EBS

Public AMIs are available from Amazon and the Amazon EC2 community and can be downloaded from the Resource Center. You can use public AMIs as a base to create your own custom private AMIs.

Private AMIs are AMIs that you own and can only be accessed by you or those to whom you grant access.

Shared AMIs are AMIs that developers build and make available for other AWS developers to use. Building safe, secure, useable AMIs for public consumption is a fairly straightforward process, if you follow a few simple guidelines. For information on how to use shared AMIs and how to share AMIs, see Using Shared AMIs and How to Share AMIs.

Paid AMIs are AMIs that you purchase from developers or AMIs that come with service contracts from organization such as Red Hat.

Preparing and Creating an AMI

To use a file system image with Amazon EC2, you must prepare and create it as an AMI.

An Amazon EC2 instances can use its instance store (Amazon S3-backed) as its root device or an Amazon EBS volume (Amazon EBS-backed).

The creation process for an AMI that uses an instance store as its root device does the following:

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

	Important
	After completion, you must register the AMI.

The creation process for an AMI that uses an Amazon EBS volume as its root device uses one of the following methods:

Creates snapshots for all attached Amazon EBS volumes and creates an AMI using a single command/call
Creates an AMI from a snapshot

Instances

After an AMI is launched, the resulting running system is called an instance. By default, you can run up to 20 instances. If you need more than 20 instances, please complete the Amazon EC2 Instance Request Form and your request will be considered.

Instances remain running unless they fail or are terminated. When this happens, the data on the instance is no longer available. However, if an instance fails that uses an Amazon EBS volume as its root device, the data remains available.

	Note
	Instances that use Amazon EBS volumes as their root devices can delete their volumes on termination or leave them running. If an instance fails that uses an Amazon EBS volume as its root device, the volume continues running and can be mounted by another instance.

Instance Usage

The instance is your basic computation building block. Amazon EC2 offers multiple instance types from which you can choose. You can run as many or as few instances as you need at any given time.

For information about available instance types, see Instance Types.

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.

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.

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 or use Amazon EBS.
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.

For more information, go to Amazon CloudWatch Product Page.
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.

Instance Types

Amazon EC2 instances are grouped into three families: standard, High-CPU, and High-Memory. Standard instances have memory to CPU ratios suitable for most general purpose applications; High-CPU instances have proportionally more CPU resources than memory (RAM) and are well suited for compute-intensive applications. High-Memory instances have proportionally more memory resources and are well suited for high throughput applications, such as database and memory caching applications.

When selecting instance types, you might want to use less powerful instance types for your web server instances and more powerful instance types for your database instances.

	Tip
	One of the advantages of Amazon EC2 is that you pay by the instance hour, which makes it convenient and inexpensive to test the performance of your application on different instance families and types. A good way to determine the most appropriate instance family and instance type is to launch test instances and benchmark your application.

Available Instance Types

The instance types described in the following table are available.

Type	CPU	Memory	Storage	Platform	I/O	Name
Small	1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)	1.7 GB	160 GB instance storage (150 GB plus 10 GB root partition)	32-bit	Moderate	m1.small
Large	4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)	7.5 GB	850 GB instance storage (2 x 420 GB plus 10 GB root partition)	64-bit	High	m1.large
Extra Large	8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)	15 GB	1690 GB instance storage (4 x 420 GB plus 10 GB root partition)	64-bit	High	m1.xlarge
High-CPU Medium	5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each)	1.7 GB	350 GB instance storage (340 GB plus 10 GB root partition)	32-bit	Moderate	c1.medium
High-CPU Extra Large	20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each)	7 GB	1,690 GB instance storage (4 x 420 GB plus 10 GB root partition)	64-bit	High	c1.xlarge
High-Memory Double Extra Large	13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each)	34.2 GB	850 GB instance storage (1 x 840 GB plus 10 GB root partition)	64-bit	High	m2.2xlarge
High-Memory Quadruple Extra Large	26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)	68.4 GB	1690 GB instance storage (2 x 840 GB plus 10 GB root partition)	64-bit	High	m2.4xlarge

	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 High-CPU and High-Memory 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.

Instance Storage

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, the instance is terminated, or the instance is stopped, the data is lost.

If you need a permanent storage solution, we recommend using Amazon EBS. For more information, see Amazon Elastic Block Store.

	Note
	If you do not use Amazon EBS, make sure to back up important data to Amazon S3.

Storage Locations

Storage is exposed on the instance types as described in the following table.

Location	Description
/dev/sda1	Formatted and mounted as root (/) on all Linux and UNIX instance types. Formatted and mounted as C:\ on all Windows instance types.
/dev/sda2 or xvdb (Windows)	Formatted and mounted as /mnt on m1.small and c1.medium instances. Formatted and mounted on small Windows instance types.
/dev/sda3	Formatted and mounted as /swap on m1.small and c1.medium instances on all Linux and UNIX instance types. Not available on Windows instances.
/dev/sdb or xvdb (Windows)	Formatted and mounted as /mnt on m1.large, m1.xlarge, and c1.xlarge Linux and UNIX instances. Formatted and mounted on m1.large, m1.xlarge, and c1.xlarge Windows instances.
/dev/sdc or xvdc (Windows)	Available on m1.large, m1.xlarge, and c1.xlarge Linux and UNIX instances. Formatted and mounted on m1.large, m1.xlarge, and c1.xlarge Windows instances.
/dev/sdd or xvdd (Windows)	Available on m1.xlarge and c1.xlarge Linux and UNIX instances. Formatted and mounted on m1.xlarge and c1.xlarge Windows instances.
/dev/sde or xvde (Windows)	Available on m1.xlarge and c1.xlarge Linux and UNIX instances. Formatted and mounted on m1.xlarge and c1.xlarge Windows instances.

	Note
	By default, instance stores are not exposed to Amazon EBS-backed instances. However, they are still available.

On-Demand and Reserved Instances

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 requirements.
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.

Windows Instance Types

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

Differences Between Windows and Linux/UNIX Instances

Using Amazon EC2 instances running Windows is similar to using instances running Linux and UNIX. The following are the major differences between instances that use Linux/UNIX and Windows:

Remote Desktop—To access Windows instances, you use Remote Desktop instead of SSH.
Administrative Password—To access Windows instances the first time, you must obtain the administrative password using the ec2-get-password command.
Bundling—Windows instances use different bundling procedures. For more information, see Preparing and Creating AMIs.

Amazon EC2 Running Windows

As part of this service, Amazon EC2 instances can now run Microsoft Windows Server 2003 or Microsoft Windows Server 2008. The Windows AMIs provide you with all standard Microsoft Windows Server functionality.

	Note
	To get started using Windows instances, we recommend using the AWS Management Console.

Windows AMI

Amazon EC2 currently provides the following Windows AMIs:

Microsoft Windows Server 2003 (32-bit)
Microsoft Windows Server 2003 (64-bit)
Microsoft Windows Server 2008 (32-bit)
Microsoft Windows Server 2008 (64-bit)

The Windows public AMIs that Amazon provides are unmodified versions of Windows with the following two exceptions: we added drivers to improve the networking and disk I/O performance and we created the Amazon EC2 configuration service. The Amazon EC2 configuration service performs the following functions:

Randomly sets the Administrator password on initial launch, encrypts the password with the user’s SSH key, and reports it to the console. This operation happens upon initial AMI launch. If you change the password, AMIs that are created from this instance use the new password.
Configures the computer name to the internal DNS name. To determine the internal DNS name, see Using Instance Addressing.
Sends the last three system and application errors from the event log to the console. This helps developers to identify problems that caused an instance to crash or network connectivity to be lost.

Measuring Compute Resources

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.

I/O Resources

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.

previous page start next page

AMI and Instance Concepts