Find more answers in Amazon EC2 Technical FAQs
Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.
Just as Amazon Simple Storage Service (Amazon S3) enables storage in the cloud, Amazon EC2 enables “compute” in the cloud. Amazon EC2’s simple web service interface allows you to obtain and configure capacity with minimal friction. It provides you with complete control of your computing resources and lets you run on Amazon’s proven computing environment. Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change. Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use.
To sign up for Amazon EC2, click the “Sign up for This Web Service” button on the Amazon EC2 detail page. You must have an Amazon Web Services account to access this service; if you do not already have one, you will be prompted to create one when you begin the Amazon EC2 sign-up process. After signing up, please refer to the Amazon EC2 documentation, which includes our Getting Started Guide.
Until now, small developers did not have the capital to acquire massive compute resources and insure they had the capacity they needed to handle unexpected spikes in load. Amazon EC2 enables any developer to leverage Amazon’s own benefits of massive scale with no up-front investment or performance compromises. Developers are now free to innovate knowing that no matter how successful their businesses become, it will be inexpensive and simple to ensure they have the compute capacity they need to meet their business requirements.
The “Elastic” nature of the service allows developers to instantly scale to meet spikes in traffic or demand. When computing requirements unexpectedly change (up or down), Amazon EC2 can instantly respond, meaning that developers have the ability to control how many resources are in use at any given point in time. In contrast, traditional hosting services generally provide a fixed number of resources for a fixed amount of time, meaning that users have a limited ability to easily respond when their usage is rapidly changing, unpredictable, or is known to experience large peaks at various intervals.
Once you have set up your account and select or create your AMIs, you are ready to boot your instance. You can start your AMI on any number of On-Demand Instances by calling the RunInstances API. You simply need to state how many instances you wish to start. If you wish to run more than 20 On-Demand Instances, complete the Amazon EC2 instance request form.
If Amazon EC2 is able to fulfill your request, RunInstances will return success, and we will start setting up your instances. You can check on the status of your instances using the DescribeInstances API call. You can also programmatically terminate any number of your instances using the TerminateInstances API call.
If you have a running instance using an Amazon EBS boot partition, you can also call the StopInstances API to release the compute resources but preserve the data on the boot partition. You can call the StartInstances API when you are ready to restart the associated instance with the Amazon EBS boot partition.
In addition, you have the option to use Spot Instances to reduce your computing costs when you have flexibility in when your applications can run. Read more about Spot Instances for a more detailed explanation on how Spot Instances work.
If you prefer, you can also perform all these actions from the AWS Management Console or through the command line using our command line tools, which have been implemented with this web service API.
When you launch your Amazon EC2 instances you have the ability to store your root device data on Amazon EBS or the local instance store. By using Amazon EBS, data on the root device will persist independently from the lifetime of the instance. This enables you to stop and restart the instance at a subsequent time, which similar to shutting down your laptop and restarting it when you need it again.
Alternatively, the local instance store only persists during the life of the instance. This is an inexpensive way to launch instances where data is not stored to the root device. For example, some customers use this option to run large web sites where each instance is a clone to handle web traffic.
It typically takes less than 10 minutes from the issue of the RunInstances call to the point where all requested instances begin their boot sequences. This time is dependant on a number of factors including: the size of your AMI, the number of instances you are launching, and how recently you have launched that AMI. Images launched for the first time may take slightly longer to boot.
Amazon EC2 allows you to set up and configure everything about your instances from your operating system up to your applications. An Amazon Machine Image (AMI) is simply a packaged-up environment that includes all the necessary bits to set up and boot your instance. Your AMIs are your unit of deployment. You might have just one AMI or you might compose your system out of several building block AMIs (e.g., webservers, appservers, and databases). Amazon EC2 provides a number of tools to make creating an AMI easy. Once you create a custom AMI, you will need to bundle it. If you are bundling an image with a root device backed by Amazon EBS, you can simply use the bundle command in the AWS Management Console. If you are bundling an image with a boot partition on the instance store, then you will need to use the AMI Tools to upload it to Amazon S3. Amazon EC2 uses Amazon EBS and Amazon S3 to provide reliable, scalable storage of your AMIs so that we can boot them when you ask us to do so.
Or, if you want, you don’t have to set up your own AMI from scratch. You can choose from a number of globally available AMIs that provide useful instances. For example, if you just want a simple Linux server, you can choose one of the standard Linux distribution AMIs.
The RunInstances call that initiates execution of your application stack will return a set of DNS names, one for each system that is being booted. This name can be used to access the system exactly as you would if it were in your own data center. You own that machine while your operating system stack is executing on it.
Yes, Amazon EC2 is used jointly with Amazon Simple Storage Service (Amazon S3) for instances with root devices backed by local instance storage. By using Amazon S3, developers have access to the same highly scalable, reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of web sites. In order to execute systems in the Amazon EC2 environment, developers use the tools provided to load their Amazon Machine Images (AMIs) into Amazon S3 and to move them between Amazon S3 and Amazon EC2. See "How do I load and store my systems with Amazon EC2?" for more information about AMIs.
We expect developers to find the combination of Amazon EC2 and Amazon S3 to be very useful. Amazon EC2 provides cheap, scalable compute in the cloud while Amazon S3 allows users to store their data reliably.
Amazon EC2 provides a truly elastic computing environment. Amazon EC2 enables you to increase or decrease capacity within minutes, not hours or days. You can commission one, hundreds or even thousands of server instances simultaneously. When you need more instances, you simply call RunInstances, and Amazon EC2 will typically set up your new instances in a matter of minutes. Of course, because this is all controlled with web service APIs, your application can automatically scale itself up and down depending on its needs.
Amazon EC2 currently supports a variety of operating systems including: RedHat Linux, Windows Server, openSuSE Linux, Fedora, Debian, OpenSolaris, Cent OS, Gentoo Linux, and Oracle Linux. We are looking for ways to expand it to other platforms in future releases.
Traditional hosting services generally provide a pre-configured resource for a fixed amount of time and at a predetermined cost. Amazon EC2 differs fundamentally in the flexibility, control and significant cost savings it offers developers, allowing them to treat Amazon EC2 as their own personal data center with the benefit of Amazon.com’s robust infrastructure.
When computing requirements unexpectedly change (up or down), Amazon EC2 can instantly respond, meaning that developers have the ability to control how many resources are in use at any given point in time. In contrast, traditional hosting services generally provide a fixed number of resources for a fixed amount of time, meaning that users have a limited ability to easily respond when their usage is rapidly changing, unpredictable, or is known to experience large peaks at various intervals.
Secondly, many hosting services don’t provide full control over the compute resources being provided. Using Amazon EC2, developers can choose not only to initiate or shut down instances at any time, they can completely customize the configuration of their instances to suit their needs – and change it at any time. Most hosting services cater more towards groups of users with similar system requirements, and so offer limited ability to change these.
Finally, with Amazon EC2, developers enjoy the benefit of paying only for their actual resource consumption – and at very low rates. Most hosting services require users to pay a fixed, up-front fee irrespective of their actual computing power used, and so users risk overbuying resources to compensate for the inability to quickly scale up resources within a short time frame.
Billing commences when Amazon EC2 initiates the boot sequence of an AMI instance. Billing ends when the instance terminates, which could occur through a web services command, by running “shutdown -h”, or through instance failure.
Each instance is charged for its data in and data out. Therefore, if data is transferred between these two instances, it is charged out for the first instance and in for the second instance.
Your application will execute on a virtual computer that we call an instance. You have the choice of several instance types, allowing you to select a configuration of memory, CPU, and instance storage that is optimal for your application:
Standard InstancesInstances of this family are well suited for most applications.
Small Instance (Default)Large Instance1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of local instance storage, 32-bit platform
Extra Large Instance7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform
High-Memory Instances
Instances of this family offer large memory sizes for high throughput applications, including database and memory caching applications.
High-Memory Double Extra Large InstanceHigh-Memory Quadruple Extra Large Instance34.2 GB of memory, 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform
High-CPU Instances
Instances of this family have proportionally more CPU resources than memory (RAM) and are well suited for compute-intensive applications.
High-CPU Medium InstanceHigh-CPU Extra Large Instance1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of local instance storage, 32-bit platform
7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform
Cluster Compute Instances
Instances of this family provide proportionally high CPU with increased networking performance and are well suited for High Performance Compute (HPC) applications and other demanding network-bound applications. Learn more about use of this instance type for HPC applications.
Cluster Compute Quadruple Extra Large Instance23 GB of memory, 33.5 EC2 Compute Units, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet
See Amazon EC2 Instance Types for details on available configurations. You have full and exclusive access to an instance once you have commissioned it.
Amazon EC2 instances are grouped into four families: Standard, High-Memory, High-CPU, and Cluster Compute. Standard Instances have memory to CPU ratios suitable for most general purpose applications; High-Memory instances offer larger memory sizes for high throughput applications, including database and memory caching applications; and High-CPU instances have proportionally more CPU resources than memory (RAM) and are well suited for compute-intensive applications. Cluster Compute instances provide a very large amount of CPU coupled with a high performance network making them well suited for High Performance Compute (HPC) applications and other demanding network-bound applications. When choosing instance types, you should consider the characteristics of your application with regards to resource utilization and select the optimal instance family and size.
For most applications, the standard instance types are appropriate. These include the Small Instance (m1.small), Large Instance (m1.large), and Extra Large Instance (m1.xlarge). For high throughput applications, such as database and memory caching applications, the High-Memory instances are well suited. These are the High-Memory Double Extra Large Instance (m2.2xlarge) and the High-Memory Quadruple Extra Large Instance (m2.4xlarge). For compute-intensive applications such as rendering, search indexing, and computational analysis, the High-CPU Instances are well suited. The High-CPU instance types are the High-CPU Medium Instance (c1.medium) and the High-CPU Extra Large Instance (c1.xlarge). For HPC and other network-bound applications such as computational biology and chemistry, engineering design and simulation, and financial analytics, the Cluster Compute Quadruple Extra Large Instance (cc1.4xlarge) is well suited. For details, please see Amazon EC2 Instance Types.
One of the advantages of 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. One good way to determine the most appropriate instance family and instance type is to launch test instances and benchmark your application.
Transitioning to a utility computing model fundamentally changes how developers have been 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 may be several different types of physical hardware underlying EC2 instances. Our goal is to provide a consistent amount of CPU capacity no matter what the actual underlying hardware.
Amazon EC2 uses a variety of measures to provide each instance with a consistent and predictable amount of CPU capacity. In order to make it easy for developers to compare CPU capacity between different instance types, we have defined an Amazon EC2 Compute Unit. The amount of CPU that is allocated to a particular instance is expressed in terms of these EC2 Compute Units. We use several benchmarks and tests to manage the consistency and predictability of the performance from an EC2 Compute Unit. One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor. This is also the equivalent to an early-2006 1.7 GHz Xeon processor referenced in our original documentation. Over time, we may add or substitute measures that go into the definition of an EC2 Compute Unit, if we find metrics that will give you a clearer picture of compute capacity.
See Amazon EC2 Instance Types for additional details.
You have complete control over the visibility of your systems. The Amazon EC2 security systems allow you to place your running instances into arbitrary groups of your choice. Using the web services interface, you can then specify which groups may communicate with which other groups, and also which IP subnets on the Internet may talk to which groups. This allows you to control access to your instances in our highly dynamic environment. Of course, you should also secure your instance as you would any other Linux host.
For more information on security on AWS please refer to our Amazon Web Services: Overview of Security Processes document and to our Amazon EC2 running Windows Security Guide.
Public (IPV4) internet addresses are a scarce resource. There is only a limited amount of public IP space available, and Amazon EC2 is committed to helping use that space efficiently.
By default, all accounts are limited to 5 Elastic IP addresses per region. If you need more the 5 Elastic IP addresses, we ask that you apply for your limit to be raised. We will ask you to think through your use case and help us understand your need for additional addresses. You can apply for more Elastic IP address here. Any increases will be specific to the region they have been requested for.
In order to help ensure our customers are efficiently using the Elastic IP addresses, we impose the $.01/hr charge for each address when it is not mapped to an instance.
No. You do not need an Elastic IP address for all your instances. By default, every instance comes with a private IP address and an internet routable public IP address. These addresses are fixed for the life of the instance. These IP addresses should be adequate for many applications where you do not need a long lived internet routable end point. Compute clusters, web crawling, and backend services are all examples of applications that typically do not require Elastic IP addresses.
The remap process currently takes several minutes from when you instruct us to remap the Elastic IP until it fully propagates through our system.
Yes, you can configure the reverse DNS record of your Elastic IP address by filling out this form. Note that a corresponding forward DNS record pointing to that Elastic IP address must exist before we can create the reverse DNS record.
Each availability zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados or flooding would only affect a single Availability Zone.
Yes, EC2 is running in four regions, each of which has multiple Availability Zones. The regions are US East (Northern Virginia), US West (Northern California), EU (Ireland), and Asia Pacific (Singapore).
We do not currently support the ability to coordinate launches into the same Availability Zone across AWS developer accounts.
No. Regional Data Transfer rates apply if at least one of the following is true, but is only charged once for a given instance even if both are true:
The data stored on a local instance store will persist only as long as that instance is alive. However, data that is stored on an Amazon EBS volume will persist independently of the life of the instance.
Therefore, we recommend that you should use the local instance store for temporary data and if you want to increase your data durability we recommend using Amazon EBS volumes or backing up the data to Amazon S3.
The latency from an Amazon EC2 instance to an Amazon EBS volume is similar to the latency you would see from the local Amazon EC2 instance storage drive. I/O rates can vary significantly based on the size of the requests, the randomness of the access patterns, and the caching strategy used by the application. As such, the most accurate measure is to benchmark your specific application on an Amazon EBS volume.
While you are able to attach multiple volumes to a single instance, attaching multiple instances to one volume is not supported at this time.
No, snapshots are only available through the Amazon EC2 APIs.
No, snapshots can be done in real time while the volume is attached and in use. However, snapshots only capture data that has been written to your Amazon EBS volume, which might exclude any data that has been locally cached by your application or OS. In order to ensure consistent snapshots on volumes attached to an instance, we recommend cleanly detaching the volume, issuing the snapshot command, and then reattaching the volume. For Amazon EBS volumes that serve as root devices, we recommend shutting down the machine to take a clean snapshot.
Each snapshot is given a unique identifier, and customers can create volumes based on any of their existing snapshots.
No. If encryption is important to you, we recommend that you run an encrypted file system on top of your Amazon EBS volume.
Spot Instances can be requested using the AWS Management Console or Amazon EC2 APIs. To start with the AWS Management Console:
For detail on how to request Spot Instances through the Amazon EC2 API, see the Amazon EC2 API Reference.
For a more detailed walk through of using Spot Instances and more information on how to get the most out of Spot Instances, please read Introduction to Spot Instances.
You can request as few as 1 or as many as 100 Spot Instances via the Amazon EC2 Management Console or API. If you need to request more than 100 Spot Instances, you can request to have your limit raised by completing the Amazon EC2 instance request form.
Yes.
Linux/Unix and Windows Server are available. Windows Server with SQL Server is not currently available.
The following features are not yet supported for use with Spot Instances: Auto Scaling, Amazon Virtual Private Cloud, Amazon Elastic MapReduce, and Amazon DevPay.
Not at this time.
No. If the Spot Instance is terminated by Amazon EC2, you will not be charged for a partial hour of usage. However, if you terminate the instance yourself, you will be charged for any hour in which the instance ran.
Amazon EC2 will change the Spot Price periodically as new requests are received and as available Spot capacity changes (e.g. due to instance terminations). While the Spot Price may change anytime, in general the Spot Price will change once per hour and in many cases less frequently. We publish the current Spot Price and historical prices for Spot Instances through the API, which can also be viewed using the AWS Management Console; these can help you assess the levels and timing of fluctuations in the Spot Price over time.
Yes.
No. The price per instance-hour for a Spot Instance is set at the beginning of each instance-hour for the entire hour. Any changes to the Spot Price will not be reflected until the next instance-hour begins.
The AWS portal makes a detailed billing report available which shows Spot instance start and termination times for all instances. Customers can check the billing report against historical Spot prices via the API to verify the Spot Price they were billed is correct.
New Amazon EC2 cluster placement group functionality allows users to group Cluster Compute Instances in clusters – allowing applications to get the low-latency network performance necessary for tightly-coupled node-to-node communication typical of many HPC applications. Cluster Compute Instances also provide significantly increased network throughput both within the Amazon EC2 environment and to the Internet. As a result, these instances also well suited for customer applications that need to perform network-intensive operations.
Learn more about use of this instance type for HPC applications.
First, Cluster Compute instances use Hardware Virtual Machine (HVM) based virtualization and run only Amazon Machine Images (AMIs) based on HVM virtualization. Paravirtual Machine (PVM) based AMIs used with other Amazon EC2 instance types cannot be used with Cluster Compute Instances.
Second, Cluster Compute Instances require booting from an EBS-backed AMI.
Third, in order to fully benefit from the available low latency, full bisection bandwidth between instances, Cluster Compute Instances must be launched into a cluster placement group through the Amazon EC2 API or AWS Management Console.