GCP Rightsizing

GCP Rightsizing Skill

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

Relationship to other GCP skills:

• gcp-rightsizing/ -> "What is oversized" (utilization thresholds, downsize recommendations)
• gcp-idle-resources/ -> "What is wasting money" (idle detection rules, cost estimation)
• gcp/ -> "How to execute" (parallel patterns, monitoring aligners, billing/pricing scripts)

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

Rule 2: E2 Shared-Core Instances Have Hard CPU Limits

E2 shared-core VMs (e2-micro, e2-small, e2-medium) have CPU time limits, NOT burstable credits like AWS t-family. An e2-micro gets 2 vCPUs but is capped at 12.5% (0.25 vCPU equivalent) sustained. They cannot exceed their allocation even if idle beforehand.

MANDATORY: Do NOT treat E2 shared-core like AWS burstable. High CPU % on shared-core means the workload is hitting its hard cap.

WRONG:  e2-micro avg CPU 12% -> "underutilized, this is a 2-vCPU machine at only 12%"
CORRECT: e2-micro avg CPU 12% -> "near cap (12.5% limit). Consider upgrading to e2-small (25% cap)"
CORRECT: e2-small avg CPU 5% -> "using 5% of 25% cap, underutilized"

CPU cap reference:

Rule 3: Sole-Tenant Nodes -- Report Node Utilization, Not VM

On sole-tenant nodes, VMs share a physical host. Rightsizing individual VMs without considering overall node fill rate is misleading.

MANDATORY: Flag sole-tenant VMs separately. The optimization is node fill rate, not individual VM utilization.

WRONG:  "vm-abc on sole-tenant node is at 5% CPU, downsize"
CORRECT: "vm-abc is on sole-tenant node node-group-xyz. Individual VM rightsizing deferred -- optimize node fill rate instead."

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: Preemptible/Spot VMs -- Skip Rightsizing

Preemptible and Spot VMs already run at 60-91% discount. Rightsizing savings are marginal and the workload is already optimized for cost.

MANDATORY: Exclude preemptible/spot VMs from rightsizing analysis.

WRONG:  "preemptible vm-abc is underutilized, downsize"
CORRECT: "vm-abc is preemptible/spot -- skipped (already cost-optimized)"

Rule 6: Savings Estimates Must Caveat CUD/SUD Coverage

GCP applies Sustained Use Discounts (SUDs) automatically (up to 30% for N1/N2) and Committed Use Discounts (CUDs) contractually. Downsizing a CUD-covered VM does NOT immediately save money -- the commitment continues.

MANDATORY: Caveat all savings estimates. Query CUD coverage when possible.

WRONG:  "Downsize to save $70/mo"
CORRECT: "Estimated on-demand savings: $70/mo. Note: if CUD-covered, savings may not apply until commitment expires. SUD automatically adjusts."

Rule 7: Cloud SQL activationPolicy + HA Doubles Compute

Cloud SQL with availabilityType=REGIONAL (HA) doubles compute cost (standby replica). A db-custom-4-16384 HA instance costs 2x the single-zone price.

MANDATORY: Check availabilityType before estimating Cloud SQL costs.

WRONG:  db-custom-4-16384 -> $165/mo
CORRECT: db-custom-4-16384, availabilityType=REGIONAL -> $330/mo (HA doubles compute)
CORRECT: db-custom-4-16384, availabilityType=ZONAL -> $165/mo

Rule 8: Persistent Disk Type Migration (pd-standard -> pd-balanced)

pd-standard (HDD) is $0.04/GiB/mo but limited to 0.75 IOPS/GiB. pd-balanced (SSD) is $0.10/GiB/mo with 6 IOPS/GiB baseline. A 200GiB pd-standard has only 150 IOPS baseline.

MANDATORY: Compare actual IOPS usage against baseline before recommending type changes.

