| name | gcp-rightsizing |
| description | Analyze Compute Engine VM, Cloud SQL, Persistent Disk, and serverless (Cloud Functions/Cloud Run) utilization to identify right-sizing opportunities. Uses Cloud Monitoring metrics with anti-hallucination rules for E2 shared-core instances, sole-tenant nodes, preemptible/spot VMs, SUD eligibility, peak vs average analysis, CUD-aware savings, and estimated monthly savings calculations. |
| connection_type | gcp |
| preload | false |
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:
| Machine Type | vCPUs | CPU Cap | Cap as % |
|---|
| e2-micro | 2 | 0.25 vCPU | 12.5% |
| e2-small | 2 | 0.50 vCPU | 25% |
| e2-medium | 2 | 1.00 vCPU | 50% |
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:
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:
| Function | Purpose | Signature |
|---|
gcp_rightsizing_vms | Compute Engine VM CPU analysis with shared-core, sole-tenant, preemptible handling | [--days N] [--project PROJECT] |
gcp_rightsizing_cloudsql | Cloud SQL CPU + connections with HA cost awareness | [--days N] [--project PROJECT] |
gcp_rightsizing_disks | Persistent Disk IOPS/throughput utilization, type migration candidates | [--days N] [--project PROJECT] |
gcp_rightsizing_serverless | Cloud Functions + Cloud Run memory/CPU waste detection | [--days N] [--project PROJECT] |
gcp_rightsizing_summary | Run all checks, output unified summary | [--days N] [--project PROJECT] |
RECOMMENDED WORKFLOW (every rightsizing analysis):
- Always run
gcp_rightsizing_vms first -- Compute Engine is typically the largest compute cost
- Run
gcp_rightsizing_cloudsql for database layer analysis
- Run
gcp_rightsizing_disks for storage optimization (pd-standard -> pd-balanced candidates)
- Run
gcp_rightsizing_serverless if Cloud Functions/Cloud Run is a significant cost driver
- 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
gcp_rightsizing_vms
gcp_rightsizing_vms --days 30 --project my-project-id
gcp_rightsizing_cloudsql --days 14
gcp_rightsizing_disks --days 14
gcp_rightsizing_serverless --days 14
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.
| Family | Machine Type | vCPU | Memory | ~Monthly USD | SUD Eligible |
|---|
| E2 | e2-micro | 2 (shared 0.25) | 1 GB | $6.11 | No |
| E2 | e2-small | 2 (shared 0.50) | 2 GB | $12.23 | No |
| E2 | e2-medium | 2 (shared 1.00) | 4 GB | $24.46 | No |
| E2 | e2-standard-2 | 2 | 8 GB | $48.92 | No |
| E2 | e2-standard-4 | 4 | 16 GB | $97.83 | No |
| E2 | e2-standard-8 | 8 | 32 GB | $195.67 | No |
| N2 | n2-standard-2 | 2 | 8 GB | $56.82 | Yes (up to 30%) |
| N2 | n2-standard-4 | 4 | 16 GB | $113.63 | Yes |
| N2 | n2-standard-8 | 8 | 32 GB | $227.26 | Yes |
| C3 | c3-standard-4 | 4 | 16 GB | $120.37 | No (CUD only) |
| N1 | n1-standard-1 | 1 | 3.75 GB | $24.27 | Yes (up to 30%) |
| N1 | n1-standard-2 | 2 | 7.5 GB | $48.55 | Yes |
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
| Tier | vCPU | Memory | ~Monthly USD (Zonal) | ~Monthly USD (HA) |
|---|
| db-f1-micro | shared | 0.6 GB | $10.80 | N/A |
| db-g1-small | shared | 1.7 GB | $36.00 | N/A |
| db-custom-1-3840 | 1 | 3.75 GB | $49.64 | $99.29 |
| db-custom-2-7680 | 2 | 7.5 GB | $99.29 | $198.58 |
| db-custom-4-15360 | 4 | 15 GB | $198.58 | $397.15 |
| db-custom-8-30720 | 8 | 30 GB | $397.15 | $794.30 |
Persistent Disk Performance Reference
| Disk Type | $/GiB/mo | IOPS/GiB | Max IOPS | Throughput/GiB |
|---|
| pd-standard | $0.04 | 0.75 R / 1.5 W | 7,500 | 0.12 MB/s |
| pd-balanced | $0.10 | 6 | 80,000 | 0.28 MB/s |
| pd-ssd | $0.17 | 30 | 100,000 | 0.48 MB/s |
| pd-extreme | $0.125 + IOPS | configurable | 120,000 | 1.2 GB/s |
Cloud Monitoring Metrics Used
| Resource | Metric | Namespace | Aligner |
|---|
| VM CPU | instance/cpu/utilization | compute.googleapis.com | ALIGN_MEAN, ALIGN_MAX |
| Cloud SQL CPU | database/cpu/utilization | cloudsql.googleapis.com | ALIGN_MEAN, ALIGN_MAX |
| Cloud SQL connections | database/network/connections | cloudsql.googleapis.com | ALIGN_MEAN |
| PD Read IOPS | instance/disk/read_ops_count | compute.googleapis.com | ALIGN_RATE |
| PD Write IOPS | instance/disk/write_ops_count | compute.googleapis.com | ALIGN_RATE |
| Cloud Function executions | function/execution_count | cloudfunctions.googleapis.com | ALIGN_RATE |
| Cloud Function memory | function/user_memory_bytes | cloudfunctions.googleapis.com | ALIGN_MAX |
| Cloud Run request count | request_count | run.googleapis.com | ALIGN_RATE |
| Cloud Run memory util | container/memory/utilizations | run.googleapis.com | ALIGN_MAX |
CRITICAL: alignment-period MUST be >= 60 seconds when using aligners other than ALIGN_NONE.
Common Errors
| Error | Cause | Solution |
|---|
PERMISSION_DENIED on monitoring | Missing monitoring.timeSeries.list permission | Check service account roles |
| No data for VM CPU | Instance was recently created or restarted | Extend observation window |
| E2 shared-core appears underutilized | Comparing against 2 vCPUs instead of CPU cap | Use the CPU cap table (Rule 2) |
| Savings estimate seems too high | HA Cloud SQL not accounted for | Check availabilityType, double cost if REGIONAL (Rule 7) |
| Preemptible VM flagged for rightsizing | Script didn't filter scheduling policy | Check scheduling.preemptible field (Rule 5) |
| Cloud SQL shows as idle but has replicas | Read replicas are separate instances | Check for read replica relationships |
| Cloud Function memory unclear | Memory metric shows allocated, not peak | Use function/user_memory_bytes with ALIGN_MAX |
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
| 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 |
