AWS单体Lambda与微Lambda函数的开发部署权衡有哪些？

微Lambda（单类单操作对应独立函数）的额外优势 #

• 权限控制粒度更安全：每个Lambda仅需分配对应操作的最小IAM权限，例如仅读取W类数据的函数只需授予存储层W表的读权限，无需开放其他表、其他操作的权限，即使函数出现安全漏洞，可影响的范围也会被控制到最小。如果使用单体Lambda，必须为其授予所有表的全量CRUD权限，风险敞口会大幅提升。
• 资源配置成本更优：不同CRUD操作的资源消耗差异极大，例如批量导出X类数据的操作可能需要1G以上内存、10秒以上运行时长，而删除单条W类数据的操作128M内存、几十毫秒就能跑完。如果合并为同一个Lambda，只能按最高资源消耗的操作配置参数，所有低消耗操作都会产生不必要的成本浪费。
• 故障隔离边界更清晰：如果某一类操作的逻辑出现bug，只会影响对应Lambda的可用性，不会波及其他操作。同时监控、日志排查的成本更低，每个操作的调用量、错误率、耗时可以直接查看对应Lambda的内置指标，不需要在同一函数的海量日志中做标签筛选，排查故障效率高很多。
• 迭代发布风险更低：修改单个操作的逻辑时，仅需单独发布对应Lambda，不会影响其他业务逻辑的运行，也可以针对单个操作做灰度发布、回滚等操作，发布影响范围被控制到最小。

单体Lambda的额外适用优势 #

• 通用逻辑复用成本低：如果所有CRUD操作共享大量通用逻辑，例如统一参数校验、身份鉴权、业务埋点、错误上报等，放在同一个Lambda内可以直接复用代码，不需要额外抽离公共层、公共依赖包，减少依赖维护的工作量。
• 低频场景收益更明显：如果这套CRUD接口是低频调用的内部工具类场景，例如日均调用量不足百次，冷启动概率本身极高，单体Lambda分摊冷启动成本的优势会被放大，同时因为调用量低，资源浪费、故障影响范围等问题的负面影响可以忽略不计。

折衷选型建议 #

不需要走非黑即白的极端路线，可以按业务域拆分Lambda，例如将关联度高的W、X类的所有CRUD放在同一个Lambda，Y、Z类的所有CRUD放在另一个Lambda，平衡两边的优劣势，适配具体业务场景的需求。

内容的提问来源于stack exchange，提问作者Mark