企业官网建设流程全解析

claude-skills 云架构师成本优化指南：FinOps、预留实例、Spot 与 Right-Sizing 实战手册

【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills

本篇技术指南基于 claude-skills 仓库中 cost.md 这一成本优化参考文档整理而成，系统讲解 FinOps 框架、预留实例/Savings Plans、Spot 抢占式实例、Right-Sizing 以及存储、网络、Serverless 各维度的降本策略。它由 cloud-architect 技能 在 Claude Code 进行云架构设计、迁移规划或多云部署优化时按需加载，读完本文你将掌握一套可落地执行的云成本优化方法论，以及对应的 AWS / Azure / GCP 三朵云的具体配置命令与检查清单。

FinOps 框架

FinOps（云财务运营）是云成本优化的组织级实践框架。它把成本责任从财务部门下放到每个工程团队，让"花钱的人"同时成为"省钱的人"。

FinOps 六大原则

1. 团队需要协作——财务、工程、业务三方共同参与成本决策；
2. 人人有责——成本责任分散到各团队，而非集中在财务；
3. 中心团队驱动 FinOps——设立成本卓越中心（Center of Excellence），沉淀最佳实践；
4. 报表应及时可访问——提供实时可见的成本数据；
5. 决策由业务价值驱动——衡量每个业务产出的成本（单位成本）；
6. 善用弹性成本模型——按需扩缩容，充分享受云按量付费的红利。

FinOps 生命周期

Inform | +---------+ | | v v Optimize --> Operate ^ | | | +---------+

三个核心阶段相互循环：

• Inform（信息）阶段：建立云支出可见性、成本分摊与 showback、基准对比与预测；
• Optimize（优化）阶段：费率优化（预留实例、Savings Plans）、用量优化（Right-Sizing）、架构优化（改造成更省钱的架构形态）；
• Operate（运营）阶段：持续改进、自动化与治理、异常检测（如 AWS Cost Anomaly Detection）。

在 cloud-architect 技能 的 Core Workflow 中，第 4 步 "Cost Model" 明确要求：Right-size 资源、使用预留容量、配置自动扩缩容——这正是 FinOps Optimize 阶段在架构设计流程中的落地位置。该技能同时也将"启用成本分摊标签与监控"列入 MUST DO 约束清单。

计算成本优化

计算资源通常是云账单中占比最大的部分，优先从费率与用量两个角度下手。

预留实例与 Savings Plans

AWS Savings Plans 对比

承诺策略（Commitment Strategy）

Baseline（常驻负载）: 1 年或 3 年 Savings Plans Variable（可预测波动）: Scheduled Reserved Instances Spiky（不可预测突发）: On-Demand + Spot

Azure Reservations——通过 Azure CLI 购买预留容量：

# Azure CLI - Purchase reservation az reservations reservation-order purchase \ --sku Standard_D2s_v3 \ --term P1Y \ --billing-scope /subscriptions/{subscription-id} \ --quantity 10 \ --applied-scope-type Shared

参数含义：--sku指定 VM 规格；--term P1Y/P3Y表示 1 年或 3 年承诺期；--quantity为实例数量；--applied-scope-type Shared表示整个订阅共享该预留。

GCP Committed Use Discounts（承诺使用折扣）

• 基于资源（Resource-based）：锁定特定 vCPU 与内存；
• 基于花费（Spend-based）：承诺金额换取灵活性；
• 1 年期约 37% 折扣，3 年期约 55% 折扣（以 gcp.md 中记录的现行档位为准，不同实例类型折扣率会有差异）。

补充一点：GCP 还有无需任何承诺的Sustained Use Discounts（Sustained Use Discounts），实例当月运行超过 25% 时间即可自动获得最高约 30% 折扣；Preemptible/Spot VM 最高约 80% 折扣。这些在 gcp.md 的 Cost Optimization 章节中有完整说明。

Spot / Preemptible 实例

适用场景

