EC2 Instance Types Guide: How to Choose the Right One (and Save Money)

Amazon EC2 has hundreds of instance types. When you open the instance type selector in the AWS Console for the first time, you are greeted with names like t3.micro, m7g.xlarge, and r6i.2xlarge. It looks like alphabet soup.

But there is a logic to it. Every instance type name tells you exactly what it is optimized for, how powerful it is, and what generation of hardware it uses. Once you decode the naming convention, choosing the right instance becomes straightforward.

This guide will teach you how to read instance type names, when to use each family, and how to pick the right pricing model to avoid overspending.

Prerequisites: You should understand cloud computing basics before starting this article.

What You Will Learn

By the end of this article, you will be able to:

• Explain the EC2 naming convention and identify the family, generation, processor, and size of any instance type
• Compare the five main instance families and select the right one based on workload bottlenecks (CPU, memory, storage, or GPU)
• Evaluate On-Demand, Reserved Instances, Savings Plans, and Spot pricing to design a cost-optimized compute strategy
• Configure Auto Scaling groups with target tracking policies and launch templates using the AWS CLI
• Troubleshoot common EC2 launch and connectivity issues including pending state, SSH failures, and application health problems

Decoding the Instance Type Name

Every EC2 instance type follows a naming convention: Family + Generation + [Additional Info] + Size.

Let us decode m7g.xlarge:

m    7    g    .    xlarge
|    |    |         |
|    |    |         +-- Size (CPU, memory, network)
|    |    +------------ Additional: Graviton (ARM processor)
|    +----------------- Generation: 7th generation
+---------------------- Family: General purpose

Here is another example. c6i.2xlarge:

c    6    i    .    2xlarge
|    |    |         |
|    |    |         +-- Size: 2xlarge (8 vCPUs, 16 GB RAM)
|    |    +------------ Additional: Intel processor
|    +----------------- Generation: 6th generation
+---------------------- Family: Compute optimized

Common Additional Indicators

You can combine these indicators. For example, m7gd.xlarge is a 7th-gen general purpose Graviton instance with local NVMe storage.

Instance Sizes

Sizes scale predictably. Each step up roughly doubles the resources:

Pro tip: Always use the latest generation available. Newer generations deliver better performance at the same or lower price. A t3.micro is cheaper and faster than a t2.micro. A m7g.large outperforms a m5.large at a lower cost per hour.

# Check available instance types in your Region
aws ec2 describe-instance-types \
  --filters "Name=instance-type,Values=m7g.*" \
  --query "InstanceTypes[].{Type:InstanceType,vCPUs:VCpuInfo.DefaultVCpus,MemGB:MemoryInfo.SizeInMiB}" \
  --output table

The Five Main Instance Families

General Purpose (T, M)

Best for: Balanced workloads that need a mix of compute, memory, and networking.

Common types: t3.micro, t3.medium, m7g.large, m6i.xlarge

Use cases:

• Web servers and application servers
• Development and test environments
• Small to medium databases
• Code repositories
• Microservices

The T family (t3, t4g) is special because it uses a burstable CPU model. Your instance earns CPU credits when idle and spends them when busy. This is perfect for workloads that occasionally spike but are mostly low-utilization. A t3.micro is Free Tier eligible and is where most beginners start.

The M family (m7g, m6i, m7i) provides a consistent balance of compute, memory, and networking without the burstable model. Use M instances when your workload needs steady, predictable performance.

Understanding T-Family CPU Credits

This concept confuses many beginners and is worth understanding in detail:

Baseline CPU means the guaranteed CPU performance level. A t3.micro runs at 10% CPU consistently. When it needs to burst (handle a traffic spike), it spends accumulated credits to run at up to 100% CPU.

What happens when credits run out?

• Standard mode (default): CPU is throttled to the baseline. Your application slows down but keeps running.
• Unlimited mode: Instance can burst past baseline indefinitely. You pay a small surcharge ($0.05 per vCPU-hour of burst).

# Check CPU credit balance
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-abc123 \
  --start-time 2026-05-11T00:00:00Z \
  --end-time 2026-05-12T00:00:00Z \
  --period 3600 \
  --statistics Average