WRONG:  "pd-standard is slower, just switch to pd-balanced"
CORRECT: "200GiB pd-standard: 150 IOPS baseline, actual avg 40 IOPS (27%). Right-sized for IOPS."
CORRECT: "200GiB pd-standard: 150 IOPS baseline, actual avg 140 IOPS (93%). Upgrade to pd-balanced for 1200 IOPS baseline."

Rule 9: Cloud Functions/Cloud Run -- Flag Waste, Don't Prescribe Values

Serverless resource configuration is highly workload-specific. Flag obvious waste (allocated 4GiB, uses 200MiB) but do NOT recommend specific memory/CPU values. Let the user benchmark.

WRONG:  "Cloud Function allocates 2GiB, reduce to 256MiB"
CORRECT: "Cloud Function fn-abc allocates 2048MiB but peak memory usage is 180MiB. Candidate for memory reduction (benchmark required)."

Rule 10: SUD Eligibility Varies by Machine Family

N1 and N2 families get automatic SUDs (up to 30%). E2 and T2D do NOT get SUDs. C3 and M3 do NOT get SUDs (use CUDs instead).

MANDATORY: Include SUD eligibility when showing savings.

WRONG:  "All VMs get 30% sustained use discount"
CORRECT: "n2-standard-4: SUD-eligible (up to 30% automatic discount)"
CORRECT: "e2-standard-4: NOT SUD-eligible (use CUDs for discounts)"

Mandatory Pre-Analysis Checklist

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

• Observation window >= 14 days (see Rule 1)
• E2 shared-core instances analyzed against their CPU cap, not raw vCPU count (see Rule 2)
• Sole-tenant VMs identified and handled separately (see Rule 3)
• Both Average AND Maximum statistics reported for all metrics (see Rule 4)
• Preemptible/Spot VMs excluded (see Rule 5)
• Savings caveated as "based on on-demand rates; CUD/SUD may apply" (see Rule 6)
• Cloud SQL HA flag checked (see Rule 7)
• All cost figures include currency unit (USD)
• Parallel execution used for all Cloud Monitoring queries (see gcp/SKILL.md)

Rightsizing Script (get_rightsizing_gcp.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/gcp/gcp-rightsizing/scripts/get_rightsizing_gcp.sh

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

FUNCTION REFERENCE:

RECOMMENDED WORKFLOW (every rightsizing analysis):

1. Always run gcp_rightsizing_vms first -- Compute Engine is typically the largest compute cost
2. Run gcp_rightsizing_cloudsql for database layer analysis
3. Run gcp_rightsizing_disks for storage optimization (pd-standard -> pd-balanced candidates)
4. Run gcp_rightsizing_serverless if Cloud Functions/Cloud Run is a significant cost driver
5. Or run gcp_rightsizing_summary for a unified view across all resource types

Examples:

source ./_skills/connections/gcp/gcp-rightsizing/scripts/get_rightsizing_gcp.sh

# VM utilization analysis (14-day default)
gcp_rightsizing_vms

# VM analysis with 30-day window in specific project
gcp_rightsizing_vms --days 30 --project my-project-id

# Cloud SQL utilization
gcp_rightsizing_cloudsql --days 14

# PD rightsizing (type migration candidates)
gcp_rightsizing_disks --days 14

# Cloud Functions + Cloud Run analysis
gcp_rightsizing_serverless --days 14

# Full summary across all resource types
gcp_rightsizing_summary --days 30 --project my-project-id

GCP Machine Type Quick Reference

Approximate monthly on-demand costs in USD (us-central1, tax-exclusive). Use to validate savings estimates.

Downsizing savings: Moving one size down within a family typically saves ~50% (e.g., e2-standard-8 $196 -> e2-standard-4 $98 = $98/mo savings).

For machine types not listed above, use get_gcp_cost from the gcp/ skill.

Cloud SQL Tier Reference

Persistent Disk Performance Reference

Cloud Monitoring Metrics Used

CRITICAL: alignment-period MUST be >= 60 seconds when using aligners other than ALIGN_NONE.

Common Errors

Output Format

Present results as a structured report:

Gcp 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