为什么我不应该使用S3而是Lambda来获取静态内容 [英] Why should(n't) I use S3 instead Lambda for static content

问题描述

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

Let's imagine situation like that:

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

We have node.js app, which is rendering view on server-side and sends html to browser. In generated html we have few static assets (like images, stylesheets etc.).

这是优点&我看到的缺点:

Here are pros & cons which I see:

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

I was quite sure that providing content from S3 is much more faster then from Lambda (there is no script which need to be executed)...

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

...Until I performed some tests (file size ~44kB) average of 10 requests:

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

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

As you can see there is no difference between providing content from Lambda via API GW then from S3. The only significant difference is between direct link to s3 and two previous tests.

Lambda 1:S3 1

Lambda 1 : S3 1

在这里Lambda绝对胜出.

And here Lambda wins definetely.

首先，我们免费分类了1 000 000个请求，其次是定价:

First of all we have free triage of 1 000 000 requests, Second here pricing comes:

• S3:每10,000个请求$ 0.004
• Lambda:每10,000个请求大约为0,002000624:

(每100万个请求0.20美元+每100毫秒0.000000208美元)

因此，在定价方面Lambda胜出.

So in pricing Lambda wins.

我的观察结果表明，即使是静态内容，Lambda也是更好的方式(速度类似于S3，价格便宜两倍).

My observations shows that Lambda is better way to serve even static content (speed is similar to S3, and pricing is twice cheaper).

有什么我想念的吗?

推荐答案

我相信您犯了一些错误.

I believe you've made a couple of errors.

S3请求的定价为每10,000个请求0.004 USD，即每百万个0.40 USD.没错.

S3 request pricing is $0.004 per 10,000 requests, which is $0.40 per million. That's correct.

Lambda是每百万次调用$ 0.20，再加上CPU时间.同意.

Lambda is $0.20 per million invocations, plus CPU time. Agreed.

但是我相信您忽略了以下事实:没有API网关就无法从Internet调用Lambda函数，这是每百万个请求额外增加$ 3.50.

But I believe you've overlooked the fact that you can't invoke Lambda functions from the Internet without API Gateway, which is an additional $3.50 per million requests.

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

Net cost for serving static content from Lambda is $3.70 per million requests, plus CPU time.¹

这使S3的价格大大降低.

This makes S3 substantially less expensive.

然后，考虑带宽成本:CloudFront与S3结合使用时，比单独的S3更快，每请求成本更高，但带宽成本略低.如果将CloudFront分配限制为价格等级100"，那么实际上在某些情况下，您所付的费用将比仅使用S3少.

Then, consider bandwidth costs: CloudFront, when coupled with S3, is faster than S3 alone, has a higher per-request cost, but is also slightly less expensive for bandwidth. If you constrain your CloudFront distribution to Price Class 100 then you will actually pay less under some circumstances than just using S3 alone.

最便宜的地区的S3下载带宽为$ 0.09/GB.

S3 download bandwidth in the least expensive regions is $0.09/GB.

最便宜的CloudFront下载带宽为$ 0.085/GB.

CloudFront download bandwidth in the least expensive class is $0.085/GB.

从S3到CloudFront的带宽是免费的(例如，用于缓存未命中).

Bandwidth from S3 to CloudFront is free (e.g. for cache misses).

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

The cost per GB downloaded is $0.005 less when using CloudFront with S3 than when using S3 alone. CloudFront charges $0.0075 per 10,000 requests, or $0.0035 more than S3... but, if we assume a 50% cache hit rate, the numbers look like this:

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

Per 10,000 objects $0.0075 [CF] + ($0.004 [S3] * 0.5 [hit rate]) = $0.0095... for simplicity, let's just round that up to $0.01.

现在，我们可以看到1万个对象的请求成本完全被2GB下载的节省所抵消，因此，如果您的对象大于2G/10K = 2M/10 = 200KB/每个，则将CloudFront与S3结合使用是实际上比单独使用S3便宜一点.如果不是这样，那么成本仍然太高而无法承受，并且如上所述，下载周转时间要短得多.

Now, we can see that the request cost for 10K objects is exactly offset by the savings on 2GB of download, so if your objects are larger than 2G/10K = 2M/10 = 200KB/each then using CloudFront with S3 is actually slightly cheaper than using S3 alone. If not, the cost is still too close to be significant and, as mentioned, the download turnaround time is much shorter.

此外，CloudFront支持HTTP/2.

Additionally, CloudFront supports HTTP/2.

¹假设使用API​​ Gateway + Lambda.自从编写了此答案以来，现在有两种方法可以允许Lambda函数返回静态(或动态)内容:应用程序负载平衡器还支持使用Lambda函数作为目标，并且这些是标准容器中的标准Lambda调用，因此支持所有运行时.尽管还必须考虑ALB本身的基准成本，但是这两者都可能比API Gateway更具成本效益.两者都限于一个1MB的响应主体(在Lambda @ Edge上，这需要一个起源请求"触发器)，这比API Gateway的限制小.

¹ This assumes API Gateway + Lambda. Since this answer was written, there are now two more ways to allow a Lambda function to return static (or dynamic) content: CloudFront's Lambda@Edge feature supports generating HTTP responses from a Lambda function, but the function runs in a special, lightweight "edge" container that only supports Node.js. However, minimum runtime here is 50ms rather than the standard 100ms. Application Load Balancers also support using a Lambda function as a target, and these are standard Lambda invocations in standard containers, so all runtimes are supported. Both of these can be more cost-effective than API Gateway, although the baseline cost of the ALB itself also has to be considered unless you already have an ALB. Both are also limited to a 1MB response body (on Lambda@Edge, this requires an "origin request" trigger), which is a smaller limit than API Gateway.

这篇关于为什么我不应该使用S3而是Lambda来获取静态内容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！