cost-optimization-review

成本优化审查

步骤 1：收集上下文

询问用户：

您希望我审查哪个工作负载或 AWS 环境的成本优化情况？请提供：

• 工作负载名称以及要分析的代码包/目录
• 流量模式（稳定、突发、可预测的增长、季节性）
• 月度支出估算（可选，有助于评估问题严重程度）
• 预算限制或目标（可选）

如果已提供上下文，或您正在检查包含 IaC 的代码库，请直接继续。

步骤 2：计算资源成本分析

分析所有计算资源配置。

您必须检查：

• ASG/启动模板中的 EC2 实例类型和规格
• ECS 任务定义（CPU/内存分配）
• Lambda 内存和超时配置
• Fargate 任务规格
• EKS 节点组配置
• Batch 计算环境

对于每项计算资源，请记录：

• 文件路径和行号
• 已配置的实例类型/规格
• 扩缩配置（最小值/最大值/期望值）
• 是否使用 Graviton（或在 Graviton 可用时使用 x86）
• 定价模式影响（仅按需、可使用 Spot，还是可使用预留）

您必须将以下情况标记为 HIGH RISK：

• 可变工作负载使用固定规模计算资源（无自动扩缩）
• Lambda 配置过度（简单操作使用超过 1024 MB）
• 存在 Graviton 等效实例类型，却使用 x86 实例类型（影响成本和可持续性）
• 工作负载使用大型实例类型，而通过水平扩展即可使用较小实例
• 开发/测试环境使用生产级资源
• 对存在明确非工作时段的环境未设置定时扩缩

步骤 3：存储和数据成本分析

分析存储配置。

您必须检查：

• S3 存储桶配置（存储类别、生命周期策略、版本控制）
• EBS 卷类型和大小
• RDS 存储配置（类型、分配大小、自动扩展）
• DynamoDB 容量模式和预置设置
• ElastiCache 节点类型和集群大小
• EFS 配置（吞吐量模式、生命周期）
• 备份保留策略（AWS Backup、RDS 快照）
• 日志保留设置（CloudWatch 日志组）

您必须将以下情况标记为 HIGH RISK：

• S3 存储桶未设置生命周期策略，导致数据无限期累积
• CloudWatch 日志组的保留期设置为“永不过期”
• DynamoDB 使用预置容量，但根据使用模式可改用按需容量（反之亦然）
• EBS/RDS 的 IOPS 过度配置
• EBS 卷未使用 gp3（相同性能下，gp2 的成本更高）
• 备份保留时间超过 35 天，但没有业务依据
• S3 启用了版本控制，却未设置生命周期规则以清理旧版本

步骤 4：数据传输成本分析

分析网络和数据传输模式。

您必须检查：

• NAT Gateway 的使用情况（是否可用 VPC 端点替代？）
• 跨区域数据传输模式
• VPC 端点配置（或 S3/DynamoDB 未配置端点的情况）
• CloudFront 分配（或静态内容未使用 CloudFront 的情况）
• 跨可用区流量模式（多可用区服务之间是否跨可用区通信）
• API Gateway 配置（REST API 还是 HTTP API，及其定价）

您必须将以下情况标记为 HIGH RISK：

• 通过 NAT Gateway 访问 S3/DynamoDB（VPC 端点可免费替代）
• 静态内容分发未使用 CloudFront
• REST API Gateway 可由 HTTP API 满足需求（成本低 70%）
• 跨区域复制没有业务依据
• 通过互联网公开访问 S3，而使用 CloudFront 可降低传输成本

步骤 5：定价模式评估

分析定价模式是否符合使用模式。

您必须评估：

• 稳定运行的计算资源 → 是否可使用 Savings Plans 或 Reserved Instances
• 可变/批处理计算资源 → 是否可使用 Spot Instance
• 无服务器与预置资源的匹配情况（突发型工作负载使用 Lambda/Fargate，稳定型工作负载使用 EC2/ECS）
• DynamoDB 按需与预置模式（不可预测时使用按需，稳定时使用预置）
• Aurora Serverless v2 与预置模式的选择（适用于数据库负载可变的情况）
• 访问模式未知时，是否可使用 S3 Intelligent-Tiering

第 6 步：环境与生命周期管理

分析非生产环境的配置。

你必须检查：

• 开发／测试／预发布环境与生产环境的规模对比
• 非生产环境的定时扩缩容或关停
• 资源生命周期策略（测试资源的 TTL）
• 资源上的成本分配标签
• 预算与异常检测配置

你必须将以下情况标记为改进机会：

• 非生产环境按生产规模全天候运行
• 资源上没有成本分配标签
• 未配置 AWS Budget 或 Cost Anomaly Detection
• 测试／临时资源没有生命周期策略

---STOP--- 检查点：发现工作已完成 — 准备根据 WA 框架进行评估

已发现计算资源（{X} 个实例／函数）、存储配置（{Y} 个存储桶／卷／表）、数据传输模式、定价模型匹配情况，以及 {packages analyzed} 中的环境生命周期设置。

是否要继续根据 WA 成本优化支柱问题评估这些发现并量化节省估算？

在用户明确确认前，不要越过此处继续操作。

第 7 步：根据 WA 框架问题进行评估

对于每个问题，请提供：状态、证据（文件:行号）、差距、风险。