Decision rule: If your average CPU utilization stays above the baseline for extended periods, switch to an M-family instance. T-family is for bursty workloads, not sustained compute.

Compute Optimized (C)

Best for: Workloads that require high-performance processors.

Common types: c7g.large, c6i.xlarge, c7gn.medium

Use cases:

• Batch processing
• Media transcoding (video encoding)
• High-performance computing (HPC)
• Scientific modeling
• Machine learning inference
• Gaming servers
• CPU-intensive web servers

Compute optimized instances have a higher ratio of vCPUs to memory compared to general purpose instances. A c6i.xlarge has 4 vCPUs and 8 GB RAM, while an m6i.xlarge has 4 vCPUs and 16 GB RAM, same CPU, half the memory, lower price.

If your workload does not need 16 GB of RAM, why pay for it? That is the value of compute optimized instances.

Memory Optimized (R, X, z)

Best for: Workloads that process large datasets in memory.

Common types: r7g.xlarge, r6i.2xlarge, x2idn.xlarge

Use cases:

• In-memory databases (Redis, Memcached, SAP HANA)
• Real-time big data analytics
• High-performance relational databases
• In-memory caching layers

Memory optimized instances provide the most RAM per dollar. An r6i.xlarge gives you 4 vCPUs and 32 GB RAM, that is double the memory of an m6i.xlarge at the same vCPU count. If your application is memory-bound (database queries scanning large datasets, caching servers holding hot data), this family saves you money because you need fewer instances.

Storage Optimized (I, D, H)

Best for: Workloads that require high, sequential read/write access to very large datasets on local storage.

Common types: i4i.xlarge, d3.xlarge, h1.2xlarge

Use cases:

• High-frequency online transaction processing (OLTP) databases
• Data warehousing
• Distributed file systems (HDFS, Elasticsearch)
• Log processing

Storage optimized instances include high-performance NVMe SSDs directly attached to the host. This local storage is faster than EBS but is ephemeral, meaning it is lost when the instance stops or terminates. Use these for workloads where the data is replicated elsewhere (like a distributed database that replicates across nodes).

Key warning: Instance store data is lost when an instance stops, terminates, or the underlying hardware fails. Always replicate critical data to EBS or S3.

Accelerated Computing (P, G, Inf, Trn)

Best for: Workloads that require hardware accelerators (GPUs or custom chips).

Common types: p5.48xlarge, g5.xlarge, inf2.xlarge, trn1.2xlarge

Use cases:

• Machine learning training (P and Trn families)
• Machine learning inference (Inf family)
• Graphics rendering (G family)
• Video processing
• Genomics

These instances are expensive and specialized. Most beginners will not use them, but you should know they exist for architecture discussions and interviews. AWS Trainium chips (Trn1) and AWS Inferentia chips (Inf2) are custom-designed by AWS for ML workloads and offer better price-performance than GPU instances for supported frameworks.

The Instance Family Quick Reference

How to Choose: A Decision Framework

Ask yourself these four questions:

1. Is my workload bursty or steady?

• Bursty (occasional spikes, mostly idle): Start with a T family instance
• Steady (consistent utilization): Use an M family instance

2. What is my bottleneck?

• CPU-bound (processing, encoding, computation): Use C family
• Memory-bound (large datasets in memory, caching): Use R family
• Storage-bound (high I/O, large local datasets): Use I or D family
• Balanced (no single bottleneck): Use M family

3. Can I use ARM (Graviton)?

• If your application runs on Linux and does not require x86-specific software: Yes, use Graviton. Graviton instances (indicated by "g" in the name, like m7g or c7g) offer up to 40% better price-performance than their Intel/AMD equivalents.
• If your software requires Windows or specific x86 instructions: Use Intel (i) or AMD (a) variants.

4. What size do I need?

• Start small. You can resize an EC2 instance by stopping it, changing the instance type, and starting it again. There is no penalty for starting with a t3.small and upgrading to a t3.large later.

