TECH **AWS EC2 Instance Types & Purchasing Options: Zero-Fluff, Hands-On Guide**

AWS EC2 Instance Types & Purchasing Options: Zero-Fluff, Hands-On Guide

(For AWS Solutions Architect – Associate & Real-World Deployments)

1. What This Is & Why It Matters

You’re a cloud engineer at a startup. Your CTO just handed you a $50K/month AWS bill and said, “Cut costs by 40% without breaking anything.” Or worse: Your production app crashes every night because the database runs on an undersized instance, and your boss blames “the cloud.”

This guide is your survival kit.
- EC2 Instance Types = The “hardware” of your virtual servers (CPU, RAM, storage, networking).
- Purchasing Options = How you pay for them (On-Demand, Reserved, Spot, Savings Plans).

Why this matters in production:
- Wrong instance type? Your app slows to a crawl (or costs 10x more than needed).
- Wrong purchasing option? You either overpay (On-Demand for steady workloads) or lose data (Spot Instances for critical jobs).
- Ignoring this? You’ll fail the AWS SAA exam (20% of questions test this) and waste thousands in real-world deployments.

Real-world scenario:
You inherit a legacy monolith running on t3.micro instances. It’s slow, unreliable, and costs $1,200/month. Your mission: 1. Right-size the instances (pick the right type).
2. Cut costs (switch to Reserved Instances or Savings Plans).
3. Ensure uptime (avoid Spot for critical workloads).

By the end of this guide, you’ll know exactly how to do this—with CLI commands, cost calculations, and best practices.

2. Core Concepts & Components

? EC2 Instance Types

? Production Trap:
- Burstable instances (t3, t4g) are not for steady workloads—they’ll throttle after CPU credits run out.
- m6i vs. m6g: m6g (Graviton2) is 20% cheaper but only works with ARM-compatible apps (e.g., Node.js, Python, Java).

? EC2 Purchasing Options

? Production Trap:
- Reserved Instances (RIs) vs. Savings Plans:
- RIs = 1 instance type, 1 region, 1 OS (e.g., m6i.large in us-east-1 with Linux).
- Savings Plans = Any instance type, any region, any OS (e.g., c6i.xlarge in eu-west-1 with Windows).
- Always prefer Savings Plans unless you know exactly what you’ll run for 3 years.

3. Step-by-Step Hands-On: Right-Size & Optimize Costs

Prerequisites

✅ AWS account with IAM admin permissions.
✅ AWS CLI installed (aws configure set up).
✅ Basic familiarity with ssh and EC2.

Step 1: Identify Your Current Workload

Goal: Find the right instance type for your app.

Option A: Use AWS Compute Optimizer (Recommended)

# Enable Compute Optimizer (one-time setup)
aws compute-optimizer update-enrollment-status --status Active

# Wait 12-24 hours for data collection, then check recommendations
aws compute-optimizer get-ec2-instance-recommendations

Expected Output:

{
  "instanceRecommendations": [
    {
      "instanceArn": "arn:aws:ec2:us-east-1:123456789012:instance/i-0abcdef1234567890",
      "currentInstanceType": "t3.micro",
      "recommendations": [
        {
          "instanceType": "m6i.large",
          "rank": 1,
          "savingsOpportunity": {
            "savingsOpportunityPercentage": 30.0,
            "estimatedMonthlySavingsAmount": 45.67,
            "currency": "USD"
          }
        }
      ]
    }
  ]
}

? What this means:
- Your t3.micro is underpowered—AWS recommends m6i.large (30% cheaper for the same performance).

Option B: Manual Analysis (If Compute Optimizer Isn’t Available)

# Get CPU utilization for an instance (last 7 days)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --start-time $(date -u -v-7d +"%Y-%m-%dT%H:%M:%SZ") \
  --end-time $(date -u +"%Y-%m-%dT%H:%M:%SZ") \
  --period 3600 \
  --statistics Average \
  --region us-east-1

? How to interpret:
- CPU < 30%: Over-provisioned (downsize).
- CPU > 70%: Under-provisioned (upsize).
- Memory: Use free -m (Linux) or Task Manager (Windows) to check.

Step 2: Pick the Right Instance Type

Scenario: Your app is a Python Flask API with: - 100 concurrent users (moderate traffic).
- PostgreSQL database (moderate memory usage).
- No GPU/ML workloads.

Recommended Instance Type: m6i.large (General Purpose, 2 vCPUs, 8 GiB RAM).
Why?
- t3 is burstable → Bad for steady workloads.
- c6i is compute-optimized → Overkill for a web app.
- r6i is memory-optimized → Too expensive for this use case.

CLI Command to Launch:

aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \  # Amazon Linux 2 (us-east-1)
  --instance-type m6i.large \
  --key-name MyKeyPair \
  --security-group-ids sg-0abcdef1234567890 \
  --subnet-id subnet-0abcdef1234567890 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=Flask-API}]'

Step 3: Optimize Costs with Purchasing Options

Goal: Reduce costs without sacrificing reliability.

Option A: Savings Plans (Best for Most Workloads)

# Check current Savings Plans recommendations
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type Compute \
  --lookback-period ONE_MONTH \
  --payment-option AllUpfront

Expected Output:

