# Instance type

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/instance-type

## Quick definition

When you create a virtual server in AWS, you choose an instance type to decide how powerful it will be. Each instance type has a certain number of virtual CPUs, a certain amount of memory, and specific storage options. Picking the right instance type ensures your application runs well without paying for resources you don't need.

## Simple meaning

Imagine you are buying a new laptop for school. You can choose from different models: some have a fast processor for gaming, others have lots of memory for video editing, and some are just basic for writing documents. An instance type in AWS is exactly that kind of choice, but for a virtual server running in the cloud. AWS offers many instance types grouped into families, like general-purpose (great for everyday tasks), compute-optimized (for heavy number crunching), memory-optimized (for large databases), and storage-optimized (for huge amounts of data). Each instance type has a name, like t3.micro or m5.large. The first part (t3, m5) tells you the family and generation, and the second part (micro, large) tells you the size within that family. A larger size means more vCPUs (virtual CPUs) and more RAM. You pay per hour based on the instance type, so a larger instance costs more. The key is to match the instance type to what your application needs. If you pick one that is too small, your application will be slow. If you pick one that is too big, you waste money. AWS also offers burstable instance types (like the t3 series) that give you a baseline performance and allow you to burst higher when needed, which is perfect for workloads that are not always busy. Understanding instance types is fundamental to designing cost-effective and performant systems on AWS.

## Technical definition

An AWS instance type is a named configuration that defines the virtual hardware resources allocated to an Amazon Elastic Compute Cloud (EC2) instance. This includes the number of virtual Central Processing Units (vCPUs), the amount of memory (RAM), the instance storage (if any), the network performance, and sometimes specific hardware accelerators like GPUs or FPGAs. Each instance type belongs to a family that is optimized for a particular type of workload. For example, the C5 family (compute-optimized) has a higher ratio of vCPUs to memory, suitable for compute-intensive tasks like batch processing. The R5 family (memory-optimized) has a larger memory footprint relative to vCPUs, ideal for in-memory caches and large databases. The T3 family (burstable general-purpose) uses the Intel Turbo Boost technology and AWS's own Nitro system to provide a baseline level of CPU performance with the ability to burst above that baseline for short periods, accumulating CPU credits for later use. The instance type naming convention follows a pattern: [family][generation].[size], e.g., m5.large. The 'm' indicates general-purpose, '5' is the generation (based on the underlying hardware, often using AWS Nitro), and 'large' is the size. Sizes double in capacity: nano, micro, small, medium, large, xlarge, 2xlarge, 4xlarge, etc. Each instance type is backed by a specific hypervisor (Nitro or Xen), and the Nitro system provides near-bare-metal performance by offloading virtualization functions to dedicated hardware. When launching an instance, you must select an instance type that is available in the chosen Availability Zone and meets the requirements of your Amazon Machine Image (AMI). Changing an instance type after launch is possible by stopping the instance, modifying the type, and starting it again, but this changes the underlying host. Instance types are also fundamental to AWS pricing models like Reserved Instances (RIs) and Savings Plans, where you commit to a specific instance type and region for a discount. CloudWatch metrics like CPUUtilization, MemoryUtilization, and NetworkIn/Out are used to monitor whether the chosen instance type is appropriately sized.

## Real-life example

Think of instance types as different classes of rental cars at an airport. A rental company has a whole fleet: economy cars (like a Toyota Yaris), compact cars (a Honda Civic), midsize sedans (a Toyota Camry), full-size sedans (a Nissan Maxima), SUVs (a Ford Explorer), and luxury sports cars (a Porsche 911). Each car type is like an instance family. The economy car is great for one person running errands around town-it's cheap and gets good gas mileage, but you wouldn't take it on a long mountain road trip with four people and luggage. That would be like using a tiny t3.nano instance for a heavy database-it will struggle. The midsize sedan is the all-rounder: good for commuting, comfortable, and can handle a small family. That's like an m5.large instance, good for web servers and small applications. The SUV is for when you need to tow a boat or carry a lot of gear-that's a memory-optimized r5 instance for large databases. The sports car is for speed, like a compute-optimized c5 instance for high-performance computing. Now, within each category, there are different sizes. The compact car might come in a 4-cylinder version and a more powerful V6 version. In AWS, the 'size' of the instance (like 'large' vs '2xlarge') is like the engine size-more vCPUs and more memory. You wouldn't rent a Porsche to move furniture, and you wouldn't rent an economy car for a cross-country road trip with four friends. Picking the right rental car (instance type) saves you money and ensures your trip (your application) goes smoothly. If you pick the wrong one, you either pay too much for features you don't use or you end up stranded on the side of the road (your app crashes).

