摘要

  • AWS为Lambda增加独立的S3 Files直接读取选择，不再只能依赖内存配置决定默认行为。
  • 判断价值要看正确完成一次任务的总成本，不能只看内存数值或执行是否成功。

想改变存储读取偏好，不一定应该先购买更多计算资源。AWS在9月11日的Lambda公告中，将S3 Files的显式直接读取选择与函数内存大小分开。这项变化给调优增加了一个维度，但它本身不是降本结果。

当前API提供AUTO、ENABLED和DISABLED，并说明直接读取失败时可以退回文件系统路径。回退有助于工作继续进行，也提醒买方：一次调用成功，不等于预期路径承担了这次读取。

拆开一个开关，不等于拆开所有成本

Lambda分配的CPU仍与配置内存成比例。若团队借新选项降低内存，就可能同时改变读取偏好和计算资源。此时执行时间的变化不能从比较中消失。

一个简单算式就能说明问题：内存减半、计费时长翻倍，两者的乘积并没有下降。这是算术示例，不是AWS实测。标准Lambda Functions按请求和内存加权的执行时长计费，因此仅凭内存栏里的数字变小，无法得出省钱结论。

存储端还有另一组计量。S3 Files区分文件系统数据访问和直接流式读取，后者仍涉及S3 GET与元数据读取费用。避开一种文件读取收费，不等于整次操作免费。更合适的分母是正确完成的一项任务，并把它引起的存储活动一起计入。

配置状态不是运行轨迹

官方文字还存在一个值得保留的边界：发布公告按文件大小描述读取分流，API中ENABLED的说明则使用了覆盖所有读取的较宽表述。不能把两者悄悄合并成一条已经验证的逐次操作规则。本稿没有进行运行测试。

两份资料的共同点仍然明确：用户现在可以在内存之外显式选择读取偏好。它们却不足以让买方仅凭一个开关，就确定混合负载中每次读取走了哪里。

大量读取小条目，与连续处理一个大数据集，未必适合相同选择。这些是分析中的负载类型，不是客户测试结果。团队需要看见时间花在哪一段、哪些计费项目发生变化。否则，存储侧的调整可能伴随未被识别的计算减速，成功回退也可能掩盖比较条件为何改变。