Rewrite directives handled by low-level routing logic of the web server are definitely different to a container image that gets spun up in a distributed network and queried for each request, don't you think?

Not really, no. In fact the only significant difference (that the Lambda@Edge function is run at the closest geolocation to the client, rather than on the origin server) is an advantage to Lambda@Edge.

What difference are you alluding to?

A HTTP URI path prefix mapping is done in nginx, in the same process, no context switching, no buffering, I think it is even done without any allocation.

Of course it doesn't matter, basically logging takes more resources than whatever routing is needed. (Especially because even if it requires running a Cloudflare worker it's just a NodeJS V8 isolate, very lightweight. As far as I know. But I have no idea of its costs.)

But AWS Lambdas are pretty pricey compared to a free nginx rewrite.

> But AWS Lambdas are pretty pricey

Kind of why CloudFront Functions we're invented for this use case, AWS Lambda@Edge is the more general purpose edge computing facility.

> (...) are definitely different to a container image that gets spun up (...)

I'm not sure you're making a informed observation. "Spinning up a container image" is just fancy jargon/handwaving to refer to launching a process, which is something nginx already does under the hood in a myriad usecases without warranting complains from users.

> and queried for each request, don't you think?

I'm not sure if either you framed your sentence poorly or you don't have a clear idea about what you're talking about. In AWS lambda, you don't "spin up containers" at each request. You launch your lambda once it's deployed or when it scales up, and it stays up as long as you see traffic.

Poor phrasing, then. Meant to say a container is started once, then queried on every subsequent request. And what I’m talking about is not the user-facing lambda, but what AWS does on the infrastructure layer below, which involves running a containerised process on firecracker VMs, communicating via HTTP. There was a great summary of how AWS works a while ago, going into way more detail, that I sadly can’t find anymore. But there’s definitely more work involved in calling a lambda function than forking a process in nginx.

> Rewrite directives handled by low-level routing logic of the web server are definitely different to a container image that gets spun up in a distributed network and queried for each request, don't you think?

I’m pretty sure Lambda@Edge is not a container image like regular Lambda (why it only supports JS and not the broader set of Lambda runtimes) and is relatively local to the edge environments serving CloudFront anyway (why it is support in CloudFront the way regular Lambda isn't, and what the @Edge part refers to.)