# Resize an instance (must be stopped first)
aws ec2 stop-instances --instance-ids i-abc123

# Wait for it to stop, then change the type
aws ec2 modify-instance-attribute \
  --instance-id i-abc123 \
  --instance-type '{"Value": "m7g.large"}'

aws ec2 start-instances --instance-ids i-abc123

Real-World Instance Selection Examples

EC2 Pricing Models: How to Pay Less

Choosing the right pricing model can reduce your EC2 bill by 30-72%. Here are the four options.

On-Demand

How it works: Pay by the second (Linux) or by the hour (Windows) with no commitment.

Best for: Unpredictable workloads, short-term projects, testing and development.

Discount: None (this is the baseline price).

# Example: t3.micro On-Demand in us-east-1
$0.0104 per hour = ~$7.59 per month (running 24/7)

# Example: m7g.large On-Demand in us-east-1
$0.0816 per hour = ~$59.57 per month (running 24/7)

On-Demand is the default and the most flexible option. You pay only while the instance is running, and you can start or stop it at any time. The downside is that it is the most expensive per-hour option for long-running workloads.

Reserved Instances (RIs)

How it works: Commit to using a specific instance type in a specific Region for 1 or 3 years.

Best for: Steady-state workloads where you know you will run the same instance type for at least a year.

Discount: Up to 72% compared to On-Demand.

Reserved Instances require planning. You are committing to a specific instance type, and if your needs change, you may end up paying for capacity you do not use. AWS offers Convertible RIs that let you change the instance family, but the discount is smaller (roughly 30-54%).

Savings Plans

How it works: Commit to a consistent amount of compute spending (measured in $/hour) for 1 or 3 years.

Best for: Organizations that want RI-level savings with more flexibility.

Discount: Up to 72% (similar to RIs).

There are two types:

• Compute Savings Plans: Apply to any instance family, any size, any Region, any OS, and even Fargate and Lambda. Maximum flexibility.
• EC2 Instance Savings Plans: Apply to a specific instance family in a specific Region, but any size within that family. Slightly higher discount than Compute Savings Plans.

Savings Plans are generally recommended over Reserved Instances for most customers because they offer comparable discounts with much more flexibility.

# View Savings Plans recommendations based on your usage
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS

Spot Instances

How it works: Bid on unused EC2 capacity at steep discounts. AWS can reclaim the instance with a 2-minute warning when it needs the capacity back.

Best for: Fault-tolerant workloads like batch processing, data analysis, CI/CD builds, and containerized microservices.

Discount: Up to 90% compared to On-Demand.

# Launch a Spot Instance
aws ec2 run-instances \
  --instance-type c6i.large \
  --instance-market-options '{"MarketType": "spot"}' \
  --image-id ami-0abcdef1234567890

# Check current Spot pricing
aws ec2 describe-spot-price-history \
  --instance-types c6i.large \
  --product-descriptions "Linux/UNIX" \
  --max-items 5

Spot instances offer the biggest savings but require your application to handle interruptions gracefully. If AWS needs the capacity back, your instance gets a 2-minute warning and then terminates. This is perfect for jobs that can be retried (batch processing, rendering) but terrible for databases or stateful applications.

Spot Instance Strategies

# Use Spot Fleet for automatic diversification
aws ec2 request-spot-fleet \
  --spot-fleet-request-config '{
    "IamFleetRole": "arn:aws:iam::123456789012:role/spot-fleet-role",
    "TargetCapacity": 10,
    "AllocationStrategy": "priceCapacityOptimized",
    "LaunchSpecifications": [
      {"InstanceType": "c6i.large", "ImageId": "ami-abc123"},
      {"InstanceType": "c6i.xlarge", "ImageId": "ami-abc123"},
      {"InstanceType": "c7g.large", "ImageId": "ami-abc123"},
      {"InstanceType": "m6i.large", "ImageId": "ami-abc123"}
    ]
  }'

Pricing Model Comparison

The Optimal Pricing Mix

Most production environments use a combination:

Auto Scaling: Match Capacity to Demand

