EC2 Instance Types Explained

Understanding EC2 Instance Type Naming

EC2 instance type names follow a consistent naming convention that tells you exactly what you are getting. Understanding this convention helps you quickly identify the right instance family for your workload without memorizing hundreds of instance types. AWS adds new instance types regularly, but the naming convention remains consistent.

The format is: [family][generation][additional capabilities].[size]. For example, m7g.xlarge means:

• m: General purpose family
• 7: 7th generation
• g: Graviton (ARM) processor
• xlarge: 4 vCPUs, 16 GiB memory

Each size doubles the resources of the previous size. An xlarge has 4 vCPUs, 2xlarge has 8, 4xlarge has 16, and so on up to metal (bare metal) for the full physical server. The nano, micro, small, medium, and large sizes provide smaller increments for lightweight workloads.

Processor and Capability Suffixes

Instance Families Explained

AWS organizes instance types into families based on the type of workload they are optimized for. Choosing the right family is the most important instance selection decision. Each family has a specific vCPU-to-memory ratio that determines its suitability for different workload profiles.

General Purpose (M, T Family)

General purpose instances provide a balance of compute, memory, and networking resources. They are the default starting point for most workloads. The M-family provides fixed performance, while the T-family provides burstable performance at a lower baseline price.

Compute Optimized (C Family)

Compute optimized instances have a higher ratio of CPU to memory (1:2) and are ideal for workloads that are CPU-bound. They provide the highest per-core performance available on EC2.

Memory Optimized (R, X, z Family)

Memory optimized instances have a higher ratio of memory to CPU (1:8 or higher) and are designed for workloads that process large datasets in memory. The X and z families provide extremely high memory (up to 24 TiB for x2idn).

Burstable vs Fixed Performance

T-family instances (T3, T3a, T4g) use a CPU credit system that allows you to burst above a baseline performance level. Each instance earns CPU credits at a fixed rate and spends them when CPU exceeds the baseline. This model is cost-effective for workloads with variable CPU usage (like web servers that handle occasional spikes) but can be problematic for sustained high-CPU scenarios.

CPU Credit System

# Check CPU credit balance and surplus for burstable instances
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --statistics Average \
  --output table

# Check for surplus credit charges (unlimited mode)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditBalance \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --statistics Maximum \
  --output table

# Find all burstable instances with low credit balance
aws ec2 describe-instances \
  --filters "Name=instance-type,Values=t3.*,t4g.*" \
  --query 'Reservations[].Instances[].{
    Id: InstanceId,
    Type: InstanceType,
    Name: Tags[?Key==`Name`].Value | [0]
  }' \
  --output table

M7i-flex: The Burstable Alternative

The M7i-flex instance type provides a middle ground between burstable T-instances and fixed M-instances. It offers a 5% discount compared to M7i with a 95% baseline CPU performance (vs. 100% for M7i). For workloads that rarely need 100% CPU, M7i-flex provides the stability of a general-purpose instance at a lower price point.

Graviton: AWS Custom Silicon

AWS Graviton processors are custom ARM-based chips designed by AWS for cloud workloads. Graviton instances offer the best price-performance for most workloads and are available across general purpose (M7g), compute optimized (C7g), memory optimized (R7g), and other families. AWS has progressively improved Graviton across three generations.

Graviton Migration Checklist

• Check application compatibility: Most Linux applications, containers, and managed runtimes (Python, Node.js, Java, .NET 6+) work on ARM64 without changes
• Build multi-arch container images: Use docker buildx build --platform linux/amd64,linux/arm64 to create images supporting both architectures
• Verify dependency availability: Check that all native binary dependencies have ARM64 builds. Most popular packages support ARM64.
• Test performance: Run benchmarks on Graviton before committing. Some workloads (particularly those using x86-specific SIMD instructions) may not see the full 40% improvement.
• Update AMIs and launch templates: Use ARM64 AMIs (Amazon Linux 2023 supports both architectures). Update Auto Scaling group launch templates.

# Build multi-architecture Docker image for Graviton
# Supports both x86_64 (amd64) and ARM64 architectures

# Create and use a new buildx builder
docker buildx create --name multiarch --driver docker-container --use

# Build and push multi-arch image to ECR
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag 123456789012.dkr.ecr.us-east-1.amazonaws.com/app:v1.0 \
  --push \
  .

# Verify the image supports both architectures
docker manifest inspect \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/app:v1.0 \
  | jq '.manifests[].platform'

Right-Sizing Your Instances

Most organizations run instances that are significantly over-provisioned. Studies consistently show that 30-40% of EC2 instances are oversized by at least one instance size. AWS Compute Optimizer analyzes 14 days of CloudWatch metrics and provides right-sizing recommendations that can reduce costs by 25-40% without impacting performance.

Right-Sizing Process

