Zero-cost possible? Lambda@Edge in CloudFront for signing requests to Lambda?

[kevin-mitchell]

Hello! I haven't kept up with this project, nor with next.js to be honest, but a few years ago the default setup for this project involved a zero-cost setup which worked great for personal / hobby projects. S3 storage and a Route 53 hosted zone was the only cost (for most of my little toy project, normally < USD $1 a month).

I am guessing the audience interested in CDK + Next.js is more likely to consider the example costs in the docs (6 bucks for the cheapest option with FCK-NAT) negligible, personally I'd still prefer a "default deployment is doable on the free tier" setup.

Again, with an apology that this is a bit of a lazy question, I am assuming there is a reason the NAT is needed at all?

I thought there was a way these days to use a Lambda@Edge function to sign requests to Lambda function, so a function URL wasn't directly accessible publicly (edit 2: actually I think this is pretty sure? edit: to be fair, it's still exposed as in reachable, so does open the door for abuse - there is a some level of security through obscurity, but without the CloudFront function signing requests to the Lambda anybody who did find it just ends up with a access denied message - still, I realize this isn't as secure as having it safely inside a VPC. But it seems like a nice option to have). I'm guessing it's not as simple as this and the issue is that some feature of Next.js requires the NAT setup for Lambda for whatever reason to support?

For my uses and goals, $5 or $6 is "too much", I have a bunch of random blogs and things that nobody reads (and it would be reasonable to question their value of their existence at all, but it gives me some joy!) that I manage through Next.js + CDK, I'd love to upgrade / update the cdk-nextjs dependency and next.js itself but am wondering if there is a reasonable path forward for me here given my goal of having a free tier only deployment option?

[bestickley]

Hey @kevin-mitchell, thanks for your interest!

As-is, if you don't need to be able to access internet from your Next.js server, you could override the default VPC creation to not have NAT Gateway or public subnet and therefore not have associated costs. Most Next.js apps need to access internet so that's why it is not default.

VPC is currently required because of use of EFS.

But the PR: #187 changes that: it replaces EFS with S3 + DDB. Please watch that PR. It will merge/release soon. I'd love your feedback.

[kevin-mitchell]

Thanks a ton @bestickley , glad to see you're still around working on this project!

I'm not super familiar with EFS but familiar enough I can roughly understand.

I started looking through a PR a bit, but I'll keep an eye and perhaps take a stab at deploying a simple project with that branch. Seems like a lot of great stuff, and I really appreciate all of the work there!

I read through the caching docs and was curious about pruning (being the frugal person I am :)), then saw the pruning doc. I haven't actually looked at the relevant code yet super deeply, but the docs mention pruning on deployment, and sure enough I see the post-deploy.. related functionality. Is this post-deploy hook the only mechanism by which old things will be purged from S3 / DDB? I was trying to think if the SK or PK could be modified in a way to allow (in the future perhaps) for sorting of cache items by age, outside of deployments, for more regular clean up? I am not sure if something like a KSUID could fit in somewhere?

Again, very possible I haven't read deeply enough or am just missing something in which case ignore me and sorry for the noise!

[bestickley]

welcome, @kevin-mitchell!

Is this post-deploy hook the only mechanism by which old things will be purged from S3 / DDB?

yes. let's say you have deployment 1 with related assets. The assumption is that you wouldn't want to delete deployment 1 assets until deployment 2 has successfully finished.

I was trying to think if the SK or PK could be modified in a way to allow (in the future perhaps) for sorting of cache items by age, outside of deployments, for more regular clean up?

DDB is used to keep track of which cache key in s3 is related to which tag. These are invalidated or deleted in s3 at runtime by cache. In s3 for static assets we use s3 tagging to include build id so we can delete static assets after subsequent deployments. I don't think there is way you'd want to prune in between deployments.

[kevin-mitchell]

Ah! This is the part I was missing (static assets). This makes complete sense.

Well the updates / changes look great. This weekend maybe I'll take a stab at deploying a fresh project from your PR branch.

From the looks of next.js releases 16.2 has been out there since... mid Januarry? so hopefully that'll get landed soon!

Thanks again for your time!