Running a fixed number of EC2 instances is like on-premises thinking applied to the cloud. Auto Scaling automatically adjusts the number of instances based on demand.

Auto Scaling Components

1. Launch Template: Defines what to launch (AMI, instance type, security group, user data)
2. Auto Scaling Group (ASG): Manages the fleet (min, max, desired count)
3. Scaling Policy: When and how to scale (target tracking, step scaling, scheduled)

# Create a launch template
aws ec2 create-launch-template \
  --launch-template-name web-server-template \
  --launch-template-data '{
    "ImageId": "ami-abc123",
    "InstanceType": "m7g.large",
    "SecurityGroupIds": ["sg-abc123"],
    "UserData": "IyEvYmluL2Jhc2gKeXVtIHVwZGF0ZSAteQ=="
  }'

# Create an Auto Scaling group
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-server-template,Version='$Latest' \
  --min-size 2 \
  --max-size 8 \
  --desired-capacity 4 \
  --vpc-zone-identifier "subnet-abc123,subnet-def456" \
  --target-group-arns "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-tg/abc123"

# Add target tracking scaling (maintain 50% average CPU)
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0
  }'

Scaling Policy Types

Cost Optimization Tips

1. Right-Size Your Instances

Most EC2 instances are over-provisioned. Use AWS Compute Optimizer to analyze your utilization and get recommendations. Switching from a m5.xlarge to a m5.large cuts your cost in half with no effort.

# Get right-sizing recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123456789012:instance/i-abc123

2. Use Graviton Instances

Graviton (ARM) instances deliver better price-performance for most Linux workloads. Switching from m6i.large to m7g.large can save 20-40% on your bill.

These percentages compound significantly across a fleet of instances running 24/7.

3. Stop Idle Instances

Development and test instances do not need to run nights and weekends. Use AWS Instance Scheduler or a simple Lambda function to stop instances outside business hours.

# Manually stop an instance (you still pay for EBS storage)
aws ec2 stop-instances --instance-ids i-0abcdef1234567890

# Tag instances for automated scheduling
aws ec2 create-tags \
  --resources i-abc123 \
  --tags Key=Schedule,Value=office-hours

Running dev instances only during business hours (12 hours/day, 5 days/week) saves ~64% compared to running 24/7.

4. Use Spot for Batch Work

Any workload that can tolerate interruptions should use Spot instances. CI/CD pipelines, data processing jobs, and testing workloads are all candidates.

5. Set Up Cost Alerts

Use AWS Budgets to create alerts when your EC2 spending exceeds a threshold. Find out before the bill arrives, not after.

# View your current EC2 spending
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-05-31 \
  --granularity MONTHLY \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --metrics "UnblendedCost"

Pricing note: On-Demand rates, Graviton comparison prices, and EBS volume costs cited in this article are for us-east-1 and were verified in May 2026. Check the AWS Pricing Calculator for current rates in your Region.

6. Use the EC2 Instance Lifecycle

Understanding the instance lifecycle helps you avoid paying for instances you are not using:

Key insight: Stopped instances still cost money for their EBS volumes. If you do not need the instance again, terminate it. If you might need it later, stop it (EBS costs are much lower than instance costs).

EBS Volumes: Your Instance's Storage

EC2 instances need storage, and the most common option is Amazon Elastic Block Store (EBS). Think of EBS volumes as virtual hard drives that attach to your instance.

EBS Volume Types

Always use gp3 over gp2. gp3 is 20% cheaper and lets you independently configure IOPS and throughput. There is no reason to use gp2 for new workloads.

# Create a gp3 volume
aws ec2 create-volume \
  --volume-type gp3 \
  --size 100 \
  --iops 3000 \
  --throughput 125 \
  --availability-zone us-east-1a

# Attach it to an instance
aws ec2 attach-volume \
  --volume-id vol-abc123 \
  --instance-id i-abc123 \
  --device /dev/sdf

EBS Snapshots for Backups

EBS snapshots are point-in-time copies of your volumes stored in S3. They are incremental, meaning only changed blocks are stored after the first snapshot.