{
  "SavingsPlansPurchaseRecommendation": {
    "AccountScope": "PAYER",
    "SavingsPlansType": "Compute",
    "TermInYears": "1",
    "PaymentOption": "AllUpfront",
    "SavingsPlansDetails": [
      {
        "SavingsPlansArn": "arn:aws:savingsplans::123456789012:savingsplan/12345678-1234-1234-1234-123456789012",
        "SavingsPlansId": "12345678-1234-1234-1234-123456789012",
        "UpfrontPaymentAmount": "1200.00",
        "RecurringPaymentAmount": "0.00",
        "HourlyCommitment": "0.12",
        "EstimatedMonthlySavingsAmount": "350.00",
        "EstimatedOnDemandCost": "500.00",
        "EstimatedSavingsPercentage": "70.0"
      }
    ]
  }
}

? What this means:
- Commit to $0.12/hour for 1 year → 70% savings vs. On-Demand.
- No instance type lock-in (unlike Reserved Instances).

CLI Command to Purchase:

aws savingsplans create-savings-plan \
  --savings-plan-offering-id 12345678-1234-1234-1234-123456789012 \
  --commitment 0.12 \
  --upfront-payment-amount 1200.00 \
  --term 1y

Option B: Reserved Instances (If You Know Exactly What You Need)

# Check RI recommendations
aws ec2 describe-reserved-instances-offerings \
  --instance-type m6i.large \
  --product-description "Linux/UNIX" \
  --offering-class standard \
  --offering-type "All Upfront" \
  --duration 31536000  # 1 year in seconds

Expected Output:

{
  "ReservedInstancesOfferings": [
    {
      "ReservedInstancesOfferingId": "12345678-1234-1234-1234-123456789012",
      "InstanceType": "m6i.large",
      "FixedPrice": 1200.0,
      "UsagePrice": 0.0,
      "RecurringCharges": [],
      "Duration": 31536000,
      "OfferingType": "All Upfront"
    }
  ]
}

? What this means:
- Pay $1,200 upfront → 72% savings vs. On-Demand.
- But: You’re locked into m6i.large in us-east-1 for 1 year.

CLI Command to Purchase:

aws ec2 purchase-reserved-instances-offering \
  --reserved-instances-offering-id 12345678-1234-1234-1234-123456789012 \
  --instance-count 1

Option C: Spot Instances (For Fault-Tolerant Workloads)

# Launch a Spot Instance (with a max price of $0.05/hour)
aws ec2 request-spot-instances \
  --spot-price "0.05" \
  --instance-count 1 \
  --type "one-time" \
  --launch-specification '{
    "ImageId": "ami-0c55b159cbfafe1f0",
    "InstanceType": "m6i.large",
    "KeyName": "MyKeyPair",
    "SecurityGroupIds": ["sg-0abcdef1234567890"],
    "SubnetId": "subnet-0abcdef1234567890"
  }'

⚠️ Warning:
- AWS can terminate this instance with 2-minute notice.
- Only use for:
- Batch jobs (e.g., data processing).
- CI/CD pipelines.
- Stateless apps (e.g., worker nodes).

4. ? Production-Ready Best Practices

? Security

• Least Privilege IAM Roles: Never use AdministratorAccess for EC2. Use AmazonEC2RoleforSSM for SSM access.
• Security Groups: Restrict SSH/RDP to your IP only (or a bastion host).
• Encryption: Always enable EBS encryption (default in most regions).
• Patch Management: Use AWS Systems Manager (SSM) Patch Manager to auto-patch instances.

? Cost Optimization

• Right-Size First: Use AWS Compute Optimizer before buying RIs/Savings Plans.
• Savings Plans > Reserved Instances: More flexible, same savings.
• Spot for Fault-Tolerant Workloads: Use Spot Fleet for auto-scaling.
• Terminate Unused Instances: Use AWS Instance Scheduler to stop dev instances at night.

⚙️ Reliability & Maintainability

• Tag Everything: Name, Environment, Owner, Project.
• Immutable Infrastructure: Use AMIs + Auto Scaling (never modify running instances).
• Backup EBS Volumes: Enable EBS Snapshots (lifecycle policy: 7 daily, 4 weekly, 12 monthly).
• Monitor CPU Credits (for t3/t4g): Set CloudWatch alarms for CPUCreditBalance < 100.

? Observability

• CloudWatch Alarms:
• CPUUtilization > 80% for 5 minutes → Trigger Auto Scaling.
• StatusCheckFailed_Instance → Reboot instance.
• AWS Cost Explorer: Set up budget alerts (e.g., “Alert me if EC2 costs > $1,000/month”).
• AWS Trusted Advisor: Check for underutilized instances (CPU < 10% for 14 days).

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (AWS SAA)

? Typical Question Patterns

1. “Which instance type for a memory-heavy database?”
2. ✅ r6i (Memory Optimized).

3. ❌ c6i (Compute Optimized).

4. “Best purchasing option for a 24/7 web server?”

5. ✅ Savings Plans (flexible, 72% savings).

6. ❌ Spot Instances (can terminate).

7. “How to reduce costs for a batch job that can fail?”

8. ✅ Spot Instances (90% discount).

9. ❌ On-Demand (most expensive).

10. “Which is more flexible: RIs or Savings Plans?”

11. ✅ Savings Plans (applies across instance types/regions).
12. ❌ RIs (locked to 1 instance type/region).

⚠️ Key Distinctions