# Cost Optimization Risk Governance Guide

Use this reference for AWS Cost Explorer, Budgets, Cost Optimization Hub, Compute Optimizer, Savings Plans, Reserved Instances, tagging, showback, idle resources, rightsizing, storage, data transfer, and forecast-risk reviews.

## What people get wrong

The lazy story is:

> Cost optimization is a list of savings recommendations.

Wrong. Savings are not neutral. Every cost action has reliability, security, compliance, performance, and delivery tradeoffs. Unowned recommendations become shelfware or outages.

Common bad assumptions:

- Cost Optimization Hub or Compute Optimizer estimates are implementation-ready.
- Rightsizing is safe from average utilization.
- Commitments are good if discount percentage is high.
- Idle resources can be deleted without owner and recovery evidence.
- Tagging is just reporting hygiene.
- Data transfer and observability costs are secondary details.

## Cost-governance failure modes

- Recommendation ignores business seasonality, migration, incidents, batch windows, or growth.
- Savings Plans/RI purchase conflicts with architecture roadmap or account ownership.
- Deleting logs, backups, NAT gateways, replicas, or endpoints reduces auditability or resilience.
- Rightsizing compute/storage causes latency, failover, or scale-out regressions.
- Untagged/shared resources make owner attribution and chargeback wrong.
- Forecasts and anomaly baselines are treated as real-time truth.

## Minimum safe workflow

1. Confirm account scope, billing view, owner, business unit, monthly spend, forecast period, and optimization target.
2. Break down cost by service, account, Region, usage type, operation, tag, resource, and commitment coverage where available.
3. Classify opportunities: no-risk governance, low-risk configuration, engineering change, commitment purchase, or risky workload reduction.
4. For each recommendation, state savings estimate, confidence, owner, risk, validation evidence, rollback path, and pillar tradeoff.
5. Prefer reversible governance first: tags, budgets, anomaly alerts, dashboards, owner assignment, and idle-resource investigation.
6. Require approval for deletion, downscale, retention reduction, commitment purchase, or architecture changes.
7. Validate post-change savings and regressions after implementation.

## Verification targets

- Cost Explorer, Budgets, Cost Optimization Hub, Compute Optimizer, Savings Plans/RI coverage and utilization
- amortized/unblended/net cost basis, billing view, payer/member account scope, and data freshness
- tag coverage, cost categories, owner mapping, showback/chargeback, and budget/anomaly subscriptions
- utilization metrics, performance headroom, business seasonality, incident/release context, and growth forecast
- reliability/security/compliance impact for logs, backups, replicas, endpoints, encryption, monitoring, and support plans
- implementation owner, approval, rollback, and post-change measurement plan

## When to push back

Push back if the user asks to:

- delete/downscale resources from cost data alone
- buy commitments without usage stability and roadmap evidence
- reduce backup/log/security spend without risk acceptance
- blame owners from incomplete tags
- present savings without confidence and tradeoff labels
- treat recommendation tools as approval authority

# 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/compute-optimizer/latest/ug/what-is.html
- https://docs.aws.amazon.com/compute-optimizer/latest/ug/savings-estimation-mode.html
- https://docs.aws.amazon.com/cost-management/latest/userguide/understanding-rr-calc.html
- https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.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:
- Compute Optimizer analyzes resource configuration and utilization for EC2 instances, Auto Scaling groups, Lambda functions, EBS volumes, and ECS services on Fargate, then reports optimization recommendations.
- Cost Explorer rightsizing recommendations use usage and billing context; savings estimates can be affected by On-Demand hours, RI/Savings Plans coverage, and payer/member-account scope.

Sampled live evidence:
- Read-only regional availability sampling reported `Compute Optimizer+GetEC2InstanceRecommendations` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- `TrustedAdvisor+ListRecommendations` was reported `isAvailableIn` in `us-east-1`, `us-west-2`, and `eu-west-1`, and `Not Found` in `ap-southeast-1`; treat this as sampled API availability, not proof of support-plan entitlement or recommendation quality.

Review implications:
- Do not delete, downsize, or purchase commitments from recommendation output alone. Require utilization windows, performance/SLO impact, reservation or Savings Plans interaction, owner approval, rollback path, and change calendar context.
- Cost tools can identify candidates; they do not prove business criticality or safe remediation.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Cost scope, account/OU/team/service/tag coverage, currency, amortization, and discount assumptions
- Budgets, alerts, Cost Explorer queries, Cost Optimization Hub findings, and recommendation evidence
- Rightsizing, idle resources, commitments, storage lifecycle, data transfer, logging volume, and support cost
- Risk controls: rollback, workload owner approval, SLO impact, security impact, and measurement after change

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Cost Optimization Governor: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```