AWS为A系列初创企业制定的财务运营指南：产品在市场环境中取得成功后会出现的8种成本变化模式

# 检查当前的跨区域数据传输费用
aws ce get-cost-and-usage \
  --time-period Start=\((date -d 'last month' +%Y-%m-01),End=\)(date +%Y-%m-01) \
  --granularity MONTHLY \
  --filter '{"Dimensions": {"Key": "USAGE_TYPE", "Values": ["DataTransfer-Regional-Bytes"]}}'  \
  --metrics UnblendedCost \
  --query 'ResultsByTime[0].Total.UnblendedCost.Amount' \
  --output text

如何找出哪些容器是导致跨区域数据传输现象的原因？：

# 查看你的RDS数据库实例位于哪个可用区内
aws rds describe-db-instances \
  --query 'DBInstances[*].{ID:DBInstanceIdentifier,AZ:AvailabilityZone}' \
  --output table

# 查看你的应用程序容器运行在哪些可用区内
kubectl get pods -o wide -n production | awk '{print $7}' | sort | uniq -c

如果你的RDS数据库位于us-east-1a可用区，而60%的应用程序容器却分布在us-east-1b和us-east-1c可用区内，那么你就遇到了跨区域数据传输的问题。

解决方法——基于拓扑结构的路由机制

# topology-aware-routing.yaml
# 这段配置告诉Kubernetes优先将容器调度到与发起请求的节点位于同一可用区内，从而确保数据传输在本地完成
apiVersion: v1
kind: Service
metadata:
  name: payment-api
  namespace: production
  annotations:
    # 在可能的情况下，将流量路由到与调用者位于同一可用区的容器上
    service.kubernetes.io/topology-mode: "Auto"
spec:
  selector:
    app: payment-api
  ports:
  - port: 8080
    targetPort: 8080

# 对于容器本身而言，虽然应该将它们分散部署在多个可用区内，但仍然应优先选择在本地进行数据传输
# topologySpreadConstraints可以确保容器的均匀分布，
# 而 topology-aware routing则能保证数据流量始终在同一个可用区内流动
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: payment-api

对于数据库流量而言，建议将原本使用单可用区的RDS系统迁移到Aurora平台上。Aurora会内部处理跨可用区的路由逻辑，因此你的应用程序无需承担任何跨区域数据传输的费用。

每月可节省的费用： 根据数据库查询量以及容器在不同区域的分布情况，每月可节省500至6,000美元。

模式6：gp2存储卷的陷阱

2014年，AWS推出了gp2类型的EBS存储卷；2020年，他们又推出了gp3类型——这种存储卷价格更低、速度更快，且基础性能也更好。然而到了2026年，大多数处于发展阶段的公司仍然在使用gp2存储卷。

两者之间的区别在于：gp2存储卷的费用为0.10美元/GB/月，每GB提供3 IOPS的吞吐量（最低为100 IOPS）；而gp3存储卷的费用为0.08美元/GB/月，无论容量大小如何，都能提供3,000 IOPS的吞吐量。对于大多数容量的情况来说，gp3存储卷的价格便宜20%，IOPS性能也快了10倍。进行迁移操作时，系统可以在线运行——也就是说，在存储卷仍然被使用的情况下，就可以完成迁移过程。

查找你所有的gp2存储卷：

# 列出账户中所有gp2存储卷的信息，包括其容量和每月费用
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{
    ID:VolumeId,
    Size:Size,
    State:State,
    MonthlyCost_USD:Size
  }' \
  --output table

# 统计总共有多少个gp2存储卷以及它们的总容量
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'length(Volumes)' --output text

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'sum(Volumes[*].Size)' --output text

解决方案：通过一个脚本将所有gp2存储卷迁移到gp3类型

#!/bin/bash
# migrate_gp2_to(gp3.sh
# 该脚本用于将所有gp2类型的存储卷迁移到gp3类型。整个迁移过程是在线进行的，因此不会导致任何停机时间。
# 每个迁移操作都是异步执行的，因此存储卷在整个迁移过程中仍然可以正常使用。

echo "开始将gp2存储卷迁移到gp3类型..."
# 获取所有gp2存储卷的ID
VOLUMES=$(aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].VolumeId' \
  --output text)

COUNT=0
for VOL_ID in $VOLUMES; do
  echo "正在将$VOL_ID存储卷迁移到gp3类型..."
  aws ec2 modify-volume \
    --volume-id $VOL_ID \
    --volume-type gp3 \
    --no-cli-pager
  COUNT=$((COUNT + 1))
done

echo "已有$COUNT个存储卷开始迁移过程。"
echo "整个迁移过程是在线进行的，因此不会导致任何停机时间。请随时查看迁移进度："
echo "aws ec2 describe-volumes-modifications --query 'VolumesModifications[*].{ID:VolumeId,State:ModificationState}'"

