亚马逊AWS官方博客
Amazon EFS 目录级配额监控:多租户 SaaS方案
摘要:Amazon EFS 不提供原生目录级配额能力。本文基于 AWS Lambda 双层 fan-out 架构与 Amazon EventBridge,给出按客户/项目两级目录粒度的存储用量监控方案,涵盖架构设计、完整代码、部署命令及成本分析。
一、引言
Amazon EFS 不提供原生的目录级配额能力,本文给出一种基于 AWS Lambda 双层 fan-out 架构与 Amazon EventBridge 的轻量监控方案,按“客户/项目”两级目录粒度持续追踪用量,并在接近或超出阈值时将状态交给下游系统处理。
二、背景与需求
许多 SaaS 平台采用一套 Amazon EFS 文件系统承载全部租户数据,目录按 /{customer}/{project}/ 两级组织。
Amazon EFS 本身不提供目录级别的配额能力:
- Amazon EFS 不支持对单个目录设定存储配额,其 Access Point 仅做路径隔离与 POSIX 权限映射,无法限制容量
- Amazon CloudWatch 提供的 StorageBytes 指标是整个文件系统的总容量,无法细分到某个客户或项目目录
因此需要在 Amazon EFS 之外自建一套轻量的监控方案。具体要求:
- 以”客户 / 项目”两级目录为最小监控单元,分别统计真实磁盘占用
- 配额阈值可灵活调整,新增客户或项目时无需改动监控逻辑
三、总体架构
方案采用双层 AWS Lambda fan-out 架构,如架构图 1 所示:
- Dispatcher Lambda(调度层):Amazon EventBridge 按设定频率(默认每小时)触发。该函数通过 Amazon EFS Access Point 只读挂载文件系统根目录,扫描第一层目录得到客户列表,然后为每个客户异步调用一个 Worker Lambda 实例。
- Worker Lambda(扫描层):每个实例负责一个客户目录,遍历该客户下所有项目目录并用 du -s 统计大小,完成后上报 Amazon CloudWatch 指标并将配额状态推送给下游处置系统。
[图1] |
架构图说明:① Amazon EventBridge 按设定频率触发 Dispatcher Lambda;② Dispatcher 通过 EFS Access Point 只读挂载根目录,扫描得到客户列表;③ Dispatcher 为每个客户异步 invoke 一个 Worker Lambda;④ 各 Worker 并行挂载 EFS,用 du -s 统计该客户下各项目目录大小;⑤ Worker 将结果写入 CloudWatch 自定义指标,并可选推送 Webhook 通知下游系统。
相比单层架构,双层 fan-out 设计有两个优势:
1. 并行扫描:各客户目录同时扫描,总耗时取决于最慢的单个客户而非所有客户之和
2. 天然可扩展:客户数增长时 Dispatcher 多发几个 invoke 即可,单个 Worker 永远只处理一个客户,不存在超时风险
网络链路上,两层 Lambda 函数均部署在同一 Amazon VPC 的私有子网内,通过 NFS 端口 2049 在内网挂载 Amazon EFS;推送状态走 HTTPS 443,是否需要 NAT 网关取决于下游系统的位置,部署章节会展开说明。
四、实现与部署
本节先讲两层函数的实现逻辑,再给出从零部署到 AWS 的完整命令。
4.1 Dispatcher Lambda:调度层
Dispatcher 的职责很简单:扫描 EFS 根目录得到客户列表,为每个客户异步调用 Worker。它本身不做 du 统计,耗时通常在秒级。
InvocationType=’Event’ 是关键:Dispatcher 不等待 Worker 返回,发完即结束。AWS Lambda 服务会为每个客户创建独立的 Worker 实例并行执行。
4.2 Worker Lambda:扫描层
Worker 接收 Dispatcher 传入的客户名,挂载 EFS 后扫描该客户下所有项目目录。核心逻辑是对每个项目调用 du -s 统计字节数,扫描完成后将结果写入 Amazon CloudWatch 自定义指标。下游对接(Webhook、告警等)可根据实际需求在此基础上扩展。
Worker 的设计要点:
- 每次调用只处理一个客户目录,天然避免了 Lambda 超时问题
- 配置参数由 Dispatcher 通过 event payload 传入,Worker 本身无需预设环境变量
- 扫描结果写入 CloudWatch 指标后即完成;如需通知业务系统(Webhook、SNS、SQS 等),可在 lambda_handler 末尾按需扩展
4.3 部署到 AWS
理清实现后,通过 AWS 命令行逐步部署。整个过程依次创建监控专用的 Amazon EFS Access Point、最小权限的 IAM 角色、Amazon VPC 网络与安全组、两个 AWS Lambda 函数,以及 Amazon EventBridge 定时规则。下文命令中的文件系统 ID、Amazon VPC、子网、安全组等均为示例值,使用时请替换为实际环境取值。部署前需具备以下条件:
- 已有一套 Amazon EFS 文件系统,且 Amazon VPC 私有子网内已就绪对应的 Amazon EFS 挂载目标
- 业务系统提供一个可接收 HTTP POST JSON 的 API 端点(若采用 Webhook 接入方式)
- 已配置具备相应权限的 AWS 命令行环境
4.3.1 第一步:创建监控专用 Access Point
为监控函数单独创建一个挂载到根目录的 Amazon EFS Access Point,使其能遍历所有客户与项目目录。Dispatcher 和 Worker 共用同一个 Access Point:
4.3.2 第二步:创建最小权限 IAM 角色
双层架构需要两个 IAM 角色。Dispatcher 除基本权限外还需要 lambda:InvokeFunction 来调用 Worker;Worker 需要 Amazon EFS 只读挂载和 Amazon CloudWatch 写入权限。
4.3.3 第三步:配置网络与安全组
两层 Lambda 函数均部署在 Amazon VPC 私有子网内,需要打通两条网络链路:经 NFS 端口 2049 在同 Amazon VPC 内网访问 Amazon EFS 挂载目标;经 HTTPS 443 访问下游处置系统端点和 AWS Lambda 服务 API(用于 Dispatcher 调用 Worker)。
Dispatcher 调用 Worker 时走 AWS Lambda 服务 API(HTTPS 443),该请求通过 NAT 网关或 VPC Endpoint 出网。如果下游业务系统也位于公网,Lambda 所在子网需要配置 NAT 网关。
4.3.4 第四步:部署 Worker Lambda
先部署 Worker,因为 Dispatcher 需要引用 Worker 的函数名:
Worker 不需要预设环境变量——所有配置由 Dispatcher 通过 event payload 传入。
4.3.5 第五步:部署 Dispatcher Lambda
Dispatcher 超时设为 60 秒即可——它只做目录列举和异步 invoke,不做实际扫描。各环境变量含义:
- WORKER_FUNCTION_NAME:Worker Lambda 的函数名
- FILE_SYSTEM_ID:被监控的 Amazon EFS 文件系统 ID
- QUOTA_GB:单项目配额(GB),默认 50
- SOFT_LIMIT_PERCENT:软限制百分比,默认 80
- WEBHOOK_URL / WEBHOOK_TOKEN:业务系统接收端点及认证 Token
- CW_NAMESPACE:Amazon CloudWatch 自定义指标命名空间
4.3.6 第六步:配置 Amazon EventBridge 定时触发
创建定时规则触发 Dispatcher:
五、效果与成本
5.1 运行效果
部署完成后,手动触发一次扫描验证:
Dispatcher 在数秒内完成调度,返回类似 {“customers_dispatched”: 3}。随后各 Worker 并行执行,可在各自的 Amazon CloudWatch Logs 中查看扫描结果。下图展示了一次扫描在 Amazon CloudWatch Logs 中的输出。
[图2] |
如启用了 Amazon CloudWatch 指标上报,还可基于自定义命名空间建立 Dashboard 观察各项目用量历史趋势,如下图所示。
[图3] |
5.2 性能表现
扫描耗时主要取决于 du 遍历目录的速度,而 du 的速度与目录下的文件数量(元数据量)相关,与总字节数关系不大。以下为基于实际部署的实测数据(4 个客户、7 个项目目录,其中 customerX/bigproject 含约 13 万文件),Worker Lambda 配置为 512 MB 内存,6 轮测试取平均值:
5.2.1 Dispatcher 耗时
| 指标 | 实测值 |
| 调度 4 个客户 | 455 ms |
5.2.2 Worker 耗时(按客户)
| 客户 | 项目数 | 文件数 | 平均耗时 | 范围 |
| customerX | 1 | ~130,000 | 27 秒 | 8.7~41 秒 |
| customerA | 3 | ~500 | 2.1 秒 | 1.0~3.4 秒 |
| customerB | 2 | ~230 | 2.6 秒 | 1.0~5.2 秒 |
| customerC | 1 | ~300 | 1.7 秒 | 0.9~3.3 秒 |
端到端完成时间(从 EventBridge 触发到全部 Worker 完成):取决于最慢的 Worker,实测约 8~41 秒。
扫描过程只消耗 Amazon EFS 的元数据读取 IOPS,不影响业务对文件系统的正常读写吞吐。
六、总结
本方案通过 EventBridge 定时触发 Dispatcher Lambda 发现客户目录,再异步 fan-out 多个 Worker Lambda 并行扫描,实现了按“客户/项目”两级目录粒度的存储用量监控。方案无额外存储组件依赖,新增客户或项目时零配置,配额阈值通过环境变量灵活调整,适用于多租户 SaaS 平台的共享 EFS 存储场景。
➡️ 下一步行动:
相关产品:
- Amazon EFS — 弹性文件存储
- AWS Lambda — 无需服务器即可运行代码
- Amazon CloudWatch — 可观测性工具
- Amazon VPC — 隔离云网络
- Amazon EventBridge — 大规模构建事件驱动应用程序
相关文章:
- 使用 Amazon EventBridge 与 AWS Lambda 实现 ALB 流量镜像会话自动化配置
- Amazon Bedrock AgentCore 数据持久化文件系统:Session Storage 和 Amazon EFS / S3 Files
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。