## Why it matters

Choosing the correct instance type is one of the most important decisions you make when deploying applications on AWS because it directly impacts both cost and performance. In a real IT environment, you are not just spinning up one server for a test; you might manage hundreds or thousands of EC2 instances for production workloads. If you select an instance type that is too small, your application will experience high CPU utilization, memory pressure, and slow response times, leading to a poor user experience and potential downtime. If you select one that is too large, you are wasting money on unutilized resources, which can significantly inflate your cloud bill. For example, a web application serving static pages might run perfectly well on a burstable t3.medium instance, but if you mistakenly choose a compute-optimized c5.2xlarge, you could be paying four times as much for processing power you never use. IT professionals must also consider the network performance of an instance type, as some types offer higher network bandwidth and support for Enhanced Networking (SR-IOV), which is critical for data-intensive applications. Instance types also determine the maximum number of Elastic Network Interfaces (ENIs) and IP addresses you can attach, which is important for designing high-availability architectures. Certain instance types offer instance store volumes (ephemeral storage), which provide very high I/O performance but are lost when the instance stops. Understanding these nuances allows an architect to match the workload to the right instance family and size, balancing cost, performance, and reliability. This is a core skill for any AWS professional, as it appears in designing architectures, troubleshooting performance issues, and optimizing costs.

## Why it matters in exams

Instance types are a core concept in the AWS Certified Solutions Architect (SAA), AWS Certified Developer (DVA), and AWS Certified SysOps Administrator (SOA) exams. For the AWS Certified Cloud Practitioner (CLF), instance types are covered at a high level, focusing on the main families (general purpose, compute optimized, memory optimized) and the idea of right-sizing. In the Solutions Architect exam, you will frequently see scenario-based questions where you must choose the most cost-effective and high-performance instance type for a given workload. For example, a question might describe a company running a high-performance computing (HPC) workload that requires high CPU performance and low latency between instances. You would need to choose a compute-optimized instance (like C5 or C6g) and consider placement groups. Another question might involve a memory-intensive application like an in-memory cache, where a memory-optimized instance (R5 or X1) is the correct answer. The Developer exam often focuses on selecting instance types for specific application tiers, like using T3 instances for development environments to save costs, and understanding how burstable credits work. The SysOps exam might present a scenario where you need to troubleshoot a performance issue and decide to resize an instance to a larger type or switch families. The exam objectives from AWS explicitly list 'Identify the appropriate instance type, family, and size for a given workload' as a key task. You will also encounter questions about instance pricing models (On-Demand, Reserved, Spot) which are tied to instance types. Common question patterns include: 'A company wants to reduce costs without sacrificing performance for a steady-state workload. Which instance type and purchasing option should they choose?' (Answer: Reserved Instances for a specific instance type). Or 'An application requires very high disk I/O. Which instance type family should the architect select?' (Answer: Storage-optimized, like I3 or D2). Mastering instance types is not optional; it is a core exam competency.

## How it appears in exam questions

Instance type questions appear in several distinct patterns across AWS certification exams. The most common is the scenario-based selection question. For example: 'A company runs an e-commerce platform that experiences unpredictable spikes in traffic. The application needs consistent CPU performance during the spikes but can use lower performance during off-peak hours. Which instance type is MOST cost-effective?' The answer would likely be a T3 burstable instance, because it can burst during spikes and accumulate credits during idle time. Another pattern is the troubleshooting question: 'Users report that the web application is responding slowly. CloudWatch metrics show CPUUtilization is consistently at 95% for the t3.medium instance. What should the SysOps administrator do?' The correct action is to stop the instance, change the instance type to a larger size (e.g., t3.large or m5.large), and start the instance. A third pattern involves networking: 'An application requires 10 Gbps network throughput between two EC2 instances in the same placement group. Which instance type should be chosen?' The answer must be an instance type that supports Enhanced Networking and is large enough to provide that bandwidth (e.g., c5n.xlarge or higher). A fourth pattern mixes instance types with pricing models: 'A company needs a compute instance to run a batch job that can be interrupted. The job takes 30 minutes and runs every night. Which combination of instance type and purchasing option is MOST cost-effective?' Here, you would select a Spot Instance with a compute-optimized instance type (C5). A fifth pattern is about storage: 'An application requires very low latency access to large datasets that are temporary in nature and do not need to persist beyond the instance lifecycle. Which instance type should the architect choose?' This points to an instance type with instance store (ephemeral storage), like an I3 or D2 instance. Finally, you might see questions about the naming convention: 'Given the instance type r5d.2xlarge, what does the 'r' represent?' The answer is memory-optimized family, and the 'd' indicates NVMe instance store. Understanding these patterns helps you quickly eliminate wrong options and focus on the instance family and characteristics that match the scenario.

