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

Question

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

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

Here are pros & cons which I see:

Performance

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:

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

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

Cost

And here Lambda wins definetely.

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

• S3: $0.004 per 10,000 requests
• Lambda: around 0,002000624 per 10,000 requests:

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

So in pricing Lambda wins.

Summarizing

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?

Answer 1

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 vpc based which requires a new ENI attached which takes longer time to create.

Answer 2

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

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.

---

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