验证迁移是否完成：

# 检查是否还有gp2类型的存储卷存在
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'length(Volumes)' \
  --output text
# 预期结果：0

每月可节省的费用： 相当于你总EBS使用费用的20%。如果你的EBS月费用为10,000美元，那么通过这次迁移，你可以节省2,000美元——这些钱相当于可以让你的业务多运行30分钟。

模式7：无限量的日志堆积问题

CloudWatch中的日志组默认会永久保留日志数据。因此，如果没有为某个日志组设置明确的保留期限，那么这些日志就会被无限期地保存下来。对于那些业务量较大的公司来说，这意味着他们可能会保存从2022年以来产生的各种调试日志，而这些日志可能自创建以来就再没人看过。

这些成本会悄然累积。CloudWatch对日志存储收取0.03美元/GB/月的费用，而对日志导入则收取0.50美元/GB的费用。如果一个集群每天产生50GB的日志，那么每天需要导入25GB的日志，每月共计750GB的日志需要被存储起来，而随之而来的存储成本也会逐月增加。

查找没有设置保留策略的日志组：

# 列出所有带有保留设置的日志组
# 任何显示“retentionInDays: null”的日志组的保留期限都是永久的，即这些日志永远不会被删除
aws logs describe-log-groups \
  --query 'logGroups[*].{Name:logGroupName,RetentionDays:retentionInDays,StoredBytes:storedBytes}' \
  --output table | grep -E "(None|null)"

# 统计没有设置保留策略的日志组的数量
aws logs describe-log-groups \
  --query 'length(logGroups[?retentionInDays==`null`])' \
  --output text

解决方法——批量设置保留策略：

不同类型的日志有着不同的合规性要求。调试日志不需要长期保存，而审计日志可能需要保留365天。下表列出了一些合理的默认设置：

#!/bin/bash
# set_log_retention.sh
# 为所有没有设置保留策略的日志组设置30天的保留期限
# 根据不同类型的日志组，可以调整相应的保留期限

echo "正在为没有设置保留期限的日志组设置保留策略..."

# 获取所有没有设置保留策略的日志组
aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].logGroupName' \
  --output text | tr '\t' '\n' | while read LOG_GROUP; do

  # 跳过CloudTrail日志——这些日志需要更长的保留期限以满足SOC2标准
  if echo "$LOG_GROUP" | grep -qi "cloudtrail"; then
    echo "跳过日志组：$LOG_GROUP"
    aws logs put-retention-policy \
      --log-group-name "$LOG_GROUP" \
      --retention-in-days 365
    continue
  fi

  # 为其他所有日志组设置30天的保留期限
  echo "正在为日志组$LOG_GROUP设置30天的保留期限"
  aws logs put-retention-policy \
    --log-group-name "$LOG_GROUP" \
    --retention-in-days 30
done

echo "操作完成。CloudWatch会自动删除超过保留期限的日志。"

每月能节省的费用：存储成本可减少500美元到2,000美元不等。当减少不必要的调试日志记录时，导入日志的成本也会立即降低。而且，随着旧日志逐渐被删除，存储成本的节约效果会在30到90天内更加明显。

模式8：被“抛弃”的资源收集器

每一位离职的工程师都会留下一些“痕迹”：某个被终止的实例上仍挂有EBS卷；某个已分配但未被关联到任何实例的Elastic IP；某个在第三季度就被弃用的服务前仍然配置着负载均衡器；还有那些已被替换的RDS实例的旧快照……这些情况都不是有意造成的，但它们都会被计入费用。

为了解决这个问题，我们采用了每周进行一次自动审计的方法。而不是人工检查——而是编写一个自动化脚本，在每个周日晚上运行，该脚本会找出那些“无处可去”的资源，并通过Slack发送消息，列出需要删除的资源清单。

如何找到这些“无主资源”：

# 未关联的EBS卷——你正在为这些空荡荡的存储空间支付费用
aws ec2 describe-volumes \
  --filters Name='status', Values='available' \
  --query 'Volumes[*].{ID:VolumeId, Size:Size, Created:CreateTime, MonthlyCost:Size}' \
  --output table

# 未关联的Elastic IP——如果没有连接到正在运行的实例，每个的成本为3.60美元/月
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' \
  --output table

# 过期的快照——创建时间超过90天，已经不再需要了
aws ec2 describe-snapshots \
  --owner-ids self \
  --query "Snapshots[?StartTime<='$(date -d '90 days ago' --iso-8601=seconds)'].[SnapshotId,StartTime,VolumeSize]" \
  --output table

# 闲置的负载均衡器——虽然处于激活状态，但并没有转发任何流量
aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[*].{ARN:LoadBalancerArn,DNS:DNSName,State:State.Code}' \
  --output table

每周自动清理的Lambda函数：

