亚马逊云代金券 AWS 充值异常报警系统

一、别让AWS账单变成每月一次的恐怖片

上个月发工资那天，我正啃着煎饼果子刷手机，突然弹出一条钉钉消息：「【紧急】AWS账户余额低于500元，近24小时支出飙升370%」。我手一抖，煎饼里的辣酱糊了半截袖子——不是心疼衣服，是心疼那笔刚冒头的$2,846.32账单。

这哪是云服务？分明是台印钞机，还带自动续费+隐形加价功能。后来翻账单才发现：一个被遗忘的测试环境EC2实例，因Auto Scaling策略写错，半夜自动扩到16台c5.4xlarge；RDS备份保留期被误设为999天；更绝的是，某同事用CLI跑了个脚本，把S3桶里3TB历史日志全复制了三遍……

于是我们痛定思痛，搞出了「AWS充值异常报警系统」——不靠人盯，不靠运气，靠规则、靠自动化、靠凌晨三点还能准时骂醒你的告警。

二、报警不是吼得响，而是听得懂

很多团队一上来就堆告警：CPU超80%、磁盘满90%、请求延迟＞500ms……结果运维群天天像过年放鞭炮。真正的充值异常报警，核心就仨字：反常识。

亚马逊云代金券 我们筛出五类高危信号：

1. 账户级突变

• 24小时支出环比增幅＞150%（基线取过去7天日均值，排除周末/大促干扰）
• 单日支出突破月度预算的40%（比如预算$5000，当天花超$2000立刻拉响）
• 未关联预算的账户突然产生费用（新创建账户或被黑客盗用的典型征兆）

2. 服务级暴走

• EC2按需实例数量2小时内增长＞300%（比看CPU更早发现扩缩容失控）
• S3存储量日增＞500GB且无对应生命周期策略（日志疯长、备份套娃的铁证）
• RDS备份存储占用＞总数据量的3倍（默认保留7天？你设成999天还敢叫默认？）

3. 隐形成本刺客

• 跨区域数据传输费用单日超$100（提醒你检查是否误配了全球加速器或错误的VPC对等连接）
• Lambda执行次数日增200%但错误率＜0.1%（大概率是定时任务没关，或有人把cron表达式写成*/1 * * * *）

注意：所有阈值都支持按标签动态调整。比如给「prod」环境设更严的规则，「dev」环境放宽3倍——毕竟开发小哥删库前总得先请示下咖啡机。

三、四步搭建，不写一行前端代码

整个系统跑在AWS原生服务上，零外部依赖，成本约$0.87/月（Lambda冷启动+CloudWatch规则+少量SNS流量）。以下是实操步骤：

Step 1：喂饱CloudWatch的「钱袋子」

AWS Cost Explorer API默认只提供每日粒度数据，但我们要求每15分钟刷新一次账单快照。解决方案：用Lambda + Cost Explorer的get-cost-and-usage接口，配合Time Granularity设为DAILY但日期范围缩至最近2天，再用Python Pandas算同比/环比——别嫌麻烦，这一步省了，后面全是玄学告警。

Step 2：告警逻辑藏在Metric Filter里

直接在CloudWatch里建告警太僵硬？我们把判断逻辑下沉到Log Group。例如：当Lambda消费Cost数据后，把计算结果以结构化JSON打到/aws/lambda/cost-analyzer日志流，内容含{"account_id":"123456789","spike_rate":217.5,"service":"EC2"}。再用Metric Filter提取spike_rate > 150，生成自定义指标CostAnomalyRate——这样改规则只需改Filter正则，不用动告警配置。

Step 3：Lambda当「财务侦探」

告警触发后，Lambda不干嚎，先查证：调用describe-instances找新增实例、list-buckets扫S3增长源头、describe-db-instances揪RDS备份陷阱。最狠的是它会自动生成诊断报告，附带「一键止损」按钮链接（其实是预签名的API Gateway URL，点开直接调用stop-instances或put-lifecycle-configuration）。

Step 4：通知要分层，别把老板和实习生一起吓哭

• Level 1（普通异常）：企业微信发摘要+跳转Cost Explorer链接
• Level 2（高危暴增）：电话+短信双呼值班人（用SNS直接集成Twilio）
• Level 3（疑似入侵）：自动邮件抄送CTO+安全团队，并冻结该账户的IAM用户密钥（调用update-access-key --status Inactive）

四、那些年我们填过的坑

坑一：时区陷阱——Cost Explorer返回的时间戳是UTC，但我们按北京时间做日切。有次凌晨3点触发告警，排查发现是UTC时间07:00对应北京15:00，系统误判为「当日超支」。解决方案：所有时间计算统一转为UTC+0，再用datetime.now(timezone.utc)校准。

坑二：免费额度干扰——新账号前12个月有EC2免费层，但告警总在第13个月首日误报。后来发现CloudWatch指标里EstimatedCharges包含已扣减的免费额度，而我们要监控的是ActualCharges。改用Cost Explorer的UnblendedCost字段才稳住。

坑三：告警风暴——某次S3桶被误设为public，爬虫疯狂读取，触发200+条告警。我们在SNS主题加了MessageDeduplicationId，并让Lambda聚合10分钟内同类事件，只发一条含Top3罪魁祸首的汇总消息。

五、比报警更狠的，是让它自己省钱

系统上线三个月后，我们加了个「省钱彩蛋」：当检测到连续7天EC2利用率＜10%，自动发起RI建议（调用get-reserved-instances-exchange-candidates），并邮件推送「买3年m5.large可省$1,240」的精准报价。上个月，这个功能帮公司锁定了$8,700的年度节省。

最后说句实在话：报警系统不是万能的，但它能把「月底惊魂」变成「周一晨会谈优化」。毕竟，云成本管理的终极目标，不是少花钱，而是让每一分钱都花得理直气壮——比如你指着报表说：「看，这$3.27是给AI训练GPU的，它刚帮你省了27小时人工审核时间。」

此时，煎饼果子的辣酱，终于可以安心抹在饼上了。