Amazon EC2 instance types

Cloud virtual machines are offered in predefined hardware configurations rather than as interchangeable units of compute. Amazon EC2 instance types express this idea through families, generations, sizes, and capability indicators. A type specifies resources such as virtual CPUs, memory, supported processor architecture, network performance, storage connectivity, and, where applicable, local storage or accelerators. Choosing an instance type is therefore an exercise in matching a workload to a resource profile, not simply choosing the largest machine within a budget.

Instance families emphasize different resource balances. General-purpose configurations suit applications with balanced CPU and memory requirements. Compute-optimized configurations suit CPU-intensive processing, while memory-optimized configurations support workloads with large in-memory working sets. Storage-optimized configurations address demanding local storage requirements, and accelerated configurations provide hardware such as GPUs for compatible applications. These categories are starting points; actual workload measurements are more useful than family labels alone.

EC2 names encode parts of the configuration. For example, m7i.large identifies the general-purpose m family, generation 7, an Intel processor variant, and the large size. Capability suffixes are family-specific, so their meanings should be checked rather than inferred universally. Sizes indicate resource scale within a family, but the same size label across different families does not guarantee equal memory, throughput, or performance. Likewise, a newer generation is not automatically the best choice for every application.

Processor compatibility matters. An Arm-based instance requires a compatible operating system image and application binaries or container images. Software compiled only for x86 cannot simply run unchanged on Arm hardware. Virtual CPU counts also require interpretation: on many x86 configurations, a vCPU represents a hardware thread, while on Graviton configurations it represents a physical core. Equal vCPU counts therefore do not guarantee equivalent application throughput.

Consider an API server with low average CPU usage and occasional traffic spikes. A burstable configuration may be economical, but sustained demand can consume CPU credits. Depending on its credit mode, the instance may fall back toward baseline performance or incur surplus credit charges. A continuously busy application may achieve more predictable economics on a non-burstable configuration. By contrast, a database that repeatedly reads from disk because its working set exceeds RAM may benefit more from additional memory than from additional CPUs.

Storage and networking impose separate limits. Attaching a faster block volume does not remove the instance's own block-storage throughput limits, and advertised network performance can include baseline and burst characteristics. Local instance-store storage must be treated as ephemeral: its data does not survive events such as instance stop or termination. Durable application state generally belongs on persistent volumes or external storage services.

Instance type selection is separate from purchasing model and scaling strategy. On-Demand, Spot, and commitment-based discounts affect cost or availability terms, not the underlying resource specification. Vertical resizing can increase resources per machine, while horizontal scaling adds machines and requires an application that can distribute work. For typical EBS-backed EC2 instances, changing type requires stopping and starting the instance, and the replacement type must satisfy compatibility requirements. Engineers should benchmark representative traffic, monitor CPU, memory, storage latency, and network utilization, and check regional availability, quotas, and capacity before adopting a configuration.