Lambda@Edge与作为CloudFront源站的Lambda性能及成本对比

方案1利用了Origin Request类型Lambda@Edge的响应短路特性：只要该触发器返回构造好的HTTP响应，CloudFront就不会真正向配置的源站发起请求，因此源站不需要部署真实业务逻辑，按以下规则配置即可：

• 源站类型选择自定义源站，填入任意公网可正常返回200响应的占位地址即可，比如公开可读的S3静态文件地址、名下任意闲置公网服务的默认页均可，不需要额外在这个源站上部署业务代码
• 对应缓存行为的源请求策略调整为仅转发缓存键需要用到的查询参数、请求头、Cookie，无关请求字段全部不转发，避免缓存键膨胀拉低命中率
• 给缓存行为绑定部署好的Lambda@Edge函数，函数执行角色必须附加对应DynamoDB表的只读权限，以及Lambda@Edge要求的基础信任策略
• Lambda@Edge代码中查询到DynamoDB数据后，直接构造带正确Cache-Control头的HTTP响应返回即可，CloudFront收到该响应后会自动按缓存规则存储到边缘节点，不会向占位源站发请求
• 注意Origin Request类型的Lambda@Edge最长执行超时为5秒，若DynamoDB查询逻辑可能超过该阈值，不要用这套配置

延迟维度 #

• 方案1（Origin Request Lambda@Edge）：缓存未命中时，函数直接在离用户最近的CloudFront边缘节点执行，不需要跨区域回源到固定地域的后端，网络路径更短。全球用户场景下，未命中延迟比方案2低30%~70%；缺点是Lambda@Edge不支持预置并发，冷启动延迟波动比配置了预置并发的区域Lambda大，且函数初始化耗时比同配置区域Lambda略高。
• 方案2（固定区域Lambda作为源站）：缓存未命中时，边缘节点必须跨网转发请求到Lambda部署的固定AWS区域，回源RTT随用户和源站地域的距离增加而上涨，偏远地区用户的未命中延迟可能达到数百毫秒；优势是支持预置并发，可以把Lambda冷启动延迟压到极低，用户集中在源站所在地域时，未命中延迟和方案1基本持平。

成本维度 #

• 方案1：Lambda@Edge的单位请求、单位执行时长计费标准是普通区域Lambda的3倍左右，但不需要支付CloudFront跨区域回源的流量费用。缓存命中率高于90%时，整体成本和方案2差距不大；缓存命中率低于70%时，Lambda执行成本会明显高于方案2。另外Lambda@Edge的版本需要同步到全球边缘节点，部署、调试的时间成本更高。
• 方案2：普通区域Lambda的执行单价更低，支持预置并发做成本和性能的弹性调整，但需要支付CloudFront边缘到源站区域的跨区域回源流量费。用户集中在源站所在地域时，回源流量开销极低，整体成本比方案1低20%以上；用户全球分散时，跨区域回源流量成本会快速上涨，最终成本可能反超方案1。

可以根据业务数据特性选对应架构，比上述两个基础方案的性价比更高：

• 若数据更新频率低（分钟级以上更新延迟可接受）：直接做静态化兜底。配置DynamoDB Streams触发普通区域Lambda，数据变更时自动把最新数据生成静态文件同步到S3桶，给S3配置OAC（源站访问控制）仅允许CloudFront访问，把S3作为CloudFront源站。这套方案完全不需要未命中时跑Lambda查库，回源延迟稳定在十几毫秒级别，成本只有Lambda查库方案的1/10不到，是静态类数据的最优解。
• 若数据实时性要求高（秒级以内更新要求）：用户全球分布就选方案1的Lambda@Edge架构，同时给DynamoDB部署DAX加速集群，把数据库查询延迟从个位数毫秒压到亚毫秒级，同时尽可能精简缓存键规则，把缓存命中率拉到最高，摊薄Lambda@Edge的执行成本；用户集中在单个区域就选方案2，给Lambda配置少量预置并发削冷启动，调试和运维成本比Lambda@Edge低很多。
• 若接口是纯读、无个性化逻辑：可以直接给CloudFront配置更激进的缓存TTL，配合stale-while-revalidate缓存策略，用户请求永远先拿边缘缓存的旧响应，后台异步回源更新缓存，能把实际用户感知的未命中延迟降到0。

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