当一个 Serverless SaaS 平台从几千个 Lambda 函数增长到超过一百万个函数时，问题会从“函数怎么写”变成“系统怎么活”。来源摘要里提到的几个经验很关键：真正的 scale-to-zero、配额管理、多账户架构，以及尽早和 AWS 服务团队沟通。这些不是架构图上的装饰，而是大规模运行时避免账单失控、部署卡死和突发故障的基本功。
百万函数规模下，scale-to-zero 不是口号
Serverless 常被说成“按需付费”，但在 SaaS 场景里，只有函数本身按调用计费还不够。真正的 scale-to-zero 要看整条租户路径：
- 空闲租户是否仍占用预置并发、常驻连接、轮询任务或定时任务？
- 每个租户是否复制了一整套资源，而这些资源在无流量时仍产生固定成本？
- 部署系统是否会为每个租户持续维护状态，即使租户几周没有请求？
百万级 Lambda 函数最容易被忽视的是“低频但海量”的尾部成本。一个函数闲着不贵，一百万个资源周边的日志、告警、事件规则、权限策略、构建元数据和部署记录就不再便宜。
可以这样实践：把“是否能归零”作为租户资源设计的验收条件，而不是成本优化阶段才补救。
# tenant-scheduler.yml
# 示例：仅在需要时启用租户级 EventBridge 规则，空闲租户禁用定时触发
# 需要替换：<account-id>、<region>、<function-name>
Resources:
TenantWakeupRule:
Type: AWS::Events::Rule
Properties:
State: DISABLED
ScheduleExpression: rate(5 minutes)
Targets:
- Arn: arn:aws:lambda:<region>:<account-id>:function:<function-name>
Id: tenant-wakeup-target
PermissionForEventsToInvokeLambda:
Type: AWS::Lambda::Permission
Properties:
FunctionName: <function-name>
Action: lambda:InvokeFunction
Principal: events.amazonaws.com
SourceArn: !GetAtt TenantWakeupRule.Arn
这个 YAML 不是说来源文章使用了这个精确模板，而是一个可改造的实践方向：默认禁用空闲租户的周期性触发，把唤醒逻辑放到明确的租户状态变更里。
配额管理要从“报错后申请”改成“持续观测”
Lambda、IAM、CloudWatch Logs、EventBridge、CloudFormation、API Gateway、VPC 相关资源都有配额。多账户 SaaS 可以分散压力，但不会让配额问题消失。规模上来后，真正危险的不是某个配额太低，而是团队不知道自己离哪条线最近。
来源摘要提到 quota management，这是大规模 Serverless 平台的核心运行能力。你需要把配额当成生产指标：定期采集、趋势化、告警、提前申请提升，并把部署系统和配额状态联动。
可以这样实践：用 AWS CLI 拉取 Service Quotas，把关键配额纳入 CI 或每日巡检。下面脚本会列出 Lambda 的部分配额，便于你扩展成告警任务。
#!/usr/bin/env bash
set -euo pipefail
REGION="${AWS_REGION:-us-east-1}"
SERVICE_CODE="lambda"
echo "Checking Lambda quotas in ${REGION}"
aws service-quotas list-service-quotas \
--region "${REGION}" \
--service-code "${SERVICE_CODE}" \
--query 'Quotas[].{Name:QuotaName,Code:QuotaCode,Value:Value,Adjustable:Adjustable}' \
--output table
运行前需要配置 AWS 凭证，并安装 AWS CLI：
export AWS_REGION=us-east-1
bash check-lambda-quotas.sh
更进一步，可以把结果写入指标系统，并给“剩余空间”设阈值。例如部署系统准备创建 50,000 个函数时，不应该等 CloudFormation 失败才发现账户或区域配额不够。
多账户不是隔离魔法，需要运营系统兜底
多账户 SaaS 的价值很明确：隔离租户、分摊配额、降低单账户爆炸半径、让团队能按环境或租户类型治理资源。但账户越多，控制面复杂度也会上升。
需要提前设计的不是“怎么创建更多账户”，而是这些问题：
- 每个账户的用途和生命周期是什么？
- 账户、区域、租户之间如何映射？
- 部署失败后如何回滚或重试？
- 哪些配额是账户级，哪些是区域级，哪些会影响跨账户共享服务？
- 日志、追踪、告警如何集中检索？
百万函数规模下，手工排查单个账户已经不现实。你需要一个控制平面记录资源归属：租户 ID、账户 ID、区域、函数名前缀、部署版本、最近调用时间、是否可下线。没有这张“资源账本”，清理闲置资源和判断影响面都会变得很慢。
可以这样实践：给函数打上稳定标签，并在巡检脚本中按标签扫描。
#!/usr/bin/env bash
set -euo pipefail
REGION="${AWS_REGION:-us-east-1}"
TENANT_ID="${TENANT_ID:?set TENANT_ID first}"
aws resourcegroupstaggingapi get-resources \
--region "${REGION}" \
--tag-filters "Key=tenant_id,Values=${TENANT_ID}" \
--resource-type-filters lambda:function \
--query 'ResourceTagMappingList[].ResourceARN' \
--output text
这类脚本简单，但在多账户环境里很有价值。它能让你从“我记得函数叫某某”转为“控制平面能精确回答某个租户拥有哪些资源”。
尽早找 AWS 服务团队，不是到事故时才开工单
来源摘要里有一个容易被低估的经验：early engagement with AWS service teams saved them from outages。到了百万函数规模，你可能会踩到普通文档里很少详细讨论的行为边界：控制面吞吐、批量部署速率、区域级限制、日志写入模式、服务内部保护机制。
这不意味着把架构风险外包给云厂商，而是要把云服务团队当成容量规划的一部分。你可以准备这些材料去沟通：
- 当前资源数量、增长曲线和目标规模；
- 每日部署峰值、每分钟创建或更新函数数量；
- 多账户和多区域分布；
- 最关键的业务时段和不可接受的失败模式；
- 已知配额、已申请提升、仍不确定的服务边界。
沟通越早，越可能在上线前发现隐性瓶颈。等到部署管道在生产高峰期被限流，补救成本会高很多。
落地检查表：别等百万函数时再补课
准备把 Serverless SaaS 做到大规模时，可以用这份清单压一下风险：
- 空闲租户路径是否真正 scale-to-zero？
- 是否持续采集 Lambda 及周边服务配额？
- 部署系统是否会在配额不足时提前阻断？
- 多账户映射、标签、资源账本是否稳定？
- 是否能按租户快速列出函数、日志、告警和版本？
- 是否和 AWS 服务团队提前沟通过增长曲线和控制面压力？
- 是否有批量清理、批量回滚、批量禁用触发器的工具？
Serverless 的优势仍然成立：少管服务器、弹性好、按需扩展。但规模越大，越不能只看单个函数的开发体验。百万 Lambda 函数背后真正需要工程化的是控制平面、配额、账户治理和归零能力。把这些能力提前做成系统，Serverless 才能从“省运维”走到“能运营”。