本文へ移動
cccskills
無料GitHub で公開

aws-rightsizing

Use when working with Aws Rightsizing — analyze EC2, RDS, EBS, and Lambda resource utilization to identify right-sizing opportunities. Uses CloudWatch metrics with anti-hallucination rules for burstable instances, memory metrics, peak vs average analysis, and estimated monthly savings calculations.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md10.8 KB
  • scripts/get_rightsizing_aws.sh25.9 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

AWS Rightsizing Skill

Analyze resource utilization and identify right-sizing opportunities with anti-hallucination guardrails and reusable CloudWatch functions.

Relationship to other AWS skills:

  • aws-rightsizing/ -> "What to resize" (anti-hallucination rules, utilization thresholds, savings estimates)
  • aws/ -> "How to execute" (parallel patterns, CloudWatch statistics syntax, throttling)
  • aws-pricing/ -> "How much things cost" (on-demand pricing via get_aws_cost)
  • aws-billing/ -> "Current spend" (billing context, discount detection)

CRITICAL: Rightsizing Rules (Anti-Hallucination)

These rules are MANDATORY when analyzing resource utilization. Violating them produces incorrect recommendations that can cause outages.

Rule 1: Minimum 14-Day Observation Window

Short observation windows miss weekly patterns (batch jobs, weekend traffic, month-end spikes). Default --days 14, allow up to 90.

WRONG:  --days 3   -> Misses weekend batch jobs
WRONG:  --days 1   -> Captures only one day's pattern
CORRECT: --days 14 -> Captures at least 2 full weekly cycles

The _rs_parse_days helper enforces the 14-90 day range.

Rule 2: Burstable Instances (t-family) Need Credit Balance

A t3.micro at 5% avg CPU may be fine OR may be throttled with 0 credits. A burstable instance running out of CPU credits is effectively capped at baseline performance, causing latency spikes.

MANDATORY: For any t-family instance (t2, t3, t3a, t4g), always check CPUCreditBalance. If credit balance trends toward 0, the instance is NOT underutilized -- it is credit-starved and may need upsizing.

WRONG:  t3.micro avg CPU 5% -> "underutilized, downsize"
CORRECT: t3.micro avg CPU 5%, credit balance 0 -> "credit-starved, consider upsizing"
CORRECT: t3.micro avg CPU 5%, credit balance 144 -> "underutilized, downsize candidate"

Rule 3: Memory Metrics Require CloudWatch Agent

mem_used_percent is NOT available by default in CloudWatch. It requires the CloudWatch Agent (CWAgent namespace) to be installed and configured on the instance.

MANDATORY: If CWAgent namespace returns no data, report "memory data unavailable" -- do NOT assume memory is fine.

WRONG:  No memory data -> "memory is fine"
CORRECT: No memory data -> "memory data unavailable (CWAgent not installed)"

Rule 4: Peak vs Average -- Never Downsize on Average Alone

An instance with avg CPU 10% but max CPU 95% is a bursty workload. Downsizing would cause failures during peaks.

MANDATORY: Report BOTH Average AND Maximum statistics. Only flag for downsizing if max < threshold too.

WRONG:  avg CPU 10% -> "downsize"
CORRECT: avg CPU 10%, max CPU 22% -> "downsize candidate (both avg and max are low)"
CORRECT: avg CPU 10%, max CPU 95% -> "bursty workload, do NOT downsize"

Rule 5: Savings Estimates Use On-Demand Pricing Only

If the instance has RI/SP coverage, actual savings differ from on-demand-based estimates. Always caveat estimates.

WRONG:  "You will save $70/mo by downsizing"
CORRECT: "Estimated savings: $70/mo (based on on-demand rates; actual savings may differ if RI/SP coverage applies)"

Rule 6: Multi-AZ RDS Doubles Compute Cost

A db.r5.large Multi-AZ costs ~$365/mo, not ~$182/mo. The standby replica incurs the same compute charge.

MANDATORY: Check MultiAZ flag before estimating RDS costs.

WRONG:  db.r5.large -> $182/mo
CORRECT: db.r5.large, MultiAZ=true -> $365/mo
CORRECT: db.r5.large, MultiAZ=false -> $182/mo

