亚马逊云科技概要介绍了某客户如何将 Lambda 函数扩展至 100 万个

亚马逊云科技概要介绍了工业可穿戴设备制造商 ProGlove 如何扩展其 SaaS 平台，以运行分布在数千个专属客户账户中的超过 100 万个 AWS Lambda 函数。在亚马逊云科技架构博客的一篇文章中，该团队将其成功归功于“每个租户一个账户”的模式、借助 CloudFormation StackSets 实现的广泛自动化，以及激进的“缩减至零”策略（可以将闲置成本控制在每个账户每个月 1 美元以下）。ProGlove 选择将每位客户隔离在各自的 AWS 账户中，以额外的运维开销为代价换取更强的安全边界、独立的服务配额，以及清晰的按客户分摊成本的机制。亚马逊云科技指出，当平台账户数量超过 50 个后，这一决策导致了运维摩擦。每个客户账户内包含若干微服务，通常是 5 到 15 个 Lambda 函数，由 Step Functions 状态机进行协调。该状态机负责采集扫描器读数，将其持久化到 Amazon DynamoDB 中，并将业务事件发布到共享的 Amazon EventBridge 总线，供 ProGlove 的分析平台消费。手动配置不仅拖慢了发布速度，还暴露了服务配额上限的问题。因此，工程师们将 AWS Organizations、Step Functions 和 CloudFormation StackSets 整合为一个工作流，通过单个管道创建和更新每个账户。该团队表示，与亚马逊云科技服务工程师的合作提升了 StackSet 的吞吐量，使得该机制能够将变更同步到数千个账户中，其中合计托管着超过一百万个 Lambda 函数。图片来源：亚马逊云科技亚马逊云科技报告称，配额并非唯一的扩展挑战。早期 cron 风格的调度会在所有账户中于同一时间触发同一函数，这会引发工程师们所描述的“自酿” DDoS 攻击。他们用抖动执行窗口和事件驱动的触发器取代了僵化的定时器，从而平滑了各区域的负载，而且不需要依赖预留并发数或预配置容量。可观测性成本也呈现出类似的走势。每个 Lambda 函数都会生成日志和指标；乘以数千个账户后，由此产生的体量几乎占据了账单的绝大部分。ProGlove 将高优先级的故障整合到了一个中央死信队列中，并删除了未使用的 Amazon SQS 队列。根据博文所述，这些变更将每个账户的闲置支出降到了 1 美元以下。其他地方也出现了类似的运维问题。Capital One 指出，标准化部署、可观测性和治理实践对于在大型组织中一致地运行 Lambda 工作负载至关重要，并且认为，技术规模的扩展还需要运维标准化的支持。亚马逊云科技的这篇博文还指出，自动化本身也做了一些权衡取舍。StackSet 的部署速度仍然慢于单账户的 CloudFormation 部署，而日志集中化则在一定程度上降低了部分租户级粒度。鉴于在隔离性、成本透明度和运维一致性方面带来的改进，团队认为这些取舍是可以接受的。ProGlove 的经验揭示了一种模式：首先采用强制执行硬边界的租户模型，尽早自动化所有基础设施操作，并将可观测性方面的投入视为首要的扩展约束。DoorDash 的无服务器迁移案例也体现了类似的主题，约束严格的自动化确保了每日超过一千万次的 API 调用没有超出并发限制。尽管具体策略各不相同，但其共同点在于：远在容量紧张的问题出现之前，成本和配额的可见性就已经促成了架构选择。原文链接：https://www.infoq.com/news/2026/07/aws-lambda-1m/