Start tracking your progress
Trailhead Home
Trailhead Home

Select Amazon EC2 Instance Configurations

Learning Objectives

After completing this unit, you’ll be able to:

  • Differentiate between AWS instance types.
  • Understand the components of an EC2 instance.
  • Differentiate between Amazon EC2 Instance Store and Amazon Elastic Block Storage (EBS) volumes.
  • Choose EC2 instance placement based on networking and proximity considerations.

Now that you know how to select an operating system for your EC2 instance, it’s time to choose other configurations to create your EC2 instance, such as the instance type, network, and storage.

For a frontend application like your cat photo app, you need instances with enough capacity to run web servers and process incoming customer requests. Your instance sizing will depend on both the demands of your application and the anticipated size of your user base.

Forecasting server capacity for an on-premises application requires difficult decisions involving significant up-front capital spending, while changes to the allocation of your cloud-based services can be made with a simple API call. Because of AWS’s pay-as-you-go model, you can match your infrastructure capacity to your application’s demand, instead of the other way around.

What Makes Up an EC2 Instance?

EC2 instances are a combination of virtual processors (vCPUs), memory, network, and in some cases, instance storage and graphics processing units (GPUs). When you create an instance for your cat photo application, you need to choose how much you need of each of these components.

Screenshot of several instances with their performance specifications. The column headers are highlighted by a red box, showing vCPU, memory, instance storage, network bandwidth, and EBS bandwidth.

AWS offers a variety of instances that differ based on performance. Some instances provide you with more capacity and others provide less. To get an overview of the capacity details for a particular instance, you should look at the instance type.  

Instance types consist of a prefix identifying the type of workloads they’re optimized for, followed by a size. For example, the instance type c5.large can be broken down into the following elements.

  • c5 determines the instance family and generation number. Here, the instance belongs to the fifth generation of instances in an instance family that’s optimized for generic computation.
  • large, which determines the amount of instance capacity.

A c5.large instance type, showing the division of the instance family and instance size.

What Are Instance Families?

In the example c5.large, the first letter, c, stands for compute-optimized. Compute optimized instances are just one of the many instance families that AWS offers. Each instance family is optimized to fit different use cases. Use the following table to help you choose the instance family that best fits your workload. 

Instance Family Description Use Cases

General purpose

Provides a balance of compute, memory, and networking resources, and can be used for a variety of workloads.

Scale-out workloads such as web servers, containerized microservices, caching fleets, distributed data stores, and development environments.

Compute optimized

Ideal for compute-bound applications that benefit from high-performance processors.


High-performance web servers, scientific modeling, batch processing, distributed analytics, high-performance computing (HPC), machine/deep learning, ad serving, highly scalable multiplayer gaming.

Memory optimized

Designed to deliver fast performance for workloads that process large data sets in memory.

Memory-intensive applications such as high-performance databases, distributed web-scale in-memory caches, mid-size in-memory databases, real-time big-data analytics, and other enterprise applications.


Accelerated computing

Use hardware accelerators or co-processors to perform functions such as floating-point number calculations, graphics processing, or data pattern matching more efficiently than is possible with conventional CPUs.

3D visualizations, graphics-intensive remote workstations, 3D rendering, application streaming, video encoding, and other server-side graphics workloads.

Storage optimized

Designed for workloads that require high, sequential read and write access to large data sets on local storage. They are optimized to deliver tens of thousands of low-latency random I/O operations per second (IOPS) to applications that replicate their data across different instances.

NoSQL databases, such as Cassandra, MongoDB, and Redis, in-memory databases, scale-out transactional databases, data warehousing, Elasticsearch, and analytics.

Where Does Your EC2 Instance Live?

By default, your EC2 instances are placed in a network called the default Amazon Virtual Private Cloud (VPC). This network was created so that you can easily get started with Amazon EC2 without having to learn how to create and configure a VPC. Any resource you put inside the default VPC will be public and accessible by the internet, so you shouldn’t place any customer data or secret cat photos inside of it. 

Once you get more comfortable with networking on AWS, you can change this default setting to choose your own custom VPCs and restrict access with additional routing and connectivity mechanisms.

Architect for High Availability

Inside this network, your instance resides in an Availability Zone of your choice. As you learned in AWS Cloud, AWS services that are scoped at the Availability Zone level must be architected with high availability in mind. 

While EC2 instances are typically reliable, two is better than one, and three is better than two. Specifying the instance size gives you an advantage when designing your architecture because you can use more smaller instances instead of a few larger ones.

If your frontend only has a single instance and that instance fails, your application goes down. On the other hand, if your workload is distributed across 10 instances and one fails, you lose only 10 percent of your fleet and your application availability is hardly affected.

When architecting your cat photo application for high availability, consider using at least two EC2 instances in two separate Availability Zones. ­­

Two EC2 instances within two different Availability Zones in a single region.

Where Do You Store Your Files?

When you choose an AMI, you select what kind of storage is used for the root device of an instance. As you learned in the previous unit, the root device contains the image used to boot the instance. Every AMI is categorized as either backed by Amazon Elastic Block Store (EBS) or backed by instance store.

Persist Storage with Amazon EBS Volumes

When you choose an EBS-backed AMI, AWS gives you an EBS volume to be used as the root device when you launch a new instance. 

EBS is an AWS Service that provides block storage designed for use with Amazon EC2. In other words, it’s a storage layer that is allocated with the size and specs of your choice that can be attached to the EC2 instance of your choice.

The billing and lifecycle of your EBS volumes are independent of the EC2 instance they’re attached to. This makes it possible to shut down an instance without losing its data. This can be especially handy for reducing costs when a particular compute instance is not in use.

EBS volumes are created within an Availability Zone of your choice. For latency reasons, you can only attach EBS volumes to instances in the same AZ. This is commonly called shared-nothing architecture because nodes do not share any memory or storage. This eliminates single points of failure. Shared-nothing architecture is popular for web applications like your cat photo application.

Two EC2 instances and three EBS volumes each, inside two Availability Zones, showing that EC2 instances and EBS volumes are scoped at the Availability Zone level

Use Amazon EC2 Instance Store for Ephemeral Storage

When you choose an AMI that is backed by instance store, it means the underlying physical server has at least one storage unit directly attached to it. The main advantage of instance store is that it’s directly attached to the physical server, which provides you more speed and throughput than EBS volumes. 

Instance store is different from EBS volumes in two ways.

  • Instance store is included in the hourly price of an EC2 instance.
  • Instance store is ephemeral. If you stop or terminate an instance, all data in instance store can no longer be used or accessed.

Instance store is ideal if you are hosting applications that replicate data to other EC2 instances, such as Elasticsearch domains, Hadoop clusters, and data architectures that perform data replication. For these cluster-based workloads, having the speed of locally attached volumes and the resiliency of replicated data helps you achieve data distribution at high performance.

The diagram below illustrates that the same host computer that provides your instance (1) are in the same physical location as your instance store, shown here as ephemeral (2).

Two host computers containing several instances and ephemeral storage volumes. A 1 is next to Instances A and B. A 2 is next to these instances's ephemeral storage.

Wrap Up

In this unit, you learned the configurations needed to create an EC2 instance, such as selecting an instance type, network, and storage type for your workload. In the next unit, you learn how to turn the EC2 instance hosting your cat photo application on and off, how it affects your pricing, and ways to drive the cost of EC2 down. 

Resources