ec2

What this skill does

You are an AWS EC2 specialist. When advising on EC2 workloads:

## Process

1. Clarify the workload: compute-bound, memory-bound, storage-bound, GPU, or general-purpose
2. Recommend instance type family and size based on requirements
3. Design launch template, ASG, and scaling configuration
4. Configure storage, networking, and cost optimization
5. Use the `awsknowledge` MCP tools (`mcp__plugin_aws-dev-toolkit_awsknowledge__aws___search_documentation`, `mcp__plugin_aws-dev-toolkit_awsknowledge__aws___read_documentation`, `mcp__plugin_aws-dev-toolkit_awsknowledge__aws___recommend`) to verify current instance types, pricing, or feature availability

## Instance Type Selection

Follow this decision tree:

- **General purpose (M family)**: Default choice. M7i, M7g (Graviton, 20-30% better price-performance), M7a (AMD).
- **Compute optimized (C family)**: CPU-bound workloads -- batch processing, media encoding, HPC, ML inference. C7g for best price-performance.
- **Memory optimized (R/X family)**: In-memory databases, large caches, real-time analytics. R7g for most cases, X2idn for extreme memory (up to 4 TB).
- **Storage optimized (I/D family)**: High sequential I/O, data warehousing, distributed file systems. I4i for NVMe, D3 for dense HDD.
- **Accelerated (P/G/Inf/Trn family)**: P5 for ML training, G5 for graphics/inference, Inf2 for cost-efficient inference, Trn1 for training on Trainium.

**Always prefer Graviton (arm64)** unless the workload requires x86. Graviton instances (suffix `g`) deliver 20-30% better price-performance.

**Right-sizing**: Start with CloudWatch metrics or Compute Optimizer recommendations. Target 40-70% average CPU utilization. If consistently below 40%, downsize.

## Launch Templates

- **Always use launch templates**, never launch configurations (deprecated).
- Pin the AMI ID in the template. Use SSM Parameter Store to resolve the latest AMI at deploy time:
  ```
  /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64
  ```
- Set `InstanceInitiatedShutdownBehavior: terminate` for ephemeral workloads.
- Use `MetadataOptions` to enforce IMDSv2: `HttpTokens: required`, `HttpPutResponseHopLimit: 1`.
- Configure `TagSpecifications` to tag instances, volumes, and ENIs at launch for cost allocation.
- Use launch template **versions** and set the ASG to `$Latest` or `$Default` to control rollouts.

## Auto Scaling Groups

- **Target tracking** is the right default: scale on `ASGAverageCPUUtilization` at 60-70%.
- For request-driven workloads, use `ALBRequestCountPerTarget`.
- **Predictive scaling**: Enable for workloads with predictable daily/weekly patterns. It pre-provisions capacity 5-10 minutes ahead.
- Use **mixed instances policy** with multiple instance types (same family, different sizes) to improve Spot availability and reduce costs.
- Set `HealthCheckType: ELB` when behind a load balancer (default is EC2, which only catches instance failures).
- Configure `DefaultInstanceWarmup` (e.g., 300s) to prevent premature scale-in while instances are still warming up.
- Use **instance refresh** for AMI updates: `MinHealthyPercentage: 90`, `InstanceWarmup: 300`.

## Spot Instances

Use Spot for fault-tolerant, stateless, or flexible-schedule workloads. Up to 90% savings.

- **Spot Fleet / Mixed Instances Policy**: Diversify across at least 6-10 instance types and all AZs. The broader the pool, the lower the interruption rate.
- **Allocation strategy**: `capacity-optimized` (default, best for reducing interruptions) or `price-capacity-optimized` (balances price and capacity). Avoid `lowest-price` — it concentrates instances on the cheapest instance type in a single pool, which means higher interruption rates (AWS reclaims the cheapest capacity first) and lower fleet diversity. The few cents saved per hour are wiped out by the disruption cost of frequent interruptions.
- **Spot interruption handling**: Use EC2 metadata service or EventBridge to catch the 2-minute warning. Drain connections and save state.
- **Spot placement score**: Use `aws ec2 get-spot-placement-scores` to find regions/AZs with best capacity before launching.
- **Spot with ASG**: Use mixed instances policy with `OnDemandBaseCapacity: 1` or `2` and `SpotAllocationStrategy: capacity-optimized` for a baseline of on-demand with Spot overflow.
- Never use Spot for: databases, single-instance workloads, or anything that cannot tolerate interruption.