Rule 7: GP2 vs GP3 Baseline IOPS

GP2 baseline IOPS = max(100, 3 x GB). GP3 baseline = 3000 IOPS at lower cost per GB.

A 100GB GP2 has 300 IOPS baseline. GP3 gives 3000 IOPS at $0.08/GB vs $0.10/GB. Always calculate both when evaluating EBS rightsizing.

WRONG:  "GP2 and GP3 have similar performance"
CORRECT: "100GB GP2: 300 IOPS baseline at $10/mo. 100GB GP3: 3000 IOPS baseline at $8/mo (10x IOPS, 20% cheaper)"

Rule 8: Lambda Memory Controls CPU Allocation

Reducing Lambda memory from 1GB to 256MB also cuts CPU by 4x. Duration may increase, negating savings. Check duration trend before recommending memory reduction.

WRONG:  "Lambda uses 200MB of 1GB, reduce to 256MB"
CORRECT: "Lambda uses 200MB of 1GB. Check duration: if avg duration is near timeout, reducing memory will increase duration and may increase cost."

Mandatory Pre-Analysis Checklist

Before writing ANY rightsizing analysis, verify ALL of the following:

  • Observation window >= 14 days (see Rule 1)
  • Burstable instances (t-family) checked for CPUCreditBalance (see Rule 2)
  • Memory metrics checked via CWAgent namespace with graceful fallback if unavailable (see Rule 3)
  • Both Average AND Maximum statistics reported for all metrics (see Rule 4)
  • Savings caveated as "based on on-demand rates" (see Rule 5)
  • Multi-AZ flag checked for RDS instances (see Rule 6)
  • All cost figures include currency unit (USD)
  • Parallel execution used for all CloudWatch queries (see aws/SKILL.md)

Rightsizing Script (get_rightsizing_aws.sh)

DO NOT read or modify the script file. Only source and call the functions.

SETUP (at the start of your script):

source ./_skills/connections/aws/aws-rightsizing/scripts/get_rightsizing_aws.sh

All functions enforce anti-hallucination rules: 14-day minimum window, parallel CloudWatch queries, TOON output format.

FUNCTION REFERENCE:

FunctionPurposeSignature
aws_rightsizing_ec2EC2 CPU + optional memory analysis, flag under/over-utilized[--days N] [--region REGION]
aws_rightsizing_ec2_savingsEstimate savings for flagged EC2 instances[--days N] [--region REGION]
aws_rightsizing_rdsRDS CPU, connections, storage utilization[--days N] [--region REGION]
aws_rightsizing_rds_savingsEstimate savings for flagged RDS instances[--days N] [--region REGION]
aws_rightsizing_ebsEBS IOPS/throughput utilization, GP2->GP3 candidates[--days N] [--region REGION]
aws_rightsizing_lambdaLambda memory/duration/invocation analysis[--days N] [--region REGION]
aws_rightsizing_summaryRun all checks, output unified summary[--days N] [--region REGION]

RECOMMENDED WORKFLOW (every rightsizing analysis):

  1. Always run aws_rightsizing_ec2 first -- EC2 is typically the largest compute cost
  2. Run aws_rightsizing_rds for database layer analysis
  3. Run aws_rightsizing_ebs for storage optimization (especially GP2->GP3 migration)
  4. Run aws_rightsizing_lambda if Lambda is a significant cost driver
  5. Or run aws_rightsizing_summary for a unified view across all resource types
  6. For savings estimates, run aws_rightsizing_ec2_savings and aws_rightsizing_rds_savings

Examples:

source ./_skills/connections/aws/aws-rightsizing/scripts/get_rightsizing_aws.sh

# EC2 utilization analysis (14-day default)
aws_rightsizing_ec2

# EC2 analysis with 30-day window in specific region
aws_rightsizing_ec2 --days 30 --region us-west-2

# EC2 savings estimates
aws_rightsizing_ec2_savings --days 30

# RDS utilization
aws_rightsizing_rds --days 14

# RDS savings estimates
aws_rightsizing_rds_savings --days 14

# EBS rightsizing (GP2->GP3 candidates)
aws_rightsizing_ebs --days 14

# Lambda memory/duration analysis
aws_rightsizing_lambda --days 14

