为什么我使用S3代替Lambda来获取静态内容

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (57)

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

我们有node.js应用程序,它在服务器端呈现视图并将html发送到浏览器。在生成的html中,我们有很少的静态资产(如图像,样式表等)。

为什么我(或不)选择S3而不是Lambda来提供这些内容?

以下是我看到的利弊:

性能

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

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

  • API GW + S3:285ms
  • GW + Lambda API:290ms
  • S3:135ms

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

Lambda 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,价格便宜两倍)。

有什么我错过的吗?

提问于
用户回答回答于

我相信你犯了一些错误。

S3请求定价为每10,000个请求0.004美元,即每百万美元0.40美元。那是对的。

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

但是我相信你忽略了这样一个事实:如果没有API网关,你不能从互联网上调用Lambda函数,这是每百万请求额外的3.50美元。

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

这使得S3基本上更便宜。

然后,考虑带宽成本:当与S3结合使用时,CloudFront比单独的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 Gateway + Lambda。由于编写了这个答案,现在有两种方法可以让Lambda函数返回静态(或动态)内容:CloudFront的Lambda @ Edge功能支持从Lambda函数生成HTTP响应,但该函数运行在一个特殊的,轻量级的“ edge“仅支持Node.js的容器” 但是,这里的最小运行时间是50ms而不是标准的100ms。 应用程序负载均衡器还支持使用Lambda函数作为目标,这些是标准容器中的标准Lambda调用,因此支持所有运行时。这两种方法都比API网关更具成本效益,但除非您已经拥有ALB,否则还必须考虑ALB本身的基准成本。两者都限于1MB响应体(在Lambda @ Edge上,这需要“原始请求”触发器),这是一个比API网关更小的限制。

用户回答回答于

您可能需要考虑的另一个重要因素是lambda冷启动时间会影响您的性能。对于静态资源,它可能会显着增加页面加载时间。如果你的lambda恰好是一个vpc需要新ENI连接的基础,这需要更长的时间来创建,这会变得更糟。

扫码关注云+社区

领取腾讯云代金券