COST 1 — 如何实施云财务管理？

• 证据：成本分配标签、预算配置、异常检测规则

COST 2 — 如何管理使用情况？

• 证据：限制实例类型的 SCP、配额、资源约束

COST 3 — 如何监控使用情况和成本？

• 证据：预算警报、Cost Anomaly Detection 配置、账单警报

COST 4 — 如何停用资源？

• 证据：生命周期策略、TTL 配置、清理自动化、保留规则

COST 5 — 选择服务时如何评估成本？

• 证据：可变负载使用无服务器方案、稳定负载使用预置方案、批处理使用 Spot

COST 6 — 选择资源类型、大小和数量时，如何满足成本目标？

• 证据：实例类型、扩缩容最小值／最大值、内存分配、适当调整资源规模的依据

COST 7 — 如何利用定价模型降低成本？

• 证据：Savings Plan 配置、预留容量、Spot 实例集配置

COST 8 — 如何规划数据传输费用？

• 证据：VPC 端点、CloudFront 分配、区域部署位置

第 8 步：量化节省估算

针对每项发现，估算：

• 当前成本指标：导致成本产生的资源配置（实例类型、预置容量、保留期）
• 优化后的配置：资源应采用的配置
• 相对节省：该资源类别的成本降幅百分比
• 工作量：实施难度，低／中／高
• 风险：对可靠性或性能的影响

步骤 9：风险评估

针对每项发现，按影响程度 × 发生可能性进行评估：

影响程度：轻微（该类别节省 < 10%）| 中等（该类别节省 10-30%）| 严重（该类别节省 > 30%，或定价模型存在根本性错配）

发生可能性（浪费持续存在的可能性）：低（已有优化计划）| 中（没有计划，但增长缓慢）| 高（持续增长且无人关注）

影响程度	发生可能性	风险等级
严重	高	严重
严重	中	高
严重	低	高
中等	高	高
中等	中	中
中等	低	中
轻微	高	中
轻微	中	低
轻微	低	低

---STOP--- 检查点：风险评估已完成 — 可以生成最终报告

已对计算、存储、数据传输、定价模型和环境管理方面的 {N} 项发现进行评估。风险分布：{X} 项严重、{Y} 项高、{Z} 项中、{W} 项低。已识别出主要节省机会并估算所需工作量。

是否要我生成完整的成本优化报告，并附上按优先级排序的修复计划？

在用户明确确认之前，不要继续执行。

---

步骤 10：生成报告

# Cost Optimization Review: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Cost Efficiency**: {1-5} — {one-line justification}
- **Top 3 Savings Opportunities**: {brief list}

## Cost Optimization Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Compute Right-Sizing | {score} | {strength} | {gap} |
| Storage Lifecycle | {score} | {strength} | {gap} |
| Data Transfer | {score} | {strength} | {gap} |
| Pricing Models | {score} | {strength} | {gap} |
| Environment Management | {score} | {strength} | {gap} |
| Cost Visibility | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), cost impact, recommendation, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Savings Summary
| Category | Finding | Current Config | Optimized Config | Relative Savings | Effort |
|----------|---------|---------------|-----------------|-----------------|--------|
| Compute | {title} | {current} | {recommended} | {%} | {effort} |
| Storage | {title} | {current} | {recommended} | {%} | {effort} |
| Transfer | {title} | {current} | {recommended} | {%} | {effort} |

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Savings Impact | Effort | Risk |
|---------|--------|---------------|--------|------|
{Switch gp2→gp3, add lifecycle policies, set log retention, add VPC endpoints}

### Foundation (1-4 weeks)
| Finding | Action | Savings Impact | Effort | Dependencies |
|---------|--------|---------------|--------|--------------|
{Right-size instances, implement auto-scaling, schedule non-prod, add Graviton}

### Strategic (1-3 months)
| Finding | Action | Savings Impact | Effort | Dependencies |
|---------|--------|---------------|--------|--------------|
{Savings Plans commitment, serverless migration, architecture optimization}

## Next Steps
{Top 5 concrete cost-saving actions the team should take this week}

步骤 11：提供后续帮助

交付报告后，提供以下选项：

你希望我：

• 为快速见效的优化生成 IaC 变更？
• 根据你的用量比较 Savings Plans 与 Reserved Instances？
• 为非生产环境设计定时扩缩容策略？
• 制定带有成本分摊标签的 FinOps 标记策略？
• 估算架构替代方案（无服务器、容器）的成本？
• 为已识别的存储桶实施 S3 生命周期策略？

校准指南

• 具备自动扩缩容、生命周期策略、VPC 端点和成本分摊标签的工作负载属于成熟型 — 应重点关注高级优化（Savings Plans、Spot、架构替代方案）
• 每项发现都必须有代码证据 — 未检查实际配置前，不要标记为“过度配置”
• 不清楚绝对支出时，节省估算应使用相对值（降低百分比）
• 始终评估权衡：成本优化不得引入可靠性风险，除非明确说明
• 如果成本优化会降低可靠性或性能水平，应予以标记
• 如果仅凭 IaC 无法评估实际利用率，“无法确定”是有效结论（建议使用 Compute Optimizer、Cost Explorer）
• 列出浪费之前，先肯定良好的成本实践