summary
2024-07-30，us-east-1 一个专供 AWS 内部服务使用的 Kinesis Data Streams 单元（cell）在例行部署期间出现异常。该单元刚迁移到新架构，且承载着一种特殊负载画像：数量极多、单 shard 吞吐量极低的 shard。单元管理系统（按吞吐量均衡工作）未能把这些低吞吐 shard 有效分散，少数主机承接了过量 shard，其定期上报的状态消息体积异常膨胀，无法被管理系统及时接收与处理。管理系统将延迟误判为主机故障，触发快速重分发，形成重分发风暴，并冲击了为 Kinesis 数据面提供安全连接供给的关键子系统，导致该 cell 降级，进而连锁影响 CloudWatch Logs、ECS/Fargate、Lambda、Redshift、Glue 等。
timeline
09:09 PDT 在单 AZ 启动例行部署（先不影响业务），取放主机触发隐患。14:45 PDT 部分 AWS 服务开始错误率升高。17:39 PDT 出现初步改善，19:21 PDT 显著恢复，21:37 PDT 全部恢复。CloudWatch Logs 与 S3 事件 backlog 清理更久（分别至 07-31 05:50、08-01 02:38 PDT）。
root_cause
新单元管理系统对低吞吐/高数量 shard 的负载画像处理不当，造成 shard 分配极度不均与状态消息膨胀；状态处理延迟被误判为故障，触发雪崩式重分发并拖垮连接供给子系统。
amplifiers
① 负载画像假设偏颇：系统按吞吐量均衡，未覆盖海量低吞吐 shard。② 误判放大：状态延迟被当成主机故障引发重分发风暴。③ 关键子系统无隔离：连接供给被重分发风暴拖垮。④ 依赖面广：CloudWatch/ECS/Lambda 等深度依赖 Kinesis。⑤ backlog 清理长尾。
mitigation
通过卸载低时效内部负载与为连接供给子系统增加容量来 mitigation；在 us-east-1 及其他新架构区域增加数据面连接容量、引入负载卸载工具并调整连接上限；后续改进单元管理系统对这种负载画像的处理。
lessons
资源调度系统必须覆盖极端负载画像（海量小对象）；健康信号延迟不应直接触发大规模重分发；关键供给子系统需独立容量与隔离；长尾 backlog 要有可预期清理 SLA。
checklist
① 单元管理系统增加低吞吐高数量 shard 的处理策略。② 健康延迟与真实故障解耦（多次确认再重分发）。③ 连接供给子系统独立扩容。④ 新增负载卸载工具与连接限流。