Lambda@Edge in SAM

[sanathkr]

There was a discussion on Twitter that made me wonder if we should support Lambda@Edge native in SAM.

We already have a SAM example showing how to enable Lambda@Edge - https://github.com/awslabs/serverless-application-model/blob/master/examples/2016-10-31/lambda_edge/template.yaml. But this still requires setting up a CloudFront distribution and IAM Roles manually.

Can we add a Edge: True property to AWS::Serverless::Function resource that makes the function Lambda@Edge enabled? Will this be useful?

Please comment or +1 (reactions) if you will be interested in this feature.

[brysontyrrell]

I would like to voice that doing this would ease a lot of deployment headaches. My expectation is that this key value would abstract away the AWS::Lambda::Version objects and handle creating and associating a new version on every update of the Edge function's code.

[yvele]

With a Edge: True the Lambda@Edge can systematically be deployed by SAM in us-east-1 (as strictly required by Lambda@Edge) notwithstanding in which other region the Cloudformation stack (then CloudFront) is deployed.

Is that possible within SAM? 🤔 That could be awesomely great!

Resolving issue #635

[martysweet]

This feature should also consider the time it takes to perform a Lambda@Edge update, due to the CloudFront distribution update time which CloudFormation waits for.

It is fine for the update to take a while if updating a Lambda function, as long as code has actually changed, and such, would be nice to somehow compare versions to prevent unnecessary new Lambda versions and deployments (though may be out the scope of this feature).

[iDVB]

Would also love to see Lambda@Edge abstraction in SAM. We're currently in the process of porting over some of our Serverless Framework implementations to SAM and Edge functions are something we use heavily.

I'd like to point out a few things that would also be great if this support included.

1. Stacks containing Edge functions fail when deleting the stack. This will always happen unless the edge functions have DeletionPolicy: Retain which can also cause orphan functions but will allow stacks to delete successfully. Support for `DeletionPolicy in this abstraction would be great.

2. There is already a Serverless Framework plugin/abstraction for Lambda@Edge functions that we use that is great. It might be helpful to read up on how that was implemented to see all the lessons learned.

[keetonian]

@iDVB Could you provide some more information on what you'd like SAM to provide as part of support for Lambda@Edge?

[iDVB]

@keetonian Sorry, I meant it more as a mention if there aren’t already ways to do this with SAM. I’m brand new to it; previously using Serverless Framework exclusively. Once I take an honest dive in, I should have a better feel for what might be missing. Just could not google much in the way of Lambda@Edge and SAM. But I’m starting to think this is because SAM doesn’t really abstract functions and so they are handled the same regardless of edge or not.

[falnyr]

@sanathkr is there any update on this?

[ugurcemozturk]

Hey, any update on this? It's getting used more and more

[aprilmintacpineda]

Any updates?

[hungnv-sr]

4 years and a half later, any update?

[wynged]

The stack deletion barrier has become a problem for us as well, we can't use the Lambda@Edge in our development stacks because they won't clean themselves up which would leave orphaned functions behind.

[Eeasan]

any update?

[johanna-herrmann]

Any update?