AWS cost optimization and FinOps workflows. Use this skill whenever the user mentions AWS costs, cloud spending, FinOps, Reserved Instances, Savings Plans, or cost reduction. Triggers include finding unused resources, analyzing the AWS bill, rightsizing EC2 or RDS instances, evaluating Spot instances, detecting cost anomalies, migrating to Graviton or newer instance generations, implementing tagging for cost allocation, setting up AWS Budgets, conducting monthly cost reviews, comparing RI vs Savings Plans, and optimizing storage, network, or database costs.
npx skills add https://github.com/ahmedasmar/devops-claude-skills --skill aws-cost-optimization
Systematic workflows for AWS cost optimization and financial operations management.
aws ec2 and aws ce CLI commands to identify unused resources and cost anomaliesaws compute-optimizer, aws cloudwatch, and aws ce for rightsizing, generation upgrades, Spot, and RI recommendationsFrequency: Run monthly (first week of each month)
Step 1: Find Unused Resources
# Find unattached EBS volumes
aws ec2 describe-volumes --filters Name=status,Values=available \
--query 'Volumes[].{ID:VolumeId,Size:Size,Created:CreateTime}' --output table
# Find unused Elastic IPs
aws ec2 describe-addresses --filters Name=domain,Values=vpc \
--query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocationId:AllocationId}' --output table
# Find idle EC2 instances (low CPU over 14 days)
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
--metric-name CPUUtilization --period 86400 --statistics Average \
--start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%S) --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--dimensions Name=InstanceId,Value=INSTANCE_ID
# Find old snapshots (>90 days)
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[?StartTime<=`2025-01-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' --output table
# Find unused load balancers (no healthy targets)
aws elbv2 describe-target-health --target-group-arn TARGET_GROUP_ARN
Step 2: Analyze Cost Anomalies
# Get daily costs for the past 30 days
aws ce get-cost-and-usage \
--time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
--granularity DAILY --metrics BlendedCost \
--group-by Type=DIMENSION,Key=SERVICE
# Get cost forecast for the next 30 days
aws ce get-cost-forecast \
--time-period Start=$(date -u +%Y-%m-%d),End=$(date -u -v+30d +%Y-%m-%d) \
--granularity MONTHLY --metric BLENDED_COST
# Compare month-over-month costs
aws ce get-cost-and-usage \
--time-period Start=$(date -u -v-60d +%Y-%m-01),End=$(date -u +%Y-%m-%d) \
--granularity MONTHLY --metrics BlendedCost
Step 3: Identify Rightsizing Opportunities
# Get Compute Optimizer rightsizing recommendations
aws compute-optimizer get-ec2-instance-recommendations \
--query 'instanceRecommendations[].{Instance:instanceArn,Finding:finding,Current:currentInstanceType,Recommended:recommendationOptions[0].instanceType}'
# Check CPU utilization for a specific instance (past 30 days)
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
--metric-name CPUUtilization --period 3600 --statistics Average Maximum \
--start-time $(date -u -v-30d +%Y-%m-%dT%H:%M:%S) --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--dimensions Name=InstanceId,Value=INSTANCE_ID
# Get RDS rightsizing recommendations
aws compute-optimizer get-ecs-service-recommendations 2>/dev/null || \
echo "Check RDS CPU/memory in CloudWatch manually"
Step 4: Generate Monthly Report
# Use the template to compile findings
cp assets/templates/monthly_cost_report.md reports/$(date +%Y-%m)-cost-report.md
# Fill in:
# - Findings from AWS CLI analysis
# - Action items
# - Team cost breakdowns
# - Optimization wins
Step 5: Team Review Meeting
When: Quarterly or when usage patterns stabilize
Step 1: Analyze Current Usage
# Get EC2 RI purchase recommendations
aws ce get-reservation-purchase-recommendation --service "Amazon Elastic Compute Cloud - Compute" \
--lookback-period-in-days SIXTY_DAYS --term-in-years ONE_YEAR --payment-option NO_UPFRONT
# Get RDS RI purchase recommendations
aws ce get-reservation-purchase-recommendation --service "Amazon Relational Database Service" \
--lookback-period-in-days SIXTY_DAYS --term-in-years ONE_YEAR --payment-option NO_UPFRONT
# Get Savings Plans recommendations
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP --lookback-period-in-days SIXTY_DAYS \
--term-in-years ONE_YEAR --payment-option NO_UPFRONT
Step 2: Review Recommendations
Evaluate each recommendation:
✅ Good candidate if:
- Running 24/7 for 60+ days
- Workload is stable and predictable
- No plans to change architecture
- Savings > 30%
❌ Poor candidate if:
- Workload is variable or experimental
- Architecture changes planned
- Instance type may change
- Dev/test environment
Step 3: Choose Commitment Type
Reserved Instances:
Savings Plans:
Decision Matrix:
Known instance type, won't change → Standard RI
May need to change types → Convertible RI or Compute SP
Variable workloads → Compute Savings Plan
Maximum flexibility → Compute Savings Plan
Step 4: Purchase and Track
Reference: See references/best_practices.md for detailed commitment strategies
When: During architecture reviews or optimization sprints
Step 1: Detect Old Instances
# Find old-generation instances (t2, m4, c4, r4, etc.)
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
--query 'Reservations[].Instances[?starts_with(InstanceType, `t2.`) || starts_with(InstanceType, `m4.`) || starts_with(InstanceType, `c4.`) || starts_with(InstanceType, `r4.`)].{ID:InstanceId,Type:InstanceType,Name:Tags[?Key==`Name`]|[0].Value}' \
--output table
# Find all running instance types to review generations
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
--query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,Name:Tags[?Key==`Name`]|[0].Value}' \
--output table
# Look for: t2→t3, m4→m6i, c4→c6i, r4→r6i, Intel→Graviton (20% savings)
Step 2: Prioritize Migrations
Quick Wins (Low Risk):
t2 → t3: Drop-in replacement, 10% savings
m4 → m5: Better performance, 5% savings
gp2 → gp3: No downtime, 20% savings
Medium Effort (Test Required):
x86 → Graviton (ARM64): 20% savings
- Requires ARM64 compatibility testing
- Most modern frameworks support ARM64
- Test in staging first
Step 3: Execute Migration
For EC2 (x86 to x86):
For Graviton Migration:
Step 4: Validate Savings
Reference: See references/best_practices.md → Compute Optimization
When: For fault-tolerant workloads or Auto Scaling Groups
Step 1: Identify Candidates
# Check current Spot pricing vs On-Demand for target instance types
aws ec2 describe-spot-price-history --instance-types m5.large m5.xlarge m6i.large \
--product-descriptions "Linux/UNIX" --start-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--query 'SpotPriceHistory[].{Type:InstanceType,AZ:AvailabilityZone,Price:SpotPrice}' --output table
# List Auto Scaling Groups (good Spot candidates)
aws autoscaling describe-auto-scaling-groups \
--query 'AutoScalingGroups[].{Name:AutoScalingGroupName,Min:MinSize,Max:MaxSize,Desired:DesiredCapacity}' --output table
# Check which ASGs already use mixed instances (Spot)
aws autoscaling describe-auto-scaling-groups \
--query 'AutoScalingGroups[?MixedInstancesPolicy!=null].AutoScalingGroupName'
Spot candidates: instances in ASGs, dev/test/staging environments, batch processing, CI/CD servers.
Step 2: Assess Suitability
Excellent for Spot:
NOT suitable for Spot:
Step 3: Implementation Strategy
Option 1: Fargate Spot -- Set capacityProviderStrategy with FARGATE_SPOT weight 70, FARGATE weight 30.
Option 2: EC2 Auto Scaling with Spot -- Use MixedInstancesPolicy with OnDemandBaseCapacity: 2, OnDemandPercentageAboveBaseCapacity: 30, SpotAllocationStrategy: capacity-optimized, and multiple instance type overrides (m5.large, m5a.large, m5n.large).
Option 3: EC2 Spot Fleet -- aws ec2 request-spot-fleet --spot-fleet-request-config file://spot-fleet.json
Step 4: Implement Interruption Handling -- Poll instance metadata at /latest/meta-data/spot/instance-action for the 2-minute termination notice. On notice: gracefully shutdown, save state, drain connections, exit.
Reference: See references/best_practices.md → Compute Optimization → Spot Instances
Use AWS CLI commands directly -- Claude Code can run aws ce, aws ec2, aws cloudwatch, and aws compute-optimizer commands to perform cost analysis.
Monthly review commands:
aws ec2 describe-volumes --filters Name=status,Values=available (unused volumes)aws ce get-cost-and-usage --granularity DAILY --metrics BlendedCost (cost trends)aws compute-optimizer get-ec2-instance-recommendations (rightsizing)Quarterly optimization commands:
aws ce get-reservation-purchase-recommendation --service EC2 (RI analysis)aws ec2 describe-instances with instance type filters (old generations)aws ec2 describe-spot-price-history (Spot pricing)Add --region REGION and --profile PROFILE to any AWS CLI command as needed.
Key Actions:
Reference: references/best_practices.md → Compute Optimization
Key Actions:
Reference: references/best_practices.md → Storage Optimization
Key Actions:
Reference: references/best_practices.md → Network Optimization
Key Actions:
Reference: references/best_practices.md → Database Optimization
Need help choosing between services?
Question: "Should I use EC2, Lambda, or Fargate?"
Answer: See references/service_alternatives.md → Compute Alternatives
Question: "Which S3 storage class should I use?"
Answer: See references/service_alternatives.md → Storage Alternatives
Question: "Should I use RDS or Aurora?"
Answer: See references/service_alternatives.md → Database Alternatives
Question: "NAT Gateway vs VPC Endpoint vs NAT Instance?"
Answer: See references/service_alternatives.md → Networking Alternatives
Three-phase rollout: (1) Foundation -- Enable Cost Explorer, set up Budgets, define tagging strategy. (2) Visibility -- Enforce tags, run AWS CLI cost analysis commands, set up monthly reviews. (3) Culture -- Cost metrics in engineering KPIs, architecture reviews, optimization sprints.
Full guide: references/finops_governance.md
Week 1: Data Collection
Week 2: Analysis
Week 3: Team Reviews
Week 4: Executive Reporting
Template: See assets/templates/monthly_cost_report.md
Detailed Process: See references/finops_governance.md → Monthly Review Process
aws ce get-cost-and-usage \
--time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
--granularity DAILY --metrics BlendedCost \
--group-by Type=DIMENSION,Key=SERVICE
Follow the optimization workflow:
Run RI analysis:
aws ce get-reservation-purchase-recommendation \
--service "Amazon Elastic Compute Cloud - Compute" \
--lookback-period-in-days SIXTY_DAYS --term-in-years ONE_YEAR --payment-option NO_UPFRONT
Look for:
Find unused resources:
aws ec2 describe-volumes --filters Name=status,Values=available --output table
aws ec2 describe-addresses --query 'Addresses[?AssociationId==null]' --output table
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[?StartTime<=`2025-01-01`]' --output table
Safe to delete (usually):
Always verify with resource owner before deletion!
References: references/best_practices.md | references/service_alternatives.md | references/finops_governance.md
Templates: assets/templates/monthly_cost_report.md
CLI Tools: Use AWS CLI commands directly -- Claude Code can run aws ce, aws ec2, aws cloudwatch, and aws compute-optimizer commands to perform cost analysis. No additional dependencies required.
Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.
Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.
Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).
Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).
Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).
This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
Take ahmedasmar/aws-cost-optimization from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.