Moving away from Lambda Edge or towards it.

[ivands]

I've been thinking more about improving the costs of the system, and I think it's probably best to remove the lambda edge router. The edge router is used to tell CloudFront to get the static files from s3. The problem however is that lambda edge is expensive and will now be triggered for every missed cache hit. And because SSR pages can't be cached we trigger the lambda edge function for no reason. Plus we don't gain any speed benefit by using the edge because SSR is still happening on a normal lambda function.

We could just move the lambda edge router functionality to the normal lambda that is doing SSR right now. The lambda just needs to get the static assets from s3 when necessary and return it with proper caching headers for CloudFront. If the request isn't for a static asset we just do the normal SSR stuff.

This approach should reduce costs even more. What do you think?

[ivands]

More thinking happened. If we could just do SSR on the edge we wouldn't need API Gateway anymore. Plus we would get the additional speed benefit that the edge provides.

Both options seem like an upgrade to me. (Going fully on the edge is a lot cheaper tho)

[MicMonen]

I am trying to get this to work on the edge with this package.

I have a CloudFront instance that has 1 origin (S3 bucket with all the static files). I've attached an edge lambda (origin-response) that checks if the request is found on the origin or else execute the SSR code and return that as a response. The problem is that I cannot get the SSR code (serverless.js) to work.

I hope you understand the logic behind this and maybe can help me try to get this working.

(An upgrade to this solution is to get SSR working on the origin-request edge function)

[yarbsemaj]

Hi @MicMonen Do you have any logs of any errors your seeing that i could take a look at? Could you try hitting the SSR API gateway directly, and seeing if you get back the expected response?

[yarbsemaj]

Hi @ivands Thank You very much for your suggestions.

I disagree with your assertion that SSR pages cannot be cached, this is quite common practice and in fact it's probably more advantages to cache SSR content vs static content as there is not only a transfer cost associated with generated data, but also a time and monetary cost associated with rendering the page. I cache SSR pages for my personal blog using this adapter. I have a long cache on all the blog pages, then when a blog post is added or updated I programmatically invalidate the cache on specific paths.

I Considered all these options when developing the initial solutions before coming up with my final design, below are the Pros and Cons of each approach so i hope you get a understanding of the tradeoffs I had to consider. I have highlighted in bold the deal breaker for me with the 2 rejected options.

SSR at the edge

Pros

• Low latency
• Assets are served directly from S3, reducing latency and cost (compared to option 2)
• Assets can be of unlimited size
• Simple architecture (Only one lambda)
• No API gateway

  Cons

• Slow deploy (edge has to be updated every time you deploy)
• High cost (It's roughly 3x more expensive to run a lambda at the edge that in region) This could be especially problematic if the lambda is waiting on external API or you have complex pages that take time to render.
• Only suitable for GET request, it's not possible to read the body of a request with a lambda at edge.

  Serve everything from a Lambda

  Pros

• Simple architecture (Only one lambda)
• Quick deploy (as your not having to wait for an edge to update)

  Cons

• You have to pay for lambda execution time just to proxy request to S3.
• You have to pay for an API gateway to proxy those s3 request too.
• Your limited to assets smaller that 6mb, (that the largest payload a lambda can output). You probably shouldn't be serving assets that big from your application but people will try.

  The Hybrid approach (the one i went for)

  Pros

• Edge function does very little processing, thus it can have minimal amount of RAM and CPU allocated and thus will have minimal running cost.
• Assets are served directly from S3, reducing latency and cost (compared to option 2)
• Assets can be of unlimited size
• SSR lambda only has to process SSR requests.

  Cons

• More complex setup
• Marginal additional cost of API gateway and edge lambda
• Slow deploy

[ivands]

Hi @yarbsemaj,

Let me just be clear about the caching point. When I say "cache" I'm talking about the CloudFront CDN cache. This package can't set default caching headers for SSR pages because not every SSR page can be cached. However static content from s3 can always be cached. (And because s3 content can be cached some of your points are incorrect).

SSR at the edge

• Going fully on the edge probably isn't more expensive, and will probably reduce the costs because API Gateway is far more expensive than a lambda edge call. (As a side note, in my experience lambda costs primarily come from the execution count. Not from the runtime costs)

Serve everything from a Lambda

• You don't have to pay for lambda execution time or API gateway just to proxy requests to S3 If you set proper caching headers for CloudFront. CloudFront should only call the lambda 1 time and for every subsequent call, the file is already in de CDN cache.

The Hybrid approach

I hope you see why using this hybrid approach doesn't add any real benefit other than unlimited file size.

[yarbsemaj]

Hi @ivands Thank You for you comment, I thought I would do the maths on SSR at the edge just to be sure (TBH id not done it before) I just assumed it would be more expensive. I can confirm it is quite a bit more expensive (nearly 2x or more depending on how long it takes to process your page). Below are my calculations.

A few notes.

• Tuns out if your using cloudfront you pay no transfer cost for using API gateway (the more you know).
• You can't use arm lambdas at the edge.

  Im making some assumptions here based off my own very small blog app.

• The SSR content you are returning is under 512KB. for these calculation the size doesn't matter as long as it fits under.
• It takes 0.5 second to SSR a request, this may seem a long time, but if you are waiting on external APIs to return data it could easily be longer (for my blog it's closer to 3 seconds)
• It takes 5ms to run the routing lambda (from looking at my logs)
• You are happy using only 256MB of ram to SSR your page, for more complex apps you may need more.

  On Serve everything from a Lambda; It's not true to say Cloudfront will only hit the lambda once, I should only hit it once per edge node but there are many nodes in the network (and thus many request). AWS will also uncache infrequently accessed object according to my research. For example, with my blog I cache aggressively, yet only have a cache hit rate of 40% ish over a month. I think on balance from a cost perspective it's probably cheaper to go this route however as long as you're not serving any objects larger that 6MB. However when you take into account the cost of Cloudfront transfer out the price difference is marginal. For example, assume there was 0 cost associated with serving files from lambda and you were serving 1M request, 100 kilobytes each, all to the US or EU. If you combine the cost of that ($8.11) with the cost serving those request from your non cached infra it turns out the edge lambda is only around 5.4% of your cost. In reality this percentage will be significantly less because most request would be served from cache so your only paying transfer on those, not for any computation. For example with my rather mediocre cache hit rate of 40% that percentage drops to 2.6%

Don't get me wrong, those are still gains but the goal with the project is to make something that "just works" and I can see someone building something and including a video or large image in there public folder and then wondering why its not working when they go to deploy, I know you shouldn't do this, but people will.

[yarbsemaj]

Im very tawn on this and once sveltekit leaves alpha I may revisit this at a later date.

[ivands]

I'm not sure if I agree that the current hybrid version is cheaper. But I should run some tests myself.

On a different note: We have some good news 🥳: Lambda Function Urls are here. https://docs.aws.amazon.com/lambda/latest/dg/urls-invocation.html

And it seems you can return any type of HTTP response. So this should eliminate the need for ApiGateway and reduce the cost of your hybrid version even more. 🎉

[yarbsemaj]

Hi @ivands Thank You so much for the update! I have just published a new version v0.8.0 that adds support for this. If you look at the commit history you will see the small update you need to make to your serverless.yml file. (as well updating the the latest version of the serverless framework)