DEV Community

loading...
Cover image for Migrating from Lambda@Edge to CloudFront Functions
AWS Community Builders

Migrating from Lambda@Edge to CloudFront Functions

Jimmy Dahlqvist
Crazy cloud guy with a passion for serverless. Loves to share my knowledge and experience. Holds several AWS, GCP certificates and I'm always aiming for the next one. Notorious coffee drinker....
・5 min read

image

I have been using Lambda@Edge for several years now, first time I used it was back in 2018, wrote this post back then. I was always under the impression that the Lambda function was running in the edge cache, hence the name. But I was apparently wrong, it runs in the region cache and not in the edge cache. That became clear when AWS, back in May 2021, release the new and shiny CloudFront Functions that was going to run in true edge cache.

So what are the differences? How do we go about to migrate from Lambda@Edge to CloudFront Functions. In this post I will try to explain the differences and talk about my experience migrating my blog infrastructure to CloudFront functions.

Lambda@Edge vs CloudFront Functions

So what are the difference between the two then? First of all Lambda@Edge run at the 13 (at the time of writing this post) Regional Caches. CloudFront Functions run at the 200+ Edge Caches. That mean that the your code will run closer to your users.

image

The other major differences are around runtime support, memory usages, execution time, and more. Here is a table showing the differences.

Feature CloudFront Functions Lambda@Edge
Runtime JavaScript
(ECMAScript 5.1 compliant)
Node.js, Python
CloudFront triggers Viewer request Viewer response Viewer request
Viewer response
Origin request
Origin response
Execution time 1 millisecond 5 seconds (viewer triggers)
30 seconds (origin triggers)
Memory 2MB 128MB (viewer triggers)
10GB (origin triggers)
Package size 10 KB 1 MB (viewer triggers)
50 MB (origin triggers)
Network access No Yes
File system access No Yes
Access to the request body No Yes

That was a lot of differences, but what does it mean? How do I know which to choose?

Pricing

So what about pricing? Is CloudFront Functions or Lambda@Edge more expensive?
With Lambda@Edge you pay $0.60 per 1 million requests plus the execution time ($0.00000625125 FOR EVERY 128MB-SECOND).
With CloudFront Functions you pay $0.10 per 1 million Invocations and nothing for execution time.
That mean that CloudFront Functions is the cheapest option of the two.

Choosing Lambda@Edge or CloudFront Functions

As we just saw there are several differences between Lambda@Edge and CloudFront functions. Which should I use?
I would say that if you don't need to react on origin triggers, have access to the request body, need file or network access, can finish execution within 1 ms and have really small deployment packages, then CloudFront Functions is probably a great match for you. Just remember that no network access mean no access to any other AWS service.

Migrating

CloudFront Functions are deployed with the CloudFront distribution in the region of your choice. This truly made deployment much easier, Lambda@Edge always had to be deployed in us-east-1 region, with CloudFront Functions there was no need to target different regions during deployment.

I have been using Lambda@Edge to make CloudFront act more like a webserver, so if a link was pointing to a folder I use Lambda@edge to append index.html to the path, so the correct file is requested from S3. Since I didn't use any network access, my Lambda@edge function was rather fast, and written in pure Javascript the migration process was rather easy.

Create the Function

First of all I created a AWS::CloudFront::Function and deployed that.

  CloudFrontFunction:
    Type: AWS::CloudFront::Function
    Properties:
      Name: UpdatePath
      AutoPublish: true
      FunctionCode: !Sub |
        function handler(event) {
          var request = event.request;
          var uri = request.uri;
          uri = uri.replace(/\/$/, '\/index.html');
          request.uri = uri;
          return request;
        }
      FunctionConfig:
        Comment: !Sub Append index.html to folder paths
        Runtime: cloudfront-js-1.0
Enter fullscreen mode Exit fullscreen mode