• 批处理与数据分析；
• CI/CD 构建代理；
• 无状态 Web 服务器（配合自动扩缩容）；
• 机器学习训练；
• 开发与测试环境。

AWS Spot 最佳实践——混合实例策略（在 On-Demand 与 Spot 之间取平衡）：

# EC2 Auto Scaling with Spot MixedInstancesPolicy: InstancesDistribution: OnDemandBaseCapacity: 2 OnDemandPercentageAboveBaseCapacity: 20 SpotAllocationStrategy: capacity-optimized LaunchTemplate: Overrides: - InstanceType: m5.large - InstanceType: m5a.large - InstanceType: m4.large - InstanceType: r5.large

capacity-optimized策略会自动选择中断风险最低的容量池；通过多实例类型 Overrides 提高 Spot 容量可得性。

Spot 中断处理——利用实例元数据服务探测 2 分钟终止预警并优雅下线：

# Check for spot termination notice (AWS) import requests def check_spot_termination(): try: response = requests.get( "http://169.254.169.254/latest/meta-data/spot/termination-time", timeout=2 ) if response.status_code == 200: # 2-minute warning - gracefully shutdown graceful_shutdown() except requests.exceptions.RequestException: pass # Not being terminated

GCP Preemptible/Spot VM——Terraform 定义：

# Terraform - GCP Spot VM resource "google_compute_instance" "spot" { name = "spot-instance" machine_type = "n2-standard-4" scheduling { preemptible = true automatic_restart = false provisioning_model = "SPOT" instance_termination_action = "STOP" } }

provisioning_model = "SPOT"对应新版 Spot VM（比旧版 Preemptible 有更好的容量可用性），instance_termination_action = "STOP"使实例在终止时先停止而非直接删除，便于后续重启。

Right-Sizing（合理配置）

分析流程

1. 收集指标（CPU、内存、网络、磁盘 I/O）；
2. 识别空闲或利用不足的资源；
3. 推荐合适的实例规格；
4. 在维护窗口内实施变更；
5. 持续监控并迭代。

AWS Compute Optimizer：

# Enable Compute Optimizer aws compute-optimizer update-enrollment-status \ --status Active \ --include-member-accounts # Get recommendations aws compute-optimizer get-ec2-instance-recommendations \ --filters name=Finding,values=OVER_PROVISIONED

Right-Sizing 阈值参考

Azure Advisor 成本建议：

# Get cost recommendations az advisor recommendation list \ --category Cost \ --query "[?impact=='High']"

存储成本优化

存储成本优化围绕"分层"与"清理"两个关键字展开：按访问频率降级到廉价存储类，同时删除闲置的卷、快照与镜像。

对象存储分层

AWS S3 存储类分层路径：

S3 Standard | | (30 days) v S3 Standard-IA | | (90 days) v S3 Glacier Instant Retrieval | | (180 days) v S3 Glacier Deep Archive

生命周期策略示例（JSON 格式，可直接作为 S3 Lifecycle Configuration）：

{ "Rules": [ { "ID": "OptimizeCosts", "Status": "Enabled", "Filter": { "Prefix": "logs/" }, "Transitions": [ { "Days": 30, "StorageClass": "STANDARD_IA" }, { "Days": 90, "StorageClass": "GLACIER" }, { "Days": 365, "StorageClass": "DEEP_ARCHIVE" } ], "Expiration": { "Days": 730 } } ] }

该策略对logs/前缀下的对象实施 30 天转 IA、90 天转 Glacier、365 天转 Deep Archive、730 天删除的全生命周期管理。

S3 Intelligent-Tiering：根据访问模式自动在层间切换，无检索费用，仅按对象收取小额监控费，最适合访问模式不可预测的数据。

块存储优化

EBS 卷类型选择（价格为官方公开参考价，供选型对比）：

gp3 迁移（约 20% 节省）：

# Modify EBS volume from gp2 to gp3 aws ec2 modify-volume \ --volume-id vol-12345678 \ --volume-type gp3 \ --iops 3000 \ --throughput 125

