Amazon EC2 Instance Types

When working with Amazon EC2, selecting what might seem like a simple instance can quickly become confusing. Many candidates find themselves repeatedly checking documentation to understand differences such as instance families versus sizes, generations versus CPU architectures, or whether storage is provided through local NVMe drives or Amazon EBS volumes. This confusion usually occurs when these concepts are encountered without a clear structure.

This lesson introduces a structured mental model to:

• Understand what Amazon EC2 instance types are and what is meant by a simple instance type, establishing the core concept needed to reason about instance selection.

• Learn the primary EC2 instance categories and how they are designed to support different workload types such as compute-optimized, memory-optimized, and general-purpose applications.

• Decode how EC2 instance names are structured so we can quickly interpret generation, family, and size when reading or selecting instance types.

• Explore the core platform concepts behind EC2, including the Nitro and Xen virtualization platforms and how root volumes behave during instance lifecycle events.

• Build a clear mental model of EC2 instance types that will help us confidently choose the right compute resources for different workloads, an essential skill when designing scalable, reliable, and cost-efficient architectures.

What are EC2 instance types?

EC2 instance types are predefined combinations of compute, memory, storage, and networking capacity that AWS exposes as virtual servers. When we launch an instance, the instance type determines the hardware characteristics made available to that instance, including CPU, memory, and (where applicable) instance storage and network performance.

Behind the scenes, AWS physical hosts provide CPU, memory, networking, and storage resources. Some resources of the host computer, such as CPU and memory, are dedicated to a particular instance. Other resources, such as the network and the disk subsystem, are shared among instances. If each instance on a host computer 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 underused, an instance can consume a higher share of that resource while it's available.

Because of this, two instance types may appear similar (for example, having comparable vCPU and memory) but still behave differently under load. Differences in network throughput, disk I/O characteristics, and hardware generation can lead to variations in performance. Instance families are one of the main signals that indicate these performance characteristics.

Instance types provide higher or lower minimum performance from shared resources. For example, instance types with high I/O performance have a larger allocation of shared resources. Allocating a 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 an instance type with higher I/O performance.

To make instance types easier to reason about, a few core terms appear frequently:

Categories of EC2 instance types

Most EC2 shortlisting starts by naming the bottleneck. AWS groups instance types into broad categories that reflect a primary resource trade-off, and that trade-off usually maps cleanly to what is constraining the workload.

Let’s look at the different categories of instances below:

• General purpose: These instances offer a balance of compute, memory, and networking capabilities that can be used for a wide range of workloads.

• Compute optimized: These instances offer high compute power, making them ideal for applications that require intense processing.

• Memory optimized: These instances offer fast memory performance, specially designed for workloads that require large datasets in memory.

• Storage optimized: These instances are designed to offer high sequential read and write capabilities on local storage.

• Accelerated computing: These instances use hardware accelerators to offer complex calculations in a more efficient manner. They offer more parallelism for intensive workloads.

• High-performance computing: These instances are built to offer the best price-performance for high-performing compute instances. They are normally used to solve complex computational problems.

• Previous generations: AWS offers previous generation instance types for users who have optimized their applications around them and have yet to upgrade.

To simplify the selection process, the following table provides a quick reference to the most commonly used Amazon EC2 instance families and their typical workloads. This helps narrow down the appropriate instance options when designing an architecture.

Once we understand the instance families and their typical use cases, it’s important to know how to read an instance type name, so we can quickly identify family, generation, size, processor, and additional capabilities.

How do we read an instance type name?

It is important to identify different types of instances from each other. Instance types are named after family, generation, processor family, additional capabilities, and size. Let’s understand the nomenclature of instance types with an example.

Consider an instance r7gd.16xlarge:

• The first position (r) in the instance type name is used to refer to the instance family.

• The second position (7) is used to represent the instance generation.

• The third position (g) is used to represent the processor family in the instance.

• The last position (d) before the period (.) i.e., the fourth position is used to highlight additional capabilities of the instance.

• After the period (.), the instance size is represented such as small, xlarge and etc.

With this structure in mind, we can now decode any instance name. The table below illustrates how each component maps to real-world examples:

EC2 virtualization platform and storage considerations

When evaluating EC2 instance types, two final checks help prevent operational surprises: 

• The virtualization platform (hypervisor)

• Storage configuration

AWS Nitro vs. Xen hypervisor

Every EC2 instance runs on a virtualization platform that allows multiple virtual machines to share the same physical hardware. Historically, Amazon EC2 used the Xen hypervisor, but most modern instance families now run on the AWS Nitro system.

