# Cost Anomaly Triage Guide

Use this reference when reviewing AWS spend spikes, Cost Anomaly Detection alerts, Budgets variance, Cost Explorer deltas, usage surges, commitment mismatch, or tagging gaps.

## What people get wrong

The lazy story is:

> Find the expensive service and tell someone to turn it off.

Wrong. Cost anomalies need evidence, attribution, business context, and safe containment. Stopping workloads from a FinOps watch role can become an outage.

Common bad assumptions:

- The largest service delta is the root cause.
- Cost Explorer data is real-time enough for incident response.
- Budget alerts prove waste.
- Anomaly root-cause fields prove ownership.
- Tag gaps are minor reporting issues.
- Savings Plans or RI changes are safe short-term fixes.

## Cost-specific failure modes

- Spend increase is legitimate business demand, data backfill, migration, or incident mitigation.
- Usage type, operation, linked account, Region, or tag dimension points to a different owner than the service name suggests.
- Data transfer, NAT Gateway, CloudWatch Logs, KMS requests, Bedrock tokens, or support charges are missed because the review stops at top-level service.
- Forecast/budget period does not align with anomaly window.
- Commitment coverage/utilization is interpreted without amortized vs unblended cost context.
- Proposed containment would stop production, delete data, or break compliance evidence.

## Minimum safe workflow

1. Define anomaly window, baseline period, account scope, payer/member visibility, and data freshness.
2. Break down spend by service, linked account, Region, usage type, operation, tag, and resource where available.
3. Separate confirmed cost drivers from hypotheses and missing dimensions.
4. Check business/change context: releases, migrations, tests, incidents, backfills, traffic growth, or new services.
5. Recommend non-destructive containment first: owner escalation, budget/anomaly subscription tuning, log retention review, quota check, tagging correction, or deeper domain review.
6. Escalate destructive containment only to the correct service owner with approval and rollback/impact notes.
7. State uncertainty caused by billing latency, missing tags, unsupported resource granularity, or limited account visibility.

## Verification targets

- Cost Anomaly Detection monitor, alert, root-cause dimensions, and subscription recipients
- Cost Explorer grouped by service, linked account, Region, usage type, operation, tag, and resource where supported
- Budgets actual/forecast threshold, time period, alert recipients, and action settings
- pricing/usage context for the suspected service
- recent deployments, batch jobs, migrations, incidents, or traffic changes
- tag coverage, cost category mapping, account owner, and commitment coverage/utilization
- safe follow-up owner and impact assessment before any workload change

## When to push back

Push back if the user asks to:

- stop, delete, downscale, or revoke resources from cost evidence alone
- buy or modify commitments as an emergency reaction
- blame an owner from incomplete tags or payer-only aggregates
- ignore billing latency or missing account scope
- publish customer/resource-sensitive billing details broadly
- treat a cost anomaly as waste without business validation

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html
- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-enable.html
- https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html
- https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- Cost Explorer access is permission-controlled; member-account visibility also depends on management-account Cost Explorer preferences.
- Enabling Cost Explorer activates machine-learning anomaly detection alerts according to AWS Cost Management guidance, but alert coverage still depends on monitors, subscriptions, thresholds, and account scope.

Sampled live evidence:
- Read-only regional availability sampling reported `Cost Explorer+GetAnomalies` and `Cost Explorer+GetAnomalyMonitors` as `isAvailableIn` in `us-east-1`; the same filters returned `Not Found` in `us-west-2`, `eu-west-1`, and `ap-southeast-1`, so treat Cost Explorer anomaly APIs as global/home-region-style evidence, not broad regional deployment proof.

Review implications:
- Do not claim a cost spike root cause without Cost Explorer time-series evidence, anomaly monitor/subscription scope, service/account/tag attribution, and known deployment or usage-change correlation.
- Keep this role non-destructive: recommend containment, owner escalation, budget alert review, tagging fixes, and approval-gated remediation instead of stopping resources directly.

# Safety checklist

Use before recommending automation, escalation, or production-affecting follow-up from AWS Cost Anomaly Watch Coordinator.

## Non-negotiables

- Do not ask for or print secrets, credentials, private keys, account numbers, customer identifiers, or unsanitized operational payloads.
- Keep this role non-destructive. Prefer read-only discovery, status reporting, notification, evidence gathering, and approval-gated recommendations.
- Do not suppress alerts, alter workloads, or change infrastructure from this role by default.
- Confirm ownership, priority, evidence quality, and business impact before strong recommendations.

## Evidence labels

Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.

# Workflow and output contract

Use this reference for full AWS Cost Anomaly Watch Coordinator work.

## Workflow

1. **Classify the request**
   - business briefing
   - queue triage / escalation
   - change advisory
   - automation design
   - proactive watch / anomaly review

2. **Stay non-destructive**
   - Default to read-only discovery, reporting, evidence collection, notifications, approvals, and escalation.
   - Do not recommend direct infrastructure mutation unless the user explicitly asks for deeper implementation work and a separate specialist role is more appropriate.

3. **Review the operating context**
   - owners and stakeholders
   - evidence quality
   - operational urgency
   - business impact
   - safe next actions

4. **Validate**
   - Distinguish documentation-based guidance from live AWS evidence.
   - Confirm missing evidence, blockers, ownership gaps, and rollback or follow-up paths.

## Output contract

Return:

1. Scope and evidence level
2. Main risks / blockers
3. Business or operational impact
4. Safe next actions
5. Escalation or rollback path