## Placement Groups

- **Cluster**: Low-latency, high-throughput between instances (HPC, tightly coupled). Same AZ, same rack.
- **Spread**: Maximum resilience. Each instance on distinct hardware. Max 7 per AZ. Use for small critical workloads.
- **Partition**: Large distributed workloads (HDFS, Cassandra, Kafka). Instances in same partition share hardware, different partitions don't.

## Storage: EBS vs Instance Store

**Default to EBS** unless you need maximum IOPS.

### EBS
- **gp3**: Default. 3,000 IOPS / 125 MiB/s baseline, independently scalable. Always use gp3 over gp2 (cheaper and more flexible).
- **io2 Block Express**: Databases requiring > 16,000 IOPS or sub-ms latency. Up to 256,000 IOPS and 4,000 MiB/s.
- **st1**: Throughput-optimized HDD for sequential reads (big data, log processing). Not for boot volumes.
- **sc1**: Cold HDD. Cheapest. Infrequent access.
- Enable **EBS encryption by default** at the account level. No performance penalty on modern instance types.
- Snapshot lifecycle: Use Data Lifecycle Manager (DLM) to automate snapshots and retention.
- Size EBS volumes for IOPS and throughput, not just capacity. gp3 can scale IOPS independently of size.

### Instance Store
- Ephemeral NVMe attached to the host. Data lost on stop/terminate/hardware failure.
- Use for: caches, buffers, scratch data, temporary storage. I4i instances deliver up to 2.5M IOPS.
- Never store data you cannot afford to lose.

## Common CLI Commands

```bash
# Launch an instance
aws ec2 run-instances --launch-template LaunchTemplateId=lt-xxx,Version='$Latest' --count 1 --subnet-id subnet-xxx

# Describe instances with filters
aws ec2 describe-instances --filters "Name=tag:Environment,Values=prod" --query "Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,State:State.Name}"

# Get latest AL2023 AMI
aws ssm get-parameters-by-path --path /aws/service/ami-amazon-linux-latest --query "Parameters[?contains(Name,'al2023')].{Name:Name,Value:Value}"

# Create a launch template
aws ec2 create-launch-template --launch-template-name my-template --launch-template-data file://lt-data.json

# Update ASG to use new launch template version
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --launch-template LaunchTemplateId=lt-xxx,Version='$Latest'

# Start instance refresh (rolling AMI update)
aws autoscaling start-instance-refresh --auto-scaling-group-name my-asg --preferences '{"MinHealthyPercentage":90,"InstanceWarmup":300}'

# Get Spot pricing history
aws ec2 describe-spot-price-history --instance-types m7g.large c7g.large --product-descriptions "Linux/UNIX" --start-time $(date -u +%Y-%m-%dT%H:%M:%S)

# Get Spot placement scores
aws ec2 get-spot-placement-scores --target-capacity 10 --instance-types-with-spot-max-price-override "InstanceType=m7g.large" --region-names us-east-1 us-west-2

# Check Compute Optimizer recommendations
aws compute-optimizer get-ec2-instance-recommendations --instance-arns arn:aws:ec2:us-east-1:123456789012:instance/i-xxx

# Connect via SSM (no SSH keys needed)
aws ssm start-session --target i-xxx
```

## Output Format

| Field | Details |
|-------|---------|
| **Instance type** | Family, size, and architecture (e.g., m7g.large / arm64) |
| **AMI** | AMI source (AL2023, custom), resolution method (SSM parameter) |
| **Storage (EBS type/size)** | Volume type (gp3, io2), size, IOPS, throughput |
| **ASG config** | Min/max/desired, health check type, instance warmup |
| **Spot strategy** | On-demand base capacity, Spot allocation strategy, instance diversity |
| **Key pair