03 — EC2 & Compute

What is EC2?

Elastic Compute Cloud — virtual servers in AWS. Full control over OS, software, and networking.

Instance Types

Family	Optimized For	Example	Use Case
t (burstable)	General purpose	t3.micro, t3.medium	Dev, small apps, testing
m	General purpose	m6i.large	Web servers, app servers
c	Compute	c6i.xlarge	CPU-intensive, batch processing
r	Memory	r6i.large	Databases, in-memory caching
g/p	GPU	g4dn.xlarge, p4d	ML training, video encoding
i	Storage I/O	i3.large	High I/O databases

Instance name: m6i.large
                │││  └── Size (nano &lt; micro &lt; small &lt; medium &lt; large &lt; xlarge &lt; 2xlarge...)
                ││└── Generation (6th gen)
                │└── Processor (i = Intel, g = Graviton/ARM, a = AMD)
                └── Family (m = general purpose)

Purchasing Options

Option	Commitment	Savings	Interruption
On-Demand	None	0%	No
Reserved (1-3 yr)	Instance type + region	Up to 72%	No
Savings Plans	$/hr spend	Up to 72%	No
Spot	None	Up to 90%	Yes (2-min warning)
Dedicated Host	Physical server	Varies	No

Launch & Connect

# Launch instance
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --count 1 \
  --tag-specifications 'ResourceType=instance,Tags=[&#123;Key=Name,Value=my-server&#125;]'

# Connect via SSH
ssh -i my-key.pem ec2-user@&lt;public-ip&gt;

# Or use Session Manager (no SSH key needed)
aws ssm start-session --target i-0123456789abcdef0

Security Groups (Firewall)

# Inbound rules (who can reach your instance)
┌──────────┬──────────┬────────────────┐
│ Protocol │ Port     │ Source         │
├──────────┼──────────┼────────────────┤
│ SSH      │ 22       │ My IP only     │
│ HTTP     │ 80       │ 0.0.0.0/0     │
│ HTTPS    │ 443      │ 0.0.0.0/0     │
│ Custom   │ 3000     │ sg-frontend    │
└──────────┴──────────┴────────────────┘

# Security groups are STATEFUL:
# If inbound is allowed, response outbound is automatically allowed

User Data (Bootstrap Script)

Run scripts on first boot:

#!/bin/bash
yum update -y
yum install -y docker
systemctl start docker
systemctl enable docker
docker run -d -p 80:3000 my-app:latest

AMI (Amazon Machine Image)

Pre-configured OS snapshot to launch instances from.

# Create AMI from running instance
aws ec2 create-image \
  --instance-id i-0123456789abcdef0 \
  --name "my-app-v1.0" \
  --description "Node.js app with all deps"

# Launch from AMI
aws ec2 run-instances --image-id ami-my-custom-image ...

Auto Scaling

Auto Scaling Group:
  Min: 2     Desired: 3     Max: 10

  Scale Out (add instances):
    CPU &gt; 70% for 5 minutes

  Scale In (remove instances):
    CPU &lt; 30% for 10 minutes

┌─────┐ ┌─────┐ ┌─────┐          ┌─────┐ ┌─────┐
│ EC2 │ │ EC2 │ │ EC2 │  ──→     │ EC2 │ │ EC2 │ ... (up to 10)
│ AZ-a│ │ AZ-b│ │ AZ-c│  traffic │ AZ-a│ │ AZ-b│
└─────┘ └─────┘ └─────┘  spike   └─────┘ └─────┘

Elastic Load Balancer (ELB)

Type	Layer	Best For
ALB (Application)	Layer 7 (HTTP)	Web apps, path-based routing, microservices
NLB (Network)	Layer 4 (TCP/UDP)	Ultra-low latency, millions of requests
CLB (Classic)	Layer 4/7	Legacy (avoid for new)

Internet → ALB → Target Group → EC2 instances
                    │
                    ├── /api  → API target group
                    └── /     → Frontend target group

Key Takeaways

Choose instance types by workload: t3 for dev, m6i for production, c6i for compute-heavy
Use Spot for fault-tolerant workloads (up to 90% savings)
Security groups = firewall; stateful; allow only what's needed
Use User Data to bootstrap instances on launch
Auto Scaling + ALB for high availability and automatic scaling
Use Session Manager over SSH when possible (no key management)

02 — IAM & Security 04 — S3 & Storage