# Full summary across all resource types
aws_rightsizing_summary --days 30 --region us-east-1

EC2 Instance Family Quick Reference

Approximate monthly on-demand costs in USD (us-east-1). Use to validate savings estimates.

FamilySizevCPUMemory~Monthly USD
t3micro21 GB$8
t3small22 GB$15
t3medium24 GB$30
t3large28 GB$61
m5large28 GB$70
m5xlarge416 GB$140
m52xlarge832 GB$281
c5large24 GB$62
c5xlarge48 GB$124
c52xlarge816 GB$248
r5large216 GB$91
r5xlarge432 GB$182

Downsizing savings: Moving one size down within a family typically saves ~50% (e.g., m5.xlarge $140 -> m5.large $70 = $70/mo savings).

For instance types or RDS pricing not listed above, use get_aws_cost from the aws-pricing/ skill.


Common Errors

ErrorCauseSolution
InvalidParameterCombination for CloudWatchWrong statistics syntaxUse spaces not commas: --statistics Average Maximum
No data for mem_used_percentCWAgent not installedReport "memory data unavailable", don't assume
CPUCreditBalance returns no dataNot a burstable instanceOnly query for t-family instances
Savings estimate seems too highMulti-AZ RDS not accounted forCheck MultiAZ flag, double cost if true
InvalidParameterValue for periodPeriod too small for date rangeUse 3600 (1hr) for <= 15 days, 86400 (1day) for > 15 days

Output Format

Present results as a structured report:

Aws Rightsizing Report
══════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Counter-Rationalizations

ShortcutCounterWhy
"I'll skip discovery and check known resources"Always run Phase 1 discovery firstResource names change, new resources appear — assumed names cause errors
"The user only asked for a quick check"Follow the full discovery → analysis flowQuick checks miss critical issues; structured analysis catches silent failures
"Default configuration is probably fine"Audit configuration explicitlyDefaults often leave logging, security, and optimization features disabled
"Metrics aren't needed for this"Always check relevant metrics when availableAPI/CLI responses show current state; metrics reveal trends and intermittent issues
"I don't have access to that"Try the command and report the actual errorAssumed permission failures prevent useful investigation; actual errors are informative

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Cloudflare GraphQL Analytics for zone traffic, firewall events, Workers metrics, and schema exploration. Use when querying Cloudflare analytics data or exploring the GraphQL API.

日本語の概要は準備中です。原文の説明を表示しています。

cloudthinker-ai/CloudSkills62026年4月5日 更新

Use when working with Alloydb — google AlloyDB instance analysis, query insights, columnar engine optimization, maintenance windows, and cluster health.

日本語の概要は準備中です。原文の説明を表示しています。

cloudthinker-ai/CloudSkills62026年4月5日 更新

Use when working with Aqua — aqua Security platform analysis. Covers container runtime protection, image assurance policies, compliance frameworks, vulnerability management, workload protection, and registry scanning. Use when analyzing container security posture, reviewing image compliance, investigating runtime alerts, or auditing security policies.

日本語の概要は準備中です。原文の説明を表示しています。

cloudthinker-ai/CloudSkills62026年4月5日 更新

Use when working with Bigquery — google BigQuery job analysis, slot utilization, cost analysis, dataset management, and query optimization.

日本語の概要は準備中です。原文の説明を表示しています。

cloudthinker-ai/CloudSkills62026年4月5日 更新

Use when working with Cassandra — apache Cassandra keyspace analysis, compaction strategies, repair status, nodetool operations, and cluster health monitoring.

日本語の概要は準備中です。原文の説明を表示しています。

cloudthinker-ai/CloudSkills62026年4月5日 更新

Use when working with Checkov — checkov infrastructure-as-code security scanning. Covers Terraform, CloudFormation, Kubernetes, and Dockerfile scanning, policy management, custom checks, compliance frameworks, and suppression management. Use when scanning IaC for security misconfigurations, evaluating compliance, managing custom policies, or reviewing scan results.

日本語の概要は準備中です。原文の説明を表示しています。

cloudthinker-ai/CloudSkills62026年4月5日 更新

cloudthinker-ai のスキルをすべて見る

このスキルの問題を報告する