blocks|key|26713|text|我相信你犯了几个错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|26714|S3请求定价为每万次请求0.004美元，即每万次请求0.4美元。是这样的。|26715|Lambda是每百万次调用0.20美元，外加CPU时间。同意。|26716|但是我相信你已经忽略了一个事实，你不能在没有API+Gateway的情况下从Internet调用Lambda函数，这是每百万次请求额外的3.50美元。|26717|提供来自Lambda的静态内容的净成本为每百万次请求3.70美元，外加CPU时间。»|26718|这使得S3的成本大大降低。|26719|然后，考虑带宽成本:当与S3结合使用时，CloudFront比单独使用S3更快，具有更高的每次请求成本，但带宽成本也略低。如果您将您的CloudFront分发限制为价格类别100，那么在某些情况下，您实际上会比只使用S3支付更少的费用。|26720|最便宜地域的S3下载带宽为0.09美元/GB。|26721|最便宜级别的CloudFront下载带宽为0.085美元/GB。|26722|从S3到CloudFront的带宽是空闲的(例如，对于缓存未命中)。|26723|与单独使用S3相比，结合使用CloudFront和S3，每GB的下载成本降低了0.005美元。CloudFront每10,000次请求收费0.0075美元，比S3高出0.0035美元...但是，如果我们假设缓存命中率为50%25，则数字如下所示：|26724|每10,000个对象$0.0075+CF+%2B+($0.004+S3+*+0.5命中率)=+$0.0095...为了简单起见，让我们将其四舍五入为0.01美元。|26725|现在，我们可以看到，10K对象的请求成本正好被节省的2+2GB下载所抵消，所以如果您的对象大于2G/10K+=+2M/10+=200KB/每个，那么使用带有S3的CloudFront实际上比单独使用S3稍微便宜一些。如果不是，成本仍然太接近而不是很明显，并且，正如前面提到的，下载周转时间要短得多。|26726|此外，CloudFront还支持HTTP/2。|26727|26728|²假设API+Gateway+%2B+Lambda。由于这个答案已经写好了，现在还有两种方法允许Lambda函数返回静态(或动态)内容:+Lambda函数的CloudFront's+Lambda@Edge+feature+supports+generating+HTTP+responses，但是该函数运行在一个特殊的、只支持Node.js的轻量级“边缘”容器中。但是，这里的最小运行时间是50ms，而不是标准的100ms。Application+Load+Balancers+also+support+using+a+Lambda+function+as+a+target，这些是标准容器中的标准Lambda调用，因此支持所有的运行时。这两者都可能比API+Gateway更具成本效益，尽管也必须考虑ALB本身的基准成本，除非您已经有了ALB。两者都被限制在1MB的响应体(在Lambda@Edge上，这需要一个“原始请求”触发器)，这比API+Gateway的限制要小。|offset|length|26729|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-generated-response-examples|1|https://aws.amazon.com/blogs/networking-and-content-delivery/lambda-functions-as-targets-for-application-load-balancers/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|24|1V|0|5U|23|1|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1I|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1J|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1K|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1L|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1M|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1N|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1O|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1P|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1R|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1T|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1V|8|@]|9|@$14|1W|15|1X|1|1Y]|$14|1Z|15|20|1|21]]|A|$]]|$1|16|3|-4|5|6|7|22|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]|1E|$5|19|1A|1B|A|$1C|1F]]]]

I believe you've made a couple of errors.

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

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

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.

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

This makes S3 substantially less expensive.

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 download bandwidth in the least expensive regions is $0.09/GB.

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

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

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:

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.

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.

Additionally, CloudFront supports HTTP/2.

<hr>

&sup1; 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: <a href="https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-generated-response-examples" rel="nofollow noreferrer">CloudFront's Lambda@Edge feature supports generating HTTP responses</a> 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. <a href="https://aws.amazon.com/blogs/networking-and-content-delivery/lambda-functions-as-targets-for-application-load-balancers/" rel="nofollow noreferrer">Application Load Balancers also support using a Lambda function as a target</a>, 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.

blocks|key|2484692|text|您可能需要考虑的另一个重要因素是λ冷启动时间，这将影响您的性能。对于静态资源，它可能会显著增加页面加载时间。如果您的lambda碰巧是基于vpc的，这会变得更糟，这需要附加一个新的ENI，这需要更长的时间来创建。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|2484693|entityMap^0|G|4|1X|3|2I|3|0^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]|$9|L|A|M|B|D]|$9|N|A|O|B|D]]|E|@]|F|$]]|$1|G|3|-4|5|6|7|P|8|@]|E|@]|F|$]]]|H|$]]

Another important factor you may need to consider is the lambda cold start time which will impact your performance. For static resource, it might significantly increase the page load time. This becomes worse if your lambda happens to be a <code>vpc</code> based which requires a new <code>ENI</code> attached which takes longer time to create.

Let's imagine situation like that:

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.).

<h2>Why should I (or not) choose S3 over Lambda to serve this content?</h2>

Here are pros &amp; cons which I see:

<h2>Performance</h2>

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)...

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

<ul>
<li>API GW + S3: 285ms</li>
<li>API GW + Lambda: 290ms</li>
<li>S3: 135ms</li>
</ul>

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

<h2>Cost</h2>

And here Lambda wins definetely.

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

<ul>
<li>S3: $0.004 per 10,000 requests</li>
<li>Lambda: around 0,002000624 per 10,000 requests:</li>
</ul>

($0.20 per 1 million requests + $0.000000208$ per every 100ms)

So in pricing Lambda wins.

<h1>Summarizing</h1>

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

Is there anything what I am missing?

Why should(n't) I use S3 instead Lambda for static content

让我们想象一下这样的情况：我们有node.js应用程序，它在服务器端渲染视图，并将html发送到浏览器。在生成的html中，我们只有很少的静态资源(如图像、样式表等)。为什么我应该(或不应该)选择S3而不是Lambda来提供这些内容？下面是我看到的利弊：性能我非常确定从S3提供内容要比从Lambda提供内容快得多(没有...

问为什么我应该(n不)对静态内容使用S3而不是Lambda
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我应该(n不)对静态内容使用S3而不是LambdaEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我应该(n不)对静态内容使用S3而不是Lambda
EN