[cloudfront] [lambda] Cross-region Lambda construct for Lambda@Edge

[njlynch]

Create a construct (e.g., EdgeLambda) which facilitates defining Lambda functions cross-region.

Use Case

CloudFront is a "global" service, but requires that both certificates and Lambda@Edge functions be defined in us-east-1 (N Virginia) to use them with a distribution. This creates a lot of overhead for users who have stacks that include CloudFront in different regions.

Customers must have separate stacks to host the Lambda function, then use SSM (or another alternative) to communicate the ARN between stacks. See #1575 (comment) for a detailed explanation of the process as it exists today.

Proposed Solution

The other CloudFront-constrained service (AWS Certificate Manager) has a custom resource for this purpose: DnsValidationCertificate. Stealing ideas from that pattern may be useful. One of the complications for Lambda (vs ACM) is that Lambda functions often require assets, which is more heavy-weight than just passing the defining parameters/props.

CodePipeline has a mechanism for cross-region deployments (see the README section titled 'Cross-region CodePipelines'). This relies on creating sub-stacks in the target region with defined buckets for replicating the assets:

aws-cdk/packages/@aws-cdk/aws-codepipeline/lib/pipeline.ts

Line 467 in b5f2f75

private createSupportResourcesForRegion(otherStack: Stack | undefined, actionRegion: string):

---

This is a 🚀 Feature Request

[robertd]

@njlynch This might be premature to ask right now, but would it be possible to handle Lambda@Edge scenarios where experimenting with it (especially renaming/deleting) causes stack deployments to fail due to the nature of lambda@edge versioning? Due to this we've elected to move out L@E into separate stack/repo (that and region issue of course)... Same goes for ACM :).

Note: I've noticed this by using aws-solutions-construct library which currently uses older version of the aws-cloudfront constructs (awslabs/aws-solutions-constructs#39). Also, aws-solutions-constructs doesn't do multi-region deployments for their aws-cloudfront-s3 solution (everything goes into us-east-1). Thus, this issue is something I'm excited to see in action (and it hopefully trickles down to aws-cloudfront-solutions repo at some point). 👍

[jbaileyashe]

@robertd did you ever find a workaround for dealing with Lambda@Edge functions? Waiting 24 hours to try and destroy again is pretty painful.

A hack that would work is for the Lambda@Edge API to return a 200/204 when you try to delete a replicated function. CloudFront is going to delete it automatically anyways, so why give the user a spurious error?

I posted a forum thread, if anyone would like to show support for the idea: https://forums.aws.amazon.com/thread.jspa?threadID=331402

[robertd]

@jbaileyashe Unfortunately no. We have name suffix randomizer component added to our Lambda@Edge functions so that each time we make change new function is deployed (rather than changed/deleted) and associated to our CF distro. Then we clean them up later on through scheduled task thru Gitlab CI/CD.

Edit:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-delete-replicas.html and https://aws.amazon.com/blogs/networking-and-content-delivery/managing-lambdaedge-and-cloudfront-deployments-by-using-a-ci-cd-pipeline/

If you delete the stack, you’ll get a DELETE_FAILED error. This happens because, when you delete the stack, CloudFormation tries to delete the master Lambda@Edge function. But the master Lambda Function can only be deleted after CloudFront removes all of the Lambda@Edge replicas, which can take hours. So wait a few hours, and then try again to delete the stack, and then it will work.

[nihakue]

Our teams have also had success with a custom resource provider that creates the source code s3 bucket and lambda function using the aws sdk. It's a bit ick, but it lets you keep everything in one stack. I can't share code, but basically:

1. create a bucket in the region to want to deploy to and put the lambda source code in it (can be done with normal constructs)
2. Create a custom resource that:
   a. create a bucket in us-east-1
   b. copies source from bucket in your region to us-east-1
   c. creates lambda in us-east-1
   d. returns created lambda version/arn

I'm glad this problem is being addressed since it's been a huge pita for us, but are you also putting pressure on the Lambda@Edge / ACM teams to remove this constraint?

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.