# orphan_resource_reporter.py
# 每个周日晚上20:00通过EventBridge执行
# 将找到的“无主资源”信息发送到Slack，但不会自动删除这些资源
# 是否删除这些资源需要人工决策，这个Lambda函数只是列出需要处理的资源清单。

import boto3
import json
import urllib.request
from datetime import datetime, timedelta, timezone

SLACK_WEBHOOK_URL = 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'

def get_orphaned_resources():
    """收集所有“无主”的AWS资源及其预估的每月费用。”“
    ec2 = boto3.client('ec2')
    elbv2 = boto3.client('elbv2')
    report = {'total_monthly_waste': 0, 'resources': []}

    # 未关联的EBS卷（gp3类型卷的每月费用为0.08美元/GB）
    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'status', 'Values': ['available']}]
    )['Volumes']
    for vol in volumes:
        monthly_cost = round(vol['Size'] * 0.08, 2)
        report['resources'].append({
            'type': 'Unattached EBS Volume',
            'id': vol['VolumeId'],
            'detail': f"{vol['Size']}GB {vol['VolumeType']}",
            'monthly_cost': monthly_cost
        })
        report['total_monthly_waste'] += monthly_cost

    # 未关联的Elastic IP（每个的成本为3.60美元/月）
    addresses = ec2.describe_addresses]['Addresses']
    for addr in addresses:
        if 'AssociationId' not in addr:
            report['resources'].append({
                'type': 'Unassociated Elastic IP',
                'id': addr['AllocationId'],
                'detail': addr['PublicIp'],
                'monthly_cost': 3.60
            })
            report['total_monthly_waste'] += 3.60

    # 创建时间超过90天的快照
    cutoff = (datetime.now(timezone.utc) - timedelta(days=90)).isoformat()
    snapshots = ec2.describe_snapshots(OwnerIds=['self'])['Snapshots']
    old_snapshots = [s for s in snapshots if s['StartTime'].isoformat() < cutoff]
    for snap in old_snapshots:
        monthly_cost = round(snap.get('VolumeSize', 0) * 0.05, 2)
        report['resources'].append({
            'type': 'Old Snapshot (90+ days)',
            'id': snap['SnapshotId'],
            'detail': f"Created {snap['StartTime'].strftime('%Y-%m-%d')}",
            'monthly_cost': monthly_cost
        })
        report['total_monthly_waste'] += monthly_cost

    return report

def post_to_slack(report):
    """将找到的“无主资源”信息发送到Slack。”“
    resource_lines = '\n'.join([
        f"• {r['type']} `{r['id']}` — {r['detail']} — *${r['monthly_cost']}/month*"
        for r in report['resources']
    ])

    message = {
        'text': (
            f":money_with_wings: *每周“无主资源”报告*\n\n"
            f"共找到了*{len(report['resources'])}个“无主资源”，\n\n"
            f>它们的总费用为*${report['total_monthly_waste']:.2f}/月*\n\n"
            f"{resource_lines}\n\n"
            f>请查看这些列表，然后删除那些不再需要的资源吧。」
        )
    }
    
    req = urllib.request.Request(
        SLACK_WEBHOOK_URL,
        data=json.dumps(message).encode(),
        headers={'Content-Type': 'application/json'}
    )
    urllib.request.urlopen(req)

def lambda_handler(event, context):
    report = get_orphaned_resources()
    post_to_slack(report)
    return {
        'resources_found': len.report['resources')),
        'monthly_waste': report['total_monthly_waste']
    }

每月可节省的费用： 500至2,000美元。每位离职的工程师通常会留下50至200美元的“闲置资源”。如果一个团队有30名成员，且人员流动率为30%，那么这些闲置资源的数量会迅速增加。

全部节省措施汇总

>

>

>

>

>

>

>

>

>

参考资源

• FinOps基础框架 —— 本指南所依据的实践框架，涵盖了云成本管理的规划、优化和运营三个阶段。

• AWS Cost Explorer API参考手册 —— 本指南中使用的get-cost-and-usage命令的完整使用说明。

• AWS计算优化服务 —— AWS提供的资源调整推荐服务，可结合本指南中的建议来优化EC2和EBS资源的配置。

• AWS VPC端点文档 —— 用于推荐措施3的各类VPC端点的详细信息列表。

• AWS实例调度解决方案 —— AWS提供的CloudFormation模板，可用于推荐措施2中涉及的环境调度任务。

• Karpenter工具文档 —— 适用于那些希望进一步探索动态节点配置和灵活使用Spot实例的团队的资源。

• FinOps基础资源库 —— 一个由业界专家共同维护的资源库，其中包含了许多实用脚本和最佳实践资料。

Ayobami Adejumo 是一位资深平台工程师兼FinOps领域的专家。他曾经为30多家处于A轮融资阶段的公司审核过他们的AWS基础设施架构，并为FinOps Foundation的资产库贡献了多种实用工具。