1. Collect metrics: Ensure the CloudWatch agent is installed and collecting memory utilization (not included by default). Wait for at least 14 days of data.
2. Run Compute Optimizer: Review recommendations, focusing on instances marked as “Over-provisioned”
3. Validate with P99 metrics: Look at the 99th percentile CPU and memory, not just averages. Size for peak with 20-30% headroom.
4. Resize incrementally: Drop one size at a time (e.g., xlarge to large). Monitor for 1-2 weeks before sizing down further.
5. Consider horizontal scaling: Instead of one large instance, use an Auto Scaling group with smaller instances for better availability and cost flexibility.

# Get Compute Optimizer recommendations for over-provisioned instances
aws compute-optimizer get-ec2-instance-recommendations \
  --filters "name=Finding,values=OVER_PROVISIONED" \
  --query 'instanceRecommendations[].{
    InstanceId: instanceArn,
    Current: currentInstanceType,
    Recommended: recommendationOptions[0].instanceType,
    MonthlySavings: recommendationOptions[0].savingsOpportunity.estimatedMonthlySavings.value
  }' \
  --output table

# Install and configure CloudWatch agent for memory metrics
# (Memory utilization is NOT collected by default)
cat > /opt/aws/amazon-cloudwatch-agent/etc/config.json << 'CWCONFIG'
{
  "metrics": {
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["used_percent"],
        "metrics_collection_interval": 300,
        "resources": ["*"]
      }
    },
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}",
      "InstanceType": "${aws:InstanceType}"
    }
  }
}
CWCONFIG

# Check 14-day CPU utilization statistics
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 86400 \
  --statistics Average Maximum p99 \
  --output table

Pricing Models

The instance type is only half the cost equation. The pricing model you choose determines your effective cost per hour. AWS offers four primary pricing models for EC2, each suited to different usage patterns.

Spot Instance Best Practices

Spot Instances provide the deepest discounts but can be interrupted with a 2-minute notice when AWS needs the capacity back. To use Spot effectively:

• Diversify across instance types: Request capacity from multiple instance types and families. Use capacity-optimized allocation strategy to choose the pool with the most available capacity.
• Use Auto Scaling groups with mixed instances: Combine On-Demand for your baseline with Spot for scaling capacity.
• Handle interruptions gracefully: Check the instance metadata service for the 2-minute interruption warning. Checkpoint work and deregister from load balancers.
• Use Spot for stateless workloads: Containers, batch jobs, CI/CD runners, and data processing are ideal. Stateful databases are not.

# Auto Scaling group with On-Demand base + Spot scaling
AutoScalingGroup:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    VPCZoneIdentifier:
      - !Ref PrivateSubnetA
      - !Ref PrivateSubnetB
    MixedInstancesPolicy:
      InstancesDistribution:
        # Minimum 2 On-Demand instances for baseline
        OnDemandBaseCapacity: 2
        # Scale above baseline with 70% Spot, 30% On-Demand
        OnDemandPercentageAboveBaseCapacity: 30
        # Choose Spot pools with most capacity (fewer interruptions)
        SpotAllocationStrategy: capacity-optimized
      LaunchTemplate:
        LaunchTemplateSpecification:
          LaunchTemplateId: !Ref LaunchTemplate
          Version: !GetAtt LaunchTemplate.LatestVersionNumber
        # Diversify across multiple instance types for Spot
        Overrides:
          - InstanceType: m7g.large
          - InstanceType: m6g.large
          - InstanceType: m7i.large
          - InstanceType: c7g.large
          - InstanceType: c6g.large
          - InstanceType: r7g.medium

Specialized Instance Types

Beyond the core families, AWS offers specialized instance types for specific workloads. These instances include custom hardware that provides significant performance advantages over general-purpose instances for their target use cases.

GPU Instances for ML and Graphics

Storage Optimized for Databases

I-family instances include high-performance local NVMe SSDs ideal for databases that benefit from low-latency local storage. The i4i instances provide up to 30 TB of NVMe storage with up to 5.5 million random read IOPS. Use these for self-managed databases like Cassandra, Elasticsearch, or ClickHouse that need high I/O performance.

Instance Selection Decision Framework

Use this systematic framework when selecting instance types for a new workload:

1. Step 1: Start with general purpose. Begin with an M-family instance (m7g.large is a good starting point) and benchmark your workload. Collect at least one week of metrics.
2. Step 2: Identify the bottleneck. Analyze whether you are CPU-bound (switch to C-family), memory-bound (switch to R-family), I/O-bound (switch to I-family), or GPU-bound (switch to G/P family).
3. Step 3: Choose the processor. Select Graviton (g suffix) unless x86 is specifically required. Test with both if unsure.
4. Step 4: Size with headroom. Start one size larger than your benchmark suggests, then right-size down based on production metrics after 2-4 weeks.
5. Step 5: Choose the pricing model. Use Savings Plans for steady-state capacity, Spot for fault-tolerant scaling, and On-Demand for unpredictable workloads.
6. Step 6: Implement auto-scaling. Use Auto Scaling groups with mixed instance types and purchase options for the most cost-effective and resilient configuration.