# Create a snapshot
aws ec2 create-snapshot \
  --volume-id vol-abc123 \
  --description "Daily backup 2026-05-12"

# Create a volume from a snapshot (for recovery)
aws ec2 create-volume \
  --snapshot-id snap-abc123 \
  --volume-type gp3 \
  --availability-zone us-east-1a

Cost tip: Snapshot storage costs $0.05/GB/month. Set up a lifecycle policy to delete old snapshots automatically using Amazon Data Lifecycle Manager.

Troubleshooting Common Errors

Instance stuck in "pending" state You launched an instance but it stays in pending for several minutes without transitioning to running. This is usually caused by insufficient capacity for the requested instance type in the selected Availability Zone. Try launching in a different AZ, or switch to a different instance size within the same family. If you are using a placement group, capacity constraints are more common. Run aws ec2 describe-instance-status --instance-id i-abc123 to check for status events. For Spot instances, a prolonged pending state may mean your request cannot be fulfilled at the current market price.

Cannot SSH to instance (connection timed out) The instance is running but you cannot connect via SSH. Check these items in order: (1) The security group attached to the instance must allow inbound traffic on port 22 from your IP address. (2) The instance must be in a public subnet with a public IP or Elastic IP, or you must be connecting through a bastion host or VPN. (3) The route table for the subnet must have a route to an internet gateway (for public subnets) or a NAT gateway (if using Session Manager). (4) The network ACL on the subnet must allow both inbound port 22 and the ephemeral outbound port range. Run aws ec2 describe-security-groups --group-ids sg-abc123 and aws ec2 describe-network-acls --filters Name=association.subnet-id,Values=subnet-abc123 to verify.

Instance running but application not responding The instance shows as running with passing status checks, but your web application returns errors or does not respond. Check that the application process actually started by reviewing the instance's system log with aws ec2 get-console-output --instance-id i-abc123. If you used a user data script, it may have failed silently. Also confirm the application's port (for example, 80 or 443) is open in the security group. If the instance recently exhausted its T-family CPU credits, the application may have become unresponsive due to CPU throttling. Check the CPUCreditBalance metric in CloudWatch.

EC2 Launch Checklist

Before launching an EC2 instance for production, verify these items:

Key Terms Quick Reference

Quick Knowledge Check

1. What does the "g" mean in m7g.xlarge?
2. Which instance family would you choose for an in-memory Redis cache?
3. What is the difference between a T family and an M family instance?
4. When should you avoid Spot instances?
5. Which pricing model offers the most flexibility with commitment-based discounts?
6. What happens when a T-family instance runs out of CPU credits?
7. Why should you prefer Graviton instances for Linux workloads?
8. What are the three components of an Auto Scaling setup?
9. How much can you save by running dev instances only during business hours?
10. What is the difference between stopping and terminating an instance?

Hands-On Challenge

Launch, connect to, monitor, and right-size an EC2 instance. When you are finished, verify you have met all of these success criteria:

1. A t4g.micro instance is running in a public subnet with a security group that allows SSH (port 22) only from your IP address
2. You can connect to the instance via SSH (or Session Manager) and run uname -m to confirm it is an ARM (aarch64) Graviton instance
3. CloudWatch detailed monitoring is enabled and you can view CPU utilization, network in/out, and disk read/write metrics
4. You installed a simple web server (such as nginx) via user data or SSH, and you can access the web page from your browser through the instance's public IP on port 80
5. You checked the CPUCreditBalance metric in CloudWatch and can explain whether the instance is earning or spending credits
6. You stopped the instance, changed the instance type to t4g.small, restarted it, and confirmed the web server is still running with the larger instance size
7. You created an EBS snapshot of the instance's root volume and verified the snapshot status is completed

My recommendation for anyone starting out: launch a t3.medium Graviton equivalent (t4g.medium) for everything. Run it for two weeks, check your CloudWatch CPU and memory metrics, then right-size from there. Nine times out of ten, Graviton instances are the right default for new Linux workloads because of the price-performance advantage. This topic is covered in more detail in Module 04: Compute with EC2 of our free AWS Bootcamp.