为什么我应该（不）使用 S3 而不是 Lambda 来处理静态内容

Question

让我们想象一下这样的情况：

我们有node.js 应用程序，它在服务器端渲染视图并将html 发送到浏览器。在生成的 html 中，我们几乎没有静态资源（如图像、样式表等）。

为什么我应该（或不应该）选择 S3 而不是 Lambda 来提供此内容？

以下是我看到的优点和缺点：

表现

我非常确定从 S3 提供内容比从 Lambda 提供内容要快得多（没有需要执行的脚本）...

...直到我执行了一些测试（文件大小 ~44kB）平均 10 个请求：

• API GW + S3：285ms
• API GW + Lambda：290ms
• S3：135毫秒

正如您所看到的，通过 API GW 从 Lambda 提供内容与从 S3 提供内容没有区别。唯一显着的区别是直接链接到 s3 和之前的两次测试之间。

拉姆达 1 : S3 1

成本

在这里 Lambda 绝对获胜。

首先，我们对 1 000 000 个请求进行免费分类，其次是定价：

• S3：每 10,000 个请求 0.004 美元
• Lambda：每 10,000 个请求大约 0,002000624：

（每 100 万个请求 0.20 美元 + 每 100 毫秒 0.000000208 美元）

因此，在定价方面，Lambda 获胜。

总结

我的观察表明，Lambda 甚至是提供静态内容的更好方式（速度与 S3 类似，而且价格便宜两倍）。

我有什么遗漏的吗？

Answer 1

我相信你犯了一些错误。

S3 请求定价为每 10,000 个请求 0.004 美元，即每百万个请求 0.40 美元。这是正确的。

Lambda 的费用是每百万次调用 0.20 美元，加上 CPU 时间。同意。

但我相信您忽略了这样一个事实：如果没有 API Gateway，则无法从 Internet 调用 Lambda 函数，每百万个请求需要额外支付 3.50 美元。

从 Lambda 提供静态内容的净成本为每百万个请求 3.70 美元，加上 CPU 时间。

这使得 S3 的成本大大降低。

然后，考虑带宽成本：CloudFront 与 S3 结合使用时，比单独使用 S3 更快，每个请求的成本更高，但带宽也稍微便宜一些。如果您将 CloudFront 分配限制为价格等级 100，那么在某些情况下您实际上支付的费用比单独使用 S3 的费用要少。

最便宜地区的 S3 下载带宽为 0.09 美元/GB。

最便宜的 CloudFront 下载带宽为 0.085 美元/GB。

从 S3 到 CloudFront 的带宽是免费的（例如，用于缓存未命中）。

将 CloudFront 与 S3 结合使用时，每 GB 下载成本比单独使用 S3 低 0.005 美元。CloudFront 每 10,000 个请求收费 0.0075 美元，比 S3 多收费 0.0035 美元...但是，如果我们假设缓存命中率为 50%，则数字如下所示：

每 10,000 个对象 $0.0075 [CF] + ($0.004 [S3] * 0.5 [命中率]) = $0.0095 ...为了简单起见，我们将其四舍五入为 $0.01。

现在，我们可以看到 10K 对象的请求成本完全被 2GB 下载节省的成本所抵消，因此，如果您的对象大于 2G/10K = 2M/10 = 200KB/每个，那么将 CloudFront 与 S3 结合使用实际上会稍微便宜一些比单独使用 S3 更好。如果不是，成本仍然太接近而不是显着，并且如上所述，下载周转时间要短得多。

此外，CloudFront 支持 HTTP/2。

¹ 这假设 API 网关 + Lambda。自编写此答案以来，现在还有两种方法可以允许 Lambda 函数返回静态（或动态）内容： CloudFront 的 Lambda@Edge 功能支持从 Lambda 函数生成 HTTP 响应，但该函数以特殊的轻量级“运行”仅支持 Node.js 的“edge”容器。然而，这里的最小运行时间是 50 毫秒，而不是标准的 100 毫秒。 Application Load Balancer 还支持使用 Lambda 函数作为目标，这些是标准容器中的标准 Lambda 调用，因此支持所有运行时。这两者都比 API Gateway 更具成本效益，但除非您已经拥有 ALB，否则还必须考虑 ALB 本身的基准成本。两者都限制为 1MB 响应正文（在 Lambda@Edge 上，这需要“原始请求”触发器），这比 API Gateway 的限制更小。