The Runtime of the function must always be cloudfront-js-1.0. I could not find a good way to keep the code in an external source file and not inline it in the CloudFormation template. This is a rather clunky way to add the code for the function. I would love to see a deployment similar to how Lambda is deployed. Since my code was rather short it is manageable to have it inlined.

Testing and debugging

When the function was deployed I could turn to the console to test it out, which was a rather nice experience. You can select the trigger and what stage, Development or Live, you like to use for the test.
image

image
The result is presented in a really nice way.

It is also possible to perform tests using the CLI in an automatic way. This is done using the test-function command.

aws cloudfront test-function \
    --name ExampleFunction \
    --if-match ETVABCEXAMPLE \
    --event-object fileb://event-object.json
    --stage DEVELOPMENT
Enter fullscreen mode Exit fullscreen mode

The event-object is Json with the information about stage etc.

{
    "version": "1.0",
    "context": {
        "eventType": "viewer-request"
    },
    "viewer": {
        "ip": "1.2.3.4"
    },
    "request": {
        "method": "GET",
        "uri": "/mytest/",
        "headers": {
            "host": {"value": "example.org"}
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

The deployment and testing is really nice, you can easily deploy a new development version and test it out before going live.
Logs, printed using console.log() is always sent to CloudWatch logs in us-east-1, doesn't matter what edge location the Function runs in, logs are in us-east-1

So after I had tested the Function it was time to update the CloudFormation template.

Doing the actual migration

The last step is to do the actual update of CloudFormation and do the migration. I commented out the LambdaFunctionAssociations section and added the FunctionAssociations instead.

CloudFrontDistribution:
    Type: AWS::CloudFront::Distribution
    Properties:
        DistributionConfig:
            ....
            FunctionAssociations:
                - EventType: viewer-request
                FunctionARN: !GetAtt CloudFrontFunction.FunctionMetadata.FunctionARN
            #LambdaFunctionAssociations:
            #    - EventType: viewer-request
            #    LambdaFunctionARN: !Ref LambdaARN

Enter fullscreen mode Exit fullscreen mode

The deployment took a couple of minutes but was not that bad. After the deployment was done the page was working perfect and I could delete the Lambda@Edge function.

Conclusion

Migrating to CloudFront Functions from Lambda@Edge was really easy, and was accomplished with just a few steps. So what did the migration bring? I feel that it was easier to debug and test CloudFront Functions. Testing was nice and straight forward. That logs are always in us-east-1 and not as with Lambda@Edge where they end up in the region the Lambda@Edge function runs in, is a killer feature. My cost was down slightly, but not much, I'm not using that much. I can see cost to be a driver for migration for heavy usage. For some reason the page felt more responsive, even though it's the same code that is running. Can be due to CloudFront Functions running closer to the client, can be my imagination, I have not done any proper measurements yet.

In short, I would say that if you can you should migrate.

Discussion (4)

Collapse
wparad profile image
Warren Parad

This is a great write-up. For what it's worth, I will mention, that this isn't a good use of a lambda, you can just deploy the index.html file twice, once to the /path/index.html and once to the /path/ location, you can also decide to upload it additionally to /path as well. This is a free solution.

Collapse
jimmydqv profile image
Jimmy Dahlqvist Author

There is actually a index.html file present under /path/ . Since links in my blog, consisting of static generated files, points to /path/ and not to /path/index.html CloudFront will request the /path/ from S3, CloudFront doesn't "speak" web server. Since there is no file in S3 called /path/ it will end up with an 404 error. Therefore the Lambda rewrites the path and append index.html so the correct file is requested from S3.
So either I have change all links to point to the actual index.html file or use a Lambda@Edge to do it for me.

Collapse
wparad profile image
Warren Parad

that's exactly my point, create a file called /path/ problem solved.

Collapse
zachjonesnoel profile image
Jones Zachariah Noel

Jimmy, brilliant read. Should definitely try out CloudFront functions. And the blog gave me all the reasons to use it over Lambda@Edge.