## Example scenario

You are an AWS Solutions Architect for a startup that runs a photo-sharing social media app. The app has two main components: a frontend web server that handles user requests and serves static images, and a backend database server that stores user profiles and photo metadata. The frontend servers experience variable traffic: high during evenings and weekends, but low during work hours. The database server requires a lot of memory because it caches frequently accessed data. Currently, you have launched both frontend and database servers using the same instance type: m5.large. After analyzing CloudWatch metrics, you notice that the frontend servers have very low CPU utilization (10-20%) most of the day, but spike to 80% during peak hours. The database server, on the other hand, is consistently using 70% of its memory and the CPU is at 30%. You realize you can optimize costs and performance. For the frontend servers, you decide to switch them to t3.large instances because they can burst during peak hours and earn credits during low traffic periods, saving money compared to always paying for the m5.large. For the database server, you choose an r5.large instance because it has double the memory of the m5.large for a similar price, which will reduce disk read operations and speed up the application. After making these changes, the application performs better and the monthly bill drops by 20%. This scenario shows how selecting the right instance type for each workload component can dramatically improve both performance and cost efficiency.

## Common mistakes

- **Mistake:** Choosing a burstable instance (T3/T4g) for a workload that consistently runs at high CPU utilization.
  - Why it is wrong: Burstable instances rely on CPU credits to provide performance above a baseline. If the CPU is always high, credits are consumed faster than they are earned, leading to 'CPU credit exhaustion'. The instance is then throttled to the baseline, causing severe performance degradation.
  - Fix: For consistently high CPU workloads (e.g., 40% or more), choose a non-burstable instance family like M5 (general-purpose) or C5 (compute-optimized) to ensure stable performance.
- **Mistake:** Selecting an instance type based solely on vCPU count and ignoring memory requirements.
  - Why it is wrong: A compute-optimized C5.large has 2 vCPUs and 4 GB of RAM, while a memory-optimized R5.large also has 2 vCPUs but 16 GB of RAM. If your application needs 10 GB of RAM, the C5.large will run out of memory, while the R5.large is perfectly suited. vCPU count alone does not tell the whole story.
  - Fix: Always consider the memory-to-vCPU ratio defined by the instance family. Use CloudWatch metrics (MemoryUtilization if configured) to understand actual memory needs before choosing.
- **Mistake:** Assuming that all instance types are available in every Availability Zone.
  - Why it is wrong: Newer instance types or specific sizes may only be available in certain AZs or regions. Launching an instance will fail if the selected type is not available in the chosen subnet/AZ.
  - Fix: Use the AWS CLI command 'aws ec2 describe-instance-type-offerings' to check availability in your target region and AZ before launching. Alternatively, select 'No preference' for the AZ to let AWS choose an available one.
- **Mistake:** Confusing instance type family with instance size when scaling.
  - Why it is wrong: Scaling from a t3.medium to a t3.xlarge doubles vCPU and memory within the same family, which is fine for general scaling. But if the workload shifts from being CPU-bound to memory-bound, scaling within the same family (e.g., t3 to t3) won't fix the resource imbalance; you need to switch families (e.g., from t3 to r5).
  - Fix: When scaling, first identify which resource is the bottleneck (CPU, memory, network, or storage). Then choose the appropriate family and then the size within that family.
- **Mistake:** Forgetting that some instance types require an HVM AMI (Hardware Virtual Machine) but not a PV AMI (Paravirtual).
  - Why it is wrong: Many modern instance types (especially those using the Nitro hypervisor) only support HVM AMIs. Using a PV AMI will result in an immediate launch failure.
  - Fix: Always use an HVM AMI for current-generation instance types. AWS recommends using the latest Amazon Linux 2 or Amazon Linux 2023 AMIs which are HVM.

## Exam trap

