---
name: cloud-cost-optimize
description: Performs FinOps cost optimization on AWS/GCP/Azure — right-sizing instances, spotting idle/orphaned resources, Savings Plans/Reserved/committed-use analysis, storage tiering, and cost anomaly investigation. Triggers when a cloud bill spikes, doing a cost review, or right-sizing infrastructure.
when_to_use: bill cloud พุ่ง, รีวิว cost/FinOps, right-size instance, หา resource ที่ idle/orphan, วิเคราะห์ cost anomaly
---

## When to Use

- Cloud bill jumped vs last month/period and you need to find *what* and *why* before paying it.
- Scheduled FinOps / cost review of an account, project, or subscription.
- Right-sizing a fleet (EC2 / Compute Engine / VM Scale Sets, RDS/Cloud SQL, EKS/GKE/AKS nodes).
- Hunting idle or orphaned resources draining money with zero traffic.
- Deciding commitment strategy: Savings Plans / Reserved Instances / Committed-Use Discounts vs Spot/Preemptible.

Skip if: you only need a one-off price quote for a single SKU (use the pricing calculator), or the spike is already explained by a known launch/migration.

## Steps

Detect the provider first — never assume. Check for `~/.aws/credentials` / `AWS_PROFILE`, `gcloud config list`, or `az account show`. Always pin scope (`--region`, `--project`, subscription) and a date window. Always start **read-only**; never mutate in the analysis phase.

### 1. Pull the cost breakdown by service + tag (find the biggest lever)
Don't eyeball the console — pull structured data grouped by service AND a cost-allocation dimension, so you know where the money actually is.
- **AWS:** `aws ce get-cost-and-usage --time-period Start=<YYYY-MM-01>,End=<YYYY-MM-01> --granularity MONTHLY --metrics UnblendedCost --group-by Type=DIMENSION,Key=SERVICE` then re-run grouped by `Type=TAG,Key=<env|team|app>` and by `Type=DIMENSION,Key=USAGE_TYPE` for the top service. Compare two consecutive months to isolate the delta.
- **GCP:** query the **BigQuery billing export** (`SELECT service.description, sku.description, SUM(cost) ... GROUP BY ... ORDER BY 3 DESC`). The console export lags and rounds; BQ is the source of truth. If no export configured, that's finding #1.
- **Azure:** `az costmanagement query --type ActualCost --timeframe MonthToDate --dataset-grouping name=ServiceName type=Dimension`.
- Output: top 5 services by spend + their MoM delta. Everything below focuses effort on these, not on the long tail.

### 2. Find idle + orphaned resources (fast money, low risk)
These cost money for nothing. Hit each class explicitly:
- **Unattached block storage:** AWS `aws ec2 describe-volumes --filters Name=status,Values=available` (status `available` = detached, still billed). GCP unattached PDs (`gcloud compute disks list` + cross-check users field empty). Azure `az disk list --query "[?diskState=='Unattached']"`.
- **Unassociated static IPs:** AWS EIPs not attached to a running instance are billed hourly — `aws ec2 describe-addresses --query "Addresses[?AssociationId==null]"`. Same for idle GCP static external IPs / Azure unassociated Public IPs.
- **Idle load balancers:** ELB/ALB/NLB with zero `RequestCount`/`ActiveFlowCount` over 14d in CloudWatch. An ALB with no targets or no traffic is pure waste.
- **Stale snapshots & old AMIs/images:** snapshots older than your retention policy, AMIs no launch-templated anywhere. These grow silently.
- **Over-provisioned managed clusters:** EKS/GKE/AKS node groups with low pod density — check `kubectl top nodes` and allocatable vs requests. Empty/cordoned nodes that never scaled down.
- **Forgotten dev/staging:** non-prod compute running 24/7. Tag-filter `env!=prod` and check for instances with no business reason to run nights/weekends → schedule stop or use auto-shutdown.
- **NAT Gateway / cross-AZ data:** often a hidden top-3 line item. Flag for step 5.

