Introduction to Amazon EC2

An Amazon Machine Image (AMI) is a template that contains a software configuration (e.g., operating system, application server, and applications). From an AMI, you launch instances, which are running copies of the AMI. You can launch multiple instances of an AMI, as shown in the following figure.

Your instances keep running until you stop or terminate them, or until they fail. If an instance fails, you can launch a new one from the AMI.

You can use a single AMI or multiple AMIs depending on your needs. From a single AMI, you can launch different types of instances. An instance type is essentially a hardware archetype. As illustrated in the following figure, you select a particular instance type based on the amount of memory and computing power you need for the application or software that you plan to run on the instance. For more information about the available instance types, see Instance Families and Types.

Amazon publishes many AMIs that contain common software configurations for public use. In addition, members of the AWS developer community have published their own custom AMIs. For more information, go to Amazon Machine Images (AMIs).

You might only need to use AMIs that Amazon or other reputable sources provide, and you can simply customize the resulting instances (e.g., run a script) to provide the data or software you need each time you launch an instance. You can also create your own custom AMI or AMIs; then you can run your application by launching one of your custom AMIs.

For example, if your application is a web site or web service, your AMI could be preconfigured with a web server, the associated static content, and the code for all dynamic pages. Alternatively, you could configure your AMI to install all required software components and content itself by running a bootstrap script as soon as the instance starts. As a result, after launching the AMI, your web server will start and your application can begin accepting requests.

For information about AMIs and instances, see Using AMIs and Using Instances.

Amazon has data centers in different areas of the world (e.g., North America, Europe, Asia, etc.). Correspondingly, EC2 is available to use in different Regions. By launching instances in separate Regions, you can design your application to be closer to specific customers or to meet legal or other requirements. Prices for Amazon EC2 usage vary by Region (for more information about pricing by Region, go to the Amazon EC2 Pricing page).

Each Region contains multiple distinct locations called Availability Zones (illustrated in the following diagram). Each Availability Zone is engineered to be isolated from failures in other Availability zones and to provide inexpensive, low-latency network connectivity to other zones in the same Region. By launching instances in separate Availability Zones, you can protect your applications from the failure of a single location.

For more information about the available Regions and Availability Zones, see Using Regions and Availability Zones.

When using EC2, you might have data that you need to store. The two most commonly used storage types are:

Amazon EBS Volumes

Amazon EBS provides your instances with persistent, block-level storage. Amazon EBS volumes are essentially hard disks that you can attach to a running instance.

Volumes are especially suited for applications that require a database, a file system, or access to raw block-level storage.

You can attach multiple volumes to an instance. To keep a back-up copy, you can create a snapshot of the volume. As illustrated in the following figure, snapshots are stored in Amazon S3.

You can create a new Amazon EBS volume from a snapshot, and attach it to another instance, as illustrated in the following figure.

You can also detach a volume from an instance and attach it to a different one, as illustrated in the following figure.

For more information about Amazon EBS volumes, see Amazon Elastic Block Store.

When EC2 was first introduced, all AMIs were backed by Amazon EC2 instance store, which means the root device for an instance launched from the AMI is stored in instance store. After we introduced Amazon EBS, we also introduced AMIs that are backed by Amazon EBS, which means the root device for an instance launched from the AMI is an Amazon EBS volume. The description of an AMI includes which type it is (you'll see the root device referred to in some places as either ebs (for Amazon EBS-backed) or instance store (for Amazon instance store-backed). This is important because there are significant differences in what you can do with each type of AMI. For a discussion of these differences, see Using Amazon EBS-Backed AMIs and Instances.

The application you're running on EC2 might need a database. Following are two common ways to implement a database for your application:

Amazon RDS offers the advantage of handling your database management tasks, such as patching the software, backing up and storing the backups, etc. For more information about Amazon RDS, go to the Amazon RDS product page.

Each instance is launched into the Amazon EC2 network space and assigned a public IP address. Instances can fail or terminate for reasons outside of your control. If one fails and you launch a replacement instance, the replacement will have a different public IP address than the original. However, your application might need a static IP address. Amazon EC2 offers elastic IP addresses for those situations. For more information, see Using Instance IP Addresses.

You use security groups to control who can access your instances. These are analogous to an inbound network firewall that allows you to specify the protocols, ports, and source IP ranges that are allowed to reach your instances. You can create multiple security groups and assign different rules to each group. You can then assign each instance to one or more security groups, and we use the rules to determine which traffic is allowed in to the instance. You can configure a security group so that only specific IP addresses or specific security groups have access to the instance.

The following figure shows a basic three-tier web-hosting architecture running on Amazon EC2 instances. Each layer has a different security group (indicated by the dotted line around each set of instances). The security group for the web servers only allows access from hosts over TCP on ports 80 and 443 (HTTP and HTTPS) and from instances in the App Servers security group on port 22 (SSH) for direct host management.

The security group for the app servers allows access from the Web Servers security group for web requests, and from your corporate subnet over TCP on port 22 (SSH) for direct host management. Your support engineers could log directly into the application servers from the corporate network, and then access the other instances from the application server boxes.

The DB Servers security group permits only the App Servers security group to access the database servers.

For more information about security groups, see Using Security Groups.

AWS provides several features that enable you to do the following:

Amazon EC2 integrates with AWS Identity and Access Management (IAM), a service that lets your organization do the following:

For example, you can use IAM with Amazon EC2 to control which users under your AWS account can create AMIs or launch instances.

For general information about IAM, go to:

For specific information about how you can control User access to Amazon EC2, go to Integrating with Other AWS Products in Using AWS Identity and Access Management.

The AWS Management Console is a simple web-based GUI (see the following screenshot). For more information about using the console, go to the Amazon Elastic Compute Cloud Getting Started Guide.

EC2 provides a Java-based command-line client that wraps the EC2 SOAP API. For more information, see Getting Started with the Command Line Tools.

The following table lists how you can access EC2 programmatically.

If you haven't walked through the Amazon Elastic Compute Cloud Getting Started Guide, we recommend you do that next. In that guide, you'll do a quick hands-on exercise where you launch an instance and connect to it.

You need to understand the key differences between running your application on infrastructure in the cloud versus on servers in your own data center. For more information, go to the technical whitepaper: Architecting for the Cloud: Best Practices.

It's important for you to design your application to handle the failure of a cloud infrastructure component. For example, EC2 instances will eventually fail; it's just a matter of when. An instance failure isn't a problem if your application is prepared for it. For more information, go to the technical whitepaper: Building Fault-Tolerant Applications on AWS.

For a complete list of the AWS whitepapers, go to the AWS Cloud Computing Whitepapers page.

The next section in this guide (Using Amazon EC2) describes in more detail the technical aspects of the infrastructure components that were briefly described in the preceding sections. We recommend you understand how these components work before designing your application or service to run on EC2.