{"trap":"A question says: 'Your application requires high single-threaded CPU performance. Which instance type should you choose?' The trap offer includes a C5 instance (typically compute-optimized) and a T3 instance (burstable). The T3 instance is cheaper, and the learner thinks 'burstable means it can go fast,' so they choose T3.","why_learners_choose_it":"Learners may not understand that 'burstable' applies to sustained CPU usage, not instantaneous clockspeed. T3 instances have a baseline limit and use credits. Even when bursting, they cannot sustain high single-thread performance indefinitely. Also, the C5 family uses faster Intel Xeon processors with higher clock speeds per core.","how_to_avoid_it":"For high single-threaded performance, always choose a compute-optimized instance (C5 family) because it offers dedicated, high-frequency cores. T3 family is for variable workloads that need cost savings, not for consistent high single-threaded CPU demand."}

## Commonly confused with

- **Instance type vs AMI (Amazon Machine Image):** An AMI is a template that includes the operating system, software, and configuration used to launch an instance. The instance type is the hardware specification (vCPU, memory) that the AMI runs on. You cannot launch an instance without both an AMI and an instance type, but they are separate choices. (Example: Choosing a Windows Server AMI and an m5.large instance type means you get a virtual Windows server with 2 vCPUs and 8 GB of RAM.)
- **Instance type vs Elastic IP (EIP):** An Elastic IP is a static public IPv4 address that can be attached to an instance. The instance type does not affect whether you can use an Elastic IP. They are orthogonal concepts. (Example: You can attach an Elastic IP to a t3.nano instance just as easily as to a c5.24xlarge instance.)
- **Instance type vs Security Group:** A security group acts as a virtual firewall that controls inbound and outbound traffic for an instance. The instance type has no influence on which security groups you apply; all instance types support security groups. (Example: A t3.micro instance and an r5.2xlarge instance can both be members of the same security group that allows HTTP traffic.)
- **Instance type vs Availability Zone (AZ):** An AZ is a distinct physical location within an AWS region. While some instance types may not be available in every AZ, the AZ is about geographic placement, not about the virtual hardware of the instance. (Example: You might need to launch an i3en.2xlarge instance in us-east-1a, but that type may only be available in us-east-1b, so you must choose a different AZ.)

## Step-by-step breakdown

1. **Identify the workload requirements** — Before choosing an instance type, analyze the application's requirements: Is it CPU-bound, memory-bound, storage-intensive, or network-intensive? Estimate the amount of vCPUs, memory (GB), storage (GB and IOPS), and network bandwidth needed. This step is foundational and often ignored in exam scenarios.
2. **Choose the instance family based on the primary resource need** — Select the family that matches the workload type: General-purpose (M series) for balanced workloads, Compute-optimized (C series) for CPU-intensive tasks, Memory-optimized (R, X series) for memory-heavy apps, Storage-optimized (I, D, H series) for high disk I/O, and Accelerated computing (P, G, F series) for GPU/FPGA workloads. Each family is designed with a specific resource ratio.
3. **Select the generation within the family** — Current generation instance types (e.g., M5, C6g) offer better features, performance, and cost efficiency compared to previous generations (M4, C5). AWS recommends using current generation types unless you have a specific compatibility reason. They also support newer features like Enhanced Networking and the Nitro hypervisor.
4. **Choose the instance size (e.g., large, xlarge, 2xlarge)** — Within the chosen family and generation, pick a size that provides the exact amount of vCPUs and memory needed. Sizes double in capacity (nano: 0.5 vCPU, micro: 1 vCPU, small: 1 vCPU, medium: 2 vCPUs, large: 2 vCPUs, xlarge: 4 vCPUs, 2xlarge: 8 vCPUs, etc.). It is often better to start with a smaller size and scale up if needed, rather than overprovisioning.
5. **Verify availability and launch** — Check that the chosen instance type is available in the desired region and Availability Zone using the AWS Management Console, CLI, or API. Some types are only available in certain AZs. Then, launch the instance with the appropriate AMI, subnet, and other configuration. After launch, monitor CloudWatch metrics to confirm the instance is not under- or over-used, and resize if necessary.

## Practical mini-lesson

In practice, selecting an instance type is rarely a one-time decision. Most production environments start with a choice based on best guesses, but then use monitoring data to right-size. AWS CloudWatch provides key metrics: CPUUtilization, NetworkIn, NetworkOut, and DiskReadOps/DiskWriteOps. However, memory utilization is not reported by default; you must install the CloudWatch agent on the instance to capture it. A common mistake is to only look at CPU and ignore memory, leading to poor performance. For example, a Java application may have low CPU but high memory usage, and you might keep scaling up CPU unnecessarily when you really need a memory-optimized instance.