### 3. Right-size compute on REAL utilization (not nameplate)
Never resize on instance type alone — pull 14–30 days of actual metrics.
- **AWS:** start with **Compute Optimizer** (`aws compute-optimizer get-ec2-instance-recommendations`) — it already crunched p99 CPU/mem/network and gives a target type + projected savings. Validate against CloudWatch `CPUUtilization` p99 and **memory** (CloudWatch agent required — if mem isn't published, say so; CPU-only sizing is unsafe for memory-bound apps). Rule of thumb: sustained p99 CPU < 40% and p99 mem < 50% → downsize one step.
- **GCP:** use **Recommender** (`gcloud recommender recommendations list --recommender=google.compute.instance.MachineTypeRecommender`).
- **Azure:** **Advisor** right-size recommendations (`az advisor recommendation list --category Cost`).
- **Databases:** RDS/Cloud SQL/Azure SQL are frequently oversized — check CPU, connections, and IOPS p99. Move gp2→gp3 on RDS (cheaper, decoupled IOPS) as a near-zero-risk win.
- Prefer the same-family smaller size or a newer generation (e.g. m5→m6i/m7g Graviton) before exotic types — Graviton/ARM is often ~20% cheaper at equal perf if the workload is ARM-compatible.

### 4. Commitment analysis (Savings Plans / RI / CUD vs Spot)
Only after right-sizing — committing to oversized capacity locks in waste.
- Pull current commitment **coverage** and **utilization**: AWS `aws ce get-savings-plans-utilization` + `get-savings-plans-coverage` (and `get-reservation-coverage` for RDS/ElastiCache/Redshift/OpenSearch which use RIs, not SPs). Coverage low + steady baseline = buy more; utilization < 95% = you over-committed.
- Use the provider's **purchase recommendations** as the starting number: AWS `aws ce get-savings-plans-purchase-recommendation --term-in-years ONE_YEAR --payment-option NO_UPFRONT --lookback-period-in-days THIRTY_DAYS`. Default to **Compute Savings Plans** (flexible across family/region/Fargate/Lambda) over EC2 Instance SPs unless the fleet is truly static. 1yr no-upfront is the safe default; 3yr only for proven-stable baseline.
- **GCP:** CUDs — prefer **flexible/spend-based** CUDs over resource-based for changing fleets.
- **Spot/Preemptible:** for stateless, fault-tolerant, batch, or interruptible workloads → 60–90% off. Quantify what fraction of compute is spot-eligible; that's the cheapest capacity tier and should be exhausted before buying commitments for it.
- Output: recommended commitment $ + projected monthly savings + break-even, and explicitly the baseline (committed) vs burst (on-demand) vs interruptible (spot) split.

### 5. Storage tiering + data-transfer / egress
- **Object storage:** enable lifecycle/Intelligent-Tiering. S3 → Intelligent-Tiering or lifecycle to IA/Glacier by access age; GCS → Autoclass or Nearline/Coldline/Archive; Azure → Blob lifecycle Hot→Cool→Cold→Archive. Check for **no lifecycle policy at all** on large buckets — common silent leak.
- **Incomplete multipart uploads / old versions:** S3 hides cost in incomplete MPU and noncurrent versions — add a lifecycle rule to abort/expire them.
- **Egress / data transfer:** usually the most opaque line item. Cross-AZ chatter, NAT Gateway processing, inter-region replication, and internet egress. Mitigations: VPC/Gateway/PrivateLink endpoints to avoid NAT for AWS-service traffic, co-locate chatty services in one AZ, CloudFront/CDN in front of egress-heavy origins, and check that internal traffic isn't routing through public IPs.
- **Logs/metrics retention:** CloudWatch Logs / Cloud Logging / Log Analytics with infinite retention silently balloon — set retention and route cold logs to object storage.

### 6. Tagging, budgets, and anomaly alerts (prevent the next spike)
- **Tag coverage:** quantify % of spend that is **untagged** (allocation gap). Untagged spend = can't attribute = can't optimize. Recommend enforcing required tags (`env`, `owner`, `cost-center`) via SCP/Org Policy/Azure Policy.
- **Budgets:** AWS Budgets / GCP Budget alerts / Azure Cost Management budgets with alert thresholds at 50/80/100% to the owning team.
- **Anomaly detection:** AWS **Cost Anomaly Detection** (`aws ce get-anomalies` to investigate the current spike; create a monitor if none exists). GCP/Azure have equivalent anomaly alerts. For a live spike: filter anomalies to the window, get the root-cause dimension (service + usage type + linked account), and tie it back to step 1's delta.

### 7. Rank recommendations by effort vs impact
Produce a single prioritized table — do NOT dump a flat list. Columns: **Recommendation | Monthly $ saved (est.) | Effort (S/M/L) | Risk | Reversible? | Action/command**.
- Sort by impact-per-effort. Surface **quick wins** (delete orphans, gp2→gp3, add lifecycle, release EIPs) at the top — high $/low effort/reversible.
- Right-sizing and Graviton migration = medium effort, needs a perf validation step.
- Commitments = high-confidence savings but **financial lock-in** — flag explicitly and require human sign-off; never purchase autonomously.
- Give a total: "estimated $X/mo (Y%) recoverable, $Z of it as zero-risk quick wins."

## Common Errors

- **Right-sizing on CPU only.** If the CloudWatch agent / Ops Agent isn't installed, memory metrics don't exist — the provider tool fills gaps with assumptions. Downsizing a memory-bound app on CPU data alone causes OOM. State when mem data is missing.
- **`aws ce` returns near-zero / empty.** Cost Explorer must be **enabled** in the account and has ~24h data latency; first call after enabling shows nothing. Also CE is global (`us-east-1` endpoint) — region flags don't filter it. Tag-based grouping only works for **activated** cost-allocation tags (activation isn't retroactive).
- **Confusing detached vs in-use.** A volume `in-use`/disk attached to a **stopped** instance is still billed — "stopped" ≠ free for storage/EIP. Don't only filter `available`.
- **Blended vs unblended cost.** Use **UnblendedCost** for actuals; blended hides RI/SP allocation across an org and misleads per-account analysis.
- **GCP console export ≠ truth.** The CSV/console rounds and lags up to a day. Always query the BigQuery billing export for cents-accurate, SKU-level data.
- **Buying commitments before right-sizing.** Locks in your current (oversized) footprint for 1–3 years. Order matters: orphans → right-size → spot → *then* commit on the proven baseline.
- **Deleting "orphaned" snapshots that back an AMI / are a DR copy.** A snapshot can look unattached but be the backing store of a registered AMI or a cross-region DR copy. Check AMI block-device mappings and DR runbooks before deleting. Never bulk-delete snapshots in the analysis phase.
- **Reading egress as one number.** "Data transfer" bundles internet egress, cross-AZ, NAT processing, and inter-region — each has a different fix. Break it down by `USAGE_TYPE` before recommending.
- **Mutating during analysis.** This skill's job is to *recommend*. Don't terminate, resize, or purchase. All write actions are human-gated.

## Verify

- Every dollar figure traces to a real query/command output, not an estimate from memory — cite the command per recommendation.
- Savings estimates are **monthly** and net (post-discount), with the assumed commitment term/payment option stated.
- Quick wins are confirmed reversible (release EIP, delete unattached vol with a final snapshot, gp2→gp3) and separated from lock-in actions.
- The top spend services in the final report reconcile to the step-1 breakdown total (sums match the bill, ± rounding).
- No write/mutating command was executed; all destructive or financial actions are presented as proposed commands for human approval.
- Re-run the cost breakdown ~one billing cycle after changes land to confirm realized savings vs projected (close the loop).