gp3 相比 gp2 不仅单价更低，而且基准 3000 IOPS / 125 MB/s 性能免费包含，无需像 gp2 那样为 IOPS 付费。该结论在 aws.md 的 Cost Optimization Strategies 章节中也有印证（"EBS gp3 instead of gp2 — 20% cheaper, better performance"）。

数据库存储

Aurora 存储优化：仅按实际使用量付费、自动扩缩容、无需预先配置；以 10GB 为增量自动扩展至 128TB。

DynamoDB 容量模式：

GCP 侧的对应实践（见 gcp.md）：BigQuery 采用 On-Demand 定价（约 $5/TB 处理量）时应启用分区与聚簇、善用查询缓存；重负载用户可改用 Flat-Rate 固定费率；并使用APPROX_COUNT_DISTINCT近似聚合函数、避免SELECT *、为高频查询建立物化视图。

网络成本优化

网络成本（尤其是出口流量）容易被忽视，但多区、跨区传输的累积账单往往可观。

数据传输成本

AWS 数据传输价格参考：

Inbound: Free Same AZ: Free Cross-AZ: $0.01/GB each direction Same Region (via public IP): $0.01/GB Cross-Region: $0.02/GB Internet Egress: $0.09/GB (first 10TB)

优化策略

1. 尽量将流量保持在同一个可用区内；
2. 使用 VPC Endpoints 访问 AWS 服务；
3. 缓存内容走 CloudFront；
4. 传输前压缩数据；
5. 优先使用区域级服务而非全局服务。

VPC Endpoints（替代 NAT Gateway）：

# Gateway endpoint (free for S3, DynamoDB) resource "aws_vpc_endpoint" "s3" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.us-east-1.s3" } # Interface endpoint (cheaper than NAT for specific services) resource "aws_vpc_endpoint" "ecr" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.us-east-1.ecr.api" vpc_endpoint_type = "Interface" }

S3 与 DynamoDB 使用 Gateway Endpoint 完全免费；ECR 等 PaaS 服务用 Interface Endpoint 也远低于 NAT Gateway 按小时+按处理量的计费方式。

CDN 优化

CloudFront 成本节省要点

• 数据传输费率低于源站直连；
• 优化缓存命中率（目标 >90%）；
• 使用 Origin Shield 降低源站负载；
• 压缩对象（Gzip/Brotli）。

# CloudFront cache optimization CacheBehaviors: - PathPattern: "/static/*" CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6 # CachingOptimized Compress: true TTL: DefaultTTL: 86400 MaxTTL: 31536000

对静态资源设置 1 天默认 TTL、1 年最大 TTL，并开启压缩，可显著减少回源请求与出口流量。

Serverless 成本优化

Lambda 优化

内存/CPU 调优——Lambda 的计费 = 内存 × 时长，调大内存会线性提升 CPU 性能，从而缩短执行时间，存在最优平衡点：

# Use AWS Lambda Power Tuning # Finds optimal memory for cost vs performance # Results example: # 128MB: $0.000021 per invocation, 3200ms duration # 256MB: $0.000025 per invocation, 1600ms duration # 512MB: $0.000031 per invocation, 800ms duration # 1024MB: $0.000042 per invocation, 450ms duration # Optimal: 512MB (best cost-performance balance)

上例中 512MB 配置单次调用成本仅比 128MB 高约 50%，但时长缩短 4 倍，综合性价比最优。

降本策略清单

1. 合理设置内存大小；
2. 关键路径用 Provisioned Concurrency 最小化冷启动（注意其本身也按小时计费，需权衡）；
3. 使用 ARM64（Graviton2）架构——便宜约 20%；
4. 优化包体积以加快冷启动；
5. 用 Lambda Layers 共享公共依赖。

Graviton2 迁移（SAM 模板）：

# SAM template with ARM64 Resources: MyFunction: Type: AWS::Serverless::Function Properties: Runtime: python3.11 Architectures: - arm64 # 20% cost savings

