
Ec2
- 3 installs
- 12 repo stars
- Updated June 8, 2026
- aws-samples/sample-claude-code-plugins-for-startups
ec2 is a Claude Code skill that designs, configures, and optimizes Amazon EC2 workloads, including instance selection, auto-scaling, and Spot.
About
This skill gives Claude Code EC2 specialist guidance for designing, configuring and optimizing compute workloads. It covers instance-type selection, launch templates, Auto Scaling Groups, Spot instances, storage and placement groups. A developer uses it when picking instance types, setting up auto-scaling or optimizing EC2 cost.
- Instance-type decision tree with Graviton price-performance guidance
- Launch templates, Auto Scaling Groups and predictive scaling
- Spot allocation strategies and placement groups
Ec2 by the numbers
- 3 all-time installs (skills.sh)
- Ranked #892 of 1,039 Cloud & Infrastructure skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
ec2 capabilities & compatibility
Free skill; EC2 instances, EBS and data transfer incur AWS usage costs.
- Capabilities
- ec2 · ecs · eks · cost check
- Works with
- aws
- Use cases
- devops
- Pricing
- Free
What ec2 says it does
You are an AWS EC2 specialist. When advising on EC2 workloads:
**Always prefer Graviton (arm64)** unless the workload requires x86. Graviton instances (suffix `g`) deliver 20-30% better price-performance.
**Always use launch templates**, never launch configurations (deprecated).
npx skills add https://github.com/aws-samples/sample-claude-code-plugins-for-startups --skill ec2Add your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 3 |
|---|---|
| repo stars | ★ 12 |
| Last updated | June 8, 2026 |
| Repository | aws-samples/sample-claude-code-plugins-for-startups ↗ |
What it does
Select EC2 instance types and configure launch templates, auto-scaling and Spot for a compute workload.
Who is it for?
Choosing EC2 instance types and configuring launch templates, ASGs and Spot for a workload.
Skip if: Serverless or container-only workloads that never provision EC2 instances directly.
When should I use this skill?
Selecting instance types, configuring auto-scaling groups, working with launch templates, managing Spot instances, choosing EBS vs instance store, or troubleshooting EC2.
What you get
An instance-type, launch-template and auto-scaling plan tuned for cost and reliability.
- Instance-type recommendation
- Launch template
- Auto Scaling Group config
By the numbers
- 5-step process
- Target 40-70% average CPU utilization
- Spot up to 90% savings
Files
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: terminatefor ephemeral workloads. - Use
MetadataOptionsto enforce IMDSv2:HttpTokens: required,HttpPutResponseHopLimit: 1. - Configure
TagSpecificationsto tag instances, volumes, and ENIs at launch for cost allocation. - Use launch template versions and set the ASG to
$Latestor$Defaultto control rollouts.
Auto Scaling Groups
- Target tracking is the right default: scale on
ASGAverageCPUUtilizationat 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: ELBwhen 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) orprice-capacity-optimized(balances price and capacity). Avoidlowest-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-scoresto find regions/AZs with best capacity before launching. - Spot with ASG: Use mixed instances policy with
OnDemandBaseCapacity: 1or2andSpotAllocationStrategy: capacity-optimizedfor 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
# 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-xxxOutput 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 / SSM | SSM Session Manager (preferred) or key pair for access |
| Security group | Inbound/outbound rules, referenced SG IDs |
| Monitoring | CloudWatch agent config, detailed monitoring, custom metrics |
Related Skills
networking— VPC, subnets, security groups, and NAT strategy for EC2 instancesiam— Instance profiles, least-privilege policies, and SSM permissionss3— Storage integration, instance backups, and bootstrap scriptsobservability— CloudWatch agent, alarms, dashboards, and Compute Optimizercloudfront— CDN in front of EC2-backed web applications
Anti-Patterns
- Using SSH keys: Use SSM Session Manager instead. No need to manage key pairs, open port 22, or maintain bastion hosts. SSM provides audit logging and IAM-based access control.
- IMDSv1 still enabled: Enforce IMDSv2 (
HttpTokens: required) in launch templates. IMDSv1 is vulnerable to SSRF attacks that can steal instance credentials. - Manually launching instances: Everything should go through launch templates and ASGs, even "temporary" instances. Manual instances become untracked snowflakes.
- Single instance type in ASG: Use mixed instances policy with 3+ instance types from the same family. This improves Spot availability and on-demand capacity during shortages.
- gp2 volumes: gp2 ties IOPS to volume size. gp3 is cheaper, with independently configurable IOPS and throughput. Migrate all gp2 volumes to gp3.
- Oversized instances: Running m5.4xlarge at 5% CPU because "we might need it." Use Compute Optimizer, right-size, and scale horizontally instead.
- No EBS encryption: Enable default encryption at the account level. There is no performance penalty on current generation instances and it satisfies most compliance requirements.
- Using public IPs when not needed: Place instances in private subnets behind a load balancer or NAT Gateway. Use VPC endpoints for AWS service access.
- Ignoring Graviton: Arm64 (Graviton) instances are 20-30% better price-performance for most workloads. Test compatibility and migrate -- most Linux workloads run without changes.
Related skills
FAQ
Should I use Graviton instances?
Always prefer Graviton (arm64) unless the workload requires x86; they deliver 20-30% better price-performance.
Which Spot allocation strategy is best?
Use capacity-optimized or price-capacity-optimized and avoid lowest-price, which concentrates instances and raises interruption rates.