aws-rightsizing

name	aws-rightsizing
description	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.
connection_type	aws
preload	false

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:

Function	Purpose	Signature
aws_rightsizing_ec2	EC2 CPU + optional memory analysis, flag under/over-utilized	[--days N] [--region REGION]
aws_rightsizing_ec2_savings	Estimate savings for flagged EC2 instances	[--days N] [--region REGION]
aws_rightsizing_rds	RDS CPU, connections, storage utilization	[--days N] [--region REGION]
aws_rightsizing_rds_savings	Estimate savings for flagged RDS instances	[--days N] [--region REGION]
aws_rightsizing_ebs	EBS IOPS/throughput utilization, GP2->GP3 candidates	[--days N] [--region REGION]
aws_rightsizing_lambda	Lambda memory/duration/invocation analysis	[--days N] [--region REGION]
aws_rightsizing_summary	Run 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.

Family	Size	vCPU	Memory	~Monthly USD
t3	micro	2	1 GB	$8
t3	small	2	2 GB	$15
t3	medium	2	4 GB	$30
t3	large	2	8 GB	$61
m5	large	2	8 GB	$70
m5	xlarge	4	16 GB	$140
m5	2xlarge	8	32 GB	$281
c5	large	2	4 GB	$62
c5	xlarge	4	8 GB	$124
c5	2xlarge	8	16 GB	$248
r5	large	2	16 GB	$91
r5	xlarge	4	32 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

Error	Cause	Solution
InvalidParameterCombination for CloudWatch	Wrong statistics syntax	Use spaces not commas: --statistics Average Maximum
No data for mem_used_percent	CWAgent not installed	Report "memory data unavailable", don't assume
CPUCreditBalance returns no data	Not a burstable instance	Only query for t-family instances
Savings estimate seems too high	Multi-AZ RDS not accounted for	Check MultiAZ flag, double cost if true
InvalidParameterValue for period	Period too small for date range	Use 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

Shortcut	Counter	Why
"I'll skip discovery and check known resources"	Always run Phase 1 discovery first	Resource names change, new resources appear — assumed names cause errors
"The user only asked for a quick check"	Follow the full discovery → analysis flow	Quick checks miss critical issues; structured analysis catches silent failures
"Default configuration is probably fine"	Audit configuration explicitly	Defaults often leave logging, security, and optimization features disabled
"Metrics aren't needed for this"	Always check relevant metrics when available	API/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 error	Assumed permission failures prevent useful investigation; actual errors are informative