Both AWS services provide the same concept of delivering processing power with the lowest latency to the user. In essence, they act as HTTP middleware that enables the execution of request & response related processing. However, even though the purpose is the same there are significant differences that can be used in specific cases.
Cloudfront Functions— run on the edge locations themselves. There are currently more than 400 edge locations in the world run by AWS. Edge locations are dominantly used for caching the content served by Cloudfront.
Cloudfront functions are also running on the edge locations. With that said, the power and execution time is very limited. However, startup time is measured in submillisecond and scaling is rapidly fast to handle hundreds of million requests per second.
However, Cloudfront Functions have a few limitations that might be an issue when architecting a solution. Some of the CF Functions' limitations are: memory is limited to 2 MB, max function code size is limited to 10KB, only JS can be used for coding, no internet access, no access to a request body, no 3rd party libs and etc.
Also, there are some advantages over Lambda@Edge functions for instance rapid scaling and lower cost.
Lambda@Edge — is similar to Cloudfront Functions, but it runs on a Regional Edge Cache instead of an Edge location. So name as such, might be misleading. Lambda@Edge are following a similar concept as regular AWS Lambda, however, there are some significant differences. Such as It can last 5sec(30sec for origin req/resp), max memory can be 128MB to 3GB, and it can be coded only in JS or Pythons.
In comparison to Cloudfront Functions, it has access to the internet, other AWS services, and 3rd party libs that can be used. However, it scales a lot slower and costs much more.
Top comments (0)