When you decide to change an instance type after launch, you must stop the instance first. Stopping an instance does not change its private IP address if it is in a VPC, but it does move the instance to a different underlying host. If you are using instance store volumes (ephemeral), stopping the instance will cause data loss because instance store data is only preserved during the instance's lifetime. For production workloads using EBS-backed instances, stopping is safe. Always test the change first in a non-production environment.

Another practical consideration is the network performance of different instance types. Larger instances often have higher network bandwidth. For example, a t3.nano has a network bandwidth of up to 5 Gigabits per second (Gbps), while a t3.xlarge has up to 25 Gbps. If your application is sensitive to network latency (e.g., real-time data streaming), you need to choose an instance type that supports Enhanced Networking (SR-IOV) which provides higher packet-per-second performance and lower latency. Most current generation instances support this by default.

Cost optimization is a major part of the job. For steady-state workloads, you should purchase Reserved Instances (RIs) or use Savings Plans to get a discount over On-Demand pricing. For fault-tolerant workloads, Spot Instances can give you up to 90% discount, but the instance can be terminated with 2 minutes of notice. You must design your application to handle interruptions. Understanding the tradeoff between flexibility (On-Demand) and cost (Reserved, Spot) is crucial.

Finally, remember that instance types evolve. AWS regularly releases new generations with better price-per-performance ratios. A well-architected system periodically reviews its instance types and migrates to newer generations when it makes sense. This is a key concept in the AWS Well-Architected Framework's cost optimization pillar. Professionals should stay informed via AWS announcements and re:Invent sessions.

## Memory tip

Think 'FGS', Family, Generation, Size. Always match the Family to the workload's main resource need (C for CPU, R for RAM, I for I/O, M for mix).

## FAQ

**Can I change the instance type of a running EC2 instance?**

No, you must stop the instance first. Once stopped, you can change the instance type from the console or CLI, then start the instance again. This process does not affect EBS volumes or the private IP address (in a VPC).

**What does the 'd' mean in an instance type like r5d.2xlarge?**

The 'd' stands for 'local NVMe SSD storage'. It indicates that the instance type comes with instance store (ephemeral) volumes that are physically attached to the host. These offer very high I/O performance but data is lost if the instance stops or terminates.

**Are all instance types available in all AWS regions?**

No. Newer instance types or specific sizes may be limited to certain regions or even certain Availability Zones within a region. Use the AWS Management Console or the 'describe-instance-type-offerings' API to check availability.

**What is the difference between a t3.medium and an m5.medium?**

Both have 2 vCPUs, but the t3.medium has 4 GB of RAM and is a burstable instance (baseline 20% CPU), while the m5.medium has 8 GB of RAM and is a fixed-performance instance. The m5.medium costs more but provides consistent CPU. The t3 is cheaper but may throttle under sustained high CPU.

**Can I run a GPU-accelerated application on a general-purpose instance?**

No, GPU-accelerated workloads require instance types from the Accelerated Computing family (P3, P4, G4, G5, etc.) which have dedicated GPUs. General-purpose, compute-optimized, and memory-optimized instances do not include GPUs.

**How do I choose between an instance type with instance store vs EBS-only storage?**

Use instance store (ephemeral) for temporary data, caches, or data that can be easily replicated, because it offers high performance but is not durable. Use EBS-backed instances for persistent data that must survive instance stops or terminations.

## Summary

An instance type is the blueprint for the virtual hardware of an AWS EC2 instance, defining its vCPUs, memory, storage, and network capabilities. Choosing the right instance type is a critical skill in cloud computing because it directly affects the cost and performance of your applications. Each instance type belongs to a family optimized for a specific workload: general-purpose (M series), compute-optimized (C series), memory-optimized (R, X series), storage-optimized (I, D, H series), and accelerated computing (P, G, F series). Within each family, different sizes offer varying amounts of resources, and most current generation types use the advanced Nitro hypervisor for near-bare-metal performance. IT professionals must match the instance type to the workload requirements, monitor utilization with CloudWatch, and periodically right-size to optimize costs. In AWS certification exams, instance types are a core topic, appearing in scenario questions about selecting the best family and size for a given use case, troubleshooting performance issues, and understanding pricing models. Mastery of instance types is not just about memorizing families; it is about applying the right combination of resources to solve real-world architectural problems. Always start by analyzing the resource bottleneck, then choose the family, generation, and size accordingly. This systematic approach will help you build efficient, cost-effective cloud solutions and succeed in your exams.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/instance-type