The virtualization platform affects several operational characteristics, including:

• Performance isolation between instances

• Networking and storage performance

• Availability of newer EC2 features

• Hardware offloading capabilities

The Nitro system moves many traditional hypervisor functions into dedicated hardware and lightweight software components. This reduces virtualization overhead and improves performance consistency. As a result, most current-generation instance families are Nitro-based.

Older instance families may still use the Xen hypervisor, which relies more heavily on software-based virtualization.

For solutions architects, this distinction is an important verification step after narrowing down candidate instance types, especially when evaluating performance-sensitive workloads or feature compatibility.

EC2 root volume vs. instance store

Storage configuration is another area that often causes confusion. The root volume is the boot disk attached to an instance when it launches. In most cases, the root volume is Amazon EBS–backed, and its size and type are defined by the AMI and block device mapping.

Some instance types also provide instance store, which is physically attached storage on the host machine. This storage often appears as local NVMe drives and provides very high I/O performance.

However, these two concepts are independent:

• An instance can boot from an EBS root volume even if it provides local NVMe instance storage.

• The presence of local NVMe drives does not determine how the root volume is configured.

When selecting an EC2 instance type, architects typically begin by choosing a workload-appropriate instance family, then select the generation and size, and finally verify platform and storage details. Treating these factors as final validation checks keeps the selection process simple while ensuring the chosen instance type supports the required performance and operational characteristics.

Note: A common misconception is assuming that instance types with a d suffix determine how the root volume behaves. In reality, the d suffix only indicates that the instance type includes local instance store (NVMe) storage. Root volume configuration is controlled separately.

How to select an EC2 instance

A systematic approach, grounded in workload analysis and empirical validation, can efficiently narrow the vast selection of instance types to those best suited for a given application.

Step 1: Analyze workload bottlenecks

The first step involves analyzing the workload bottleneck. Architects must determine whether the application is constrained by processing power, memory capacity, disk input/output operations, or network throughput. 

• CPU-bound: Tasks like video encoding or batch processing need high compute capacity.

• Memory-bound: Large databases or in-memory caches require significant RAM.

• I/O-bound: Data warehousing and log processing benefit from fast storage.

• Network-bound: Distributed systems or network appliances need enhanced networking.

Step 2: Choose the appropriate instance family

Once the primary bottleneck is identified, the appropriate instance family can be selected.

• Compute-optimized (C series): CPU-intensive workloads.

• Memory-optimized (R series): Large datasets and memory-heavy applications.

• Storage-optimized (D series): High read/write performance for I/O-heavy workloads.

• General purpose (M and T series): Balanced resources for typical workloads without extreme requirements.

Step 3: Decide on processor architecture

Processor architecture represents the next consideration. Pick a processor type based on compatibility, cost, and performance.

• Intel: Broad software support, suitable for legacy applications.

• AMD: Cost-effective x86 alternative.

• AWS Graviton (ARM-based): High price-performance for workloads that can run on ARM architecture.

Step 4: Right-size the instance

With family and architecture determined, right-sizing follows. Match the instance size to the application’s specific resource needs.

• Examine resource usage patterns such as memory and CPU utilization.

• Choose the size within the selected family (e.g., large, xlarge) that satisfies these requirements without over-provisioning.

Step 5: Validate with empirical testing

The final step involves empirical validation. The selected instance should be launched in an On-Demand capacity, subjected to representative load tests, and monitored through Amazon CloudWatch. Performance metrics shall reveal whether resources are over-provisioned or under-provisioned, informing any necessary adjustments to the instance selection.

Real-life scenario: The e-commerce startup

Consider the case of a rapidly growing e-commerce application comprising two distinct components: a Node.js web frontend that processes user requests and a backend MySQL relational database.

For the web frontend, Node.js exhibits CPU-bound characteristics with unpredictable traffic patterns that spike during promotional sales events. Following the recommended approach, the general purpose family emerges as the appropriate category. Within this family, burstable instances such as the t3 or t4g series prove particularly suitable. These instances maintain low baseline costs during normal traffic periods while possessing the ability to burst CPU performance when demand escalates during flash sales.

The database component presents different requirements. Relational databases depend heavily on caching mechanisms, with performance closely tied to available memory for query caching. This bottleneck maps directly to the memory-optimized family. An r6g instance (a Graviton-based R-series instance) provides the substantial RAM pool necessary for effective database caching while leveraging Graviton processors to minimize hourly on-demand costs in the us-east-1 region.

This systematic approach transforms instance selection from a potentially overwhelming exercise into a structured decision process, ensuring that architectural choices align with workload characteristics and operational requirements.