容器优化

Fargate 定价优化——Fargate Spot 最高约 70% 折扣，适用于可容错工作负载：

# Fargate Spot: Up to 70% discount # Use for fault-tolerant workloads ECS Service: CapacityProviderStrategy: - CapacityProvider: FARGATE_SPOT Weight: 4 - CapacityProvider: FARGATE Weight: 1 Base: 2 # Minimum on-demand tasks

权重配置Weight: 4 : 1表示约 80% 任务优先落在 Spot 上，Base: 2保证至少有 2 个按需任务兜底。

容器资源 Right-Sizing：

# Analyze actual usage with Container Insights resources: requests: memory: "256Mi" # Based on p95 usage + 20% buffer cpu: "100m" # Based on p95 usage + 20% buffer limits: memory: "512Mi" # 2x requests for burst cpu: "500m"

requests 应基于 P95 实测用量加 20% 缓冲设置，limits 给到 requests 的约 2 倍用于突发——避免 requests 虚高导致整集群利用率过低。

成本分配与 Tagging

标签策略

必选标签模板（Terraform）：

# Terraform - enforce tags variable "required_tags" { default = { environment = "prod" cost-center = "engineering" owner = "platform-team" project = "api-gateway" managed-by = "terraform" } } resource "aws_instance" "example" { ami = data.aws_ami.latest.id instance_type = "t3.medium" tags = var.required_tags }

推荐至少包含environment / cost-center / owner / project / managed-by五个维度，这是成本分摊报表能按团队、项目、环境切分的先决条件。

标签强制执行——AWS SCP 拒绝未打标资源：

// AWS SCP - Deny untagged resources { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyUntaggedEC2", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "Null": { "aws:RequestTag/cost-center": "true" } } } ] }

利用 SCP 的Null条件在创建实例时强制携带cost-center标签，从源头杜绝"孤儿资源"。这也对应 cloud-architect 技能 MUST DO 中"Enable cost allocation tags and monitoring"的约束。跨云场景下，multi-cloud.md 还给出了统一的跨云标签规范（environment/cost-center/owner/project/managed-by），供多云团队对齐。

成本分摊报表

AWS Cost and Usage Report（CUR）：

# Enable detailed billing reports aws cur put-report-definition \ --report-definition '{ "ReportName": "detailed-cost-report", "TimeUnit": "HOURLY", "Format": "Parquet", "Compression": "Parquet", "S3Bucket": "my-billing-bucket", "S3Region": "us-east-1", "AdditionalArtifacts": ["ATHENA"] }'

Athena 分析查询：

-- Cost by service and tag SELECT line_item_product_code as service, resource_tags_user_cost_center as cost_center, SUM(line_item_unblended_cost) as cost FROM cost_report WHERE month = '2024-01' GROUP BY 1, 2 ORDER BY 3 DESC; -- Unused Reserved Instances SELECT reservation_reservation_a_r_n, reservation_unused_quantity, reservation_unused_normalized_unit_quantity FROM cost_report WHERE reservation_unused_quantity > 0;

第二条查询可直接定位"买了但没用"的预留实例——预留利用率不达标通常是费率优化的最大浪费点。

自动化与治理

自动成本控制

AWS Budgets 预算告警（CloudFormation）：

# CloudFormation - Budget with auto-stop Resources: MonthlyCostBudget: Type: AWS::Budgets::Budget Properties: Budget: BudgetName: monthly-cost-limit BudgetLimit: Amount: 10000 Unit: USD TimeUnit: MONTHLY BudgetType: COST NotificationsWithSubscribers: - Notification: NotificationType: ACTUAL ComparisonOperator: GREATER_THAN Threshold: 80 Subscribers: - SubscriptionType: EMAIL Address: finance@company.com

预算达到 80% 即向财务邮箱发送告警，配合预算 Actions 可实现自动关停实例等治理动作。

非生产环境定时扩缩容（Dev/Test）：

# Stop non-prod resources nights/weekends Resources: ScaleDownSchedule: Type: AWS::AutoScaling::ScheduledAction Properties: AutoScalingGroupName: !Ref DevASG DesiredCapacity: 0 Recurrence: "0 20 * * MON-FRI" # 8 PM weekdays ScaleUpSchedule: Type: AWS::AutoScaling::ScheduledAction Properties: AutoScalingGroupName: !Ref DevASG DesiredCapacity: 3 Recurrence: "0 8 * * MON-FRI" # 8 AM weekdays

工作日 20:00 缩到 0、8:00 扩回 3，一个 Cron 表达式即可让开发环境每周节省约 60% 的常驻成本。Azure 侧对应做法是 VM 自动关机（auto-shutdown），见 azure.md 的 Compute Savings 章节。

成本异常检测

AWS Cost Anomaly Detection：

# Create anomaly monitor aws ce create-anomaly-monitor \ --anomaly-monitor '{ "MonitorName": "ServiceMonitor", "MonitorType": "DIMENSIONAL", "MonitorDimension": "SERVICE" }' # Create anomaly subscription aws ce create-anomaly-subscription \ --anomaly-subscription '{ "SubscriptionName": "CostAlerts", "MonitorArnList": ["arn:aws:ce::123456789:anomalymonitor/abc123"], "Subscribers": [{"Type": "EMAIL", "Address": "alerts@company.com"}], "Threshold": 100 }'

以 SERVICE 维度监控成本波动，超过 100 美元阈值即推送邮件告警，能够在预算被烧穿前介入。

成本指标与 KPI

没有度量就无法管理。以下 KPI 表可直接用于搭建成本看板：

成本效率看板 SQL 示例：

-- Cost efficiency dashboard metrics WITH metrics AS ( SELECT date_trunc('month', usage_date) as month, SUM(cost) as total_cost, SUM(CASE WHEN reservation_arn IS NOT NULL THEN cost END) as reserved_cost, COUNT(DISTINCT user_id) as active_users FROM cloud_costs GROUP BY 1 ) SELECT month, total_cost, reserved_cost / total_cost as reservation_coverage, total_cost / active_users as cost_per_user FROM metrics;

其中reservation_coverage对应上表的覆盖率 KPI，cost_per_user即单位成本 KPI 的一种落地形式。在 cloud-architect 技能 中还提供了直接可用的成本分析 CLI，例如用aws ce get-cost-and-usage按 SERVICE 维度拉取近 30 天 Top 成本项，或用az consumption usage list按资源组查看 Azure 花费，可作为快速识别成本驱动因素的第一步。

快速见效清单

本周即可实施的即时节省

• 删除未使用的 EBS 卷与快照
• 终止不再需要的已停止 EC2 实例
• 释放未使用的弹性 IP
• 删除未使用的负载均衡器
• 审查并删除旧 AMI

本月短期优化

• 对利用不足的实例执行 Right-Sizing
• 将 gp2 卷迁移到 gp3
• 实施 S3 生命周期策略
• 启用 S3 Intelligent-Tiering
• 为开发/测试环境配置定时启停

本季度中期治理

• 为常驻基线购买 Savings Plans
• 为可容错工作负载启用 Spot
• 建立成本分摊标签体系
• 启用 Cost Anomaly Detection
• 正式建立 FinOps 实践流程

在 claude-skills 中的使用方式

cost.md是 cloud-architect 技能 的五个参考文档之一（对应references/cost.md），与该技能的 aws.md、azure.md、gcp.md、multi-cloud.md 配套使用。在 Claude Code 中触发云成本优化相关需求时，该技能会按需加载此参考，并遵循其 Core Workflow 输出"成本估算与优化策略"，作为架构交付物的一部分。文中所有命令与配置均可直接复制到对应云平台的 CLI 或 IaC 工具中使用，前提是按需替换订阅 ID、卷 ID、ARN 等占位参数。

【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills