Lambda@Edge example for the CloudFront construct documentation

https://docs.aws.amazon.com/cdk/api/latest/docs/aws-cloudfront-readme.html

https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-cloudfront.LambdaFunctionAssociation.html

It wasn’t clear to me from the API reference how to add a Lambda function to a CloudFront distribution. I got my Lambda@Edge implementation working, but there were a few gotchas for me.

The first gotcha was that CloudFront requires a numbered Lambda version, but it wasn’t apparent to me at first. It seems that I had to explicitly create a new lambda version to put in the LambdaFunctionAssociation so that CloudFront will accept it. Although the type for LambdaFunctionAssociation takes a lambda.IVersion for lambdaFunction, attempting to use a Lambda function’s latestVersion member will cause a deployment error as it provides $LATEST which isn’t a numbered Lambda version and causes CloudFront to reject it and to roll back the stack.

There were a few other gotchas for me too, but I suppose that all of this was a learning process for me, as I’ve never done Lambda@Edge before… The gotchas were: Environment variables and the NODEJS_12_X runtime are not supported. Both mistakes on my part made it through CDK synthesis without a hitch, however, but they fail to deploy.

I think an example showing how to do Lambda@Edge and some mention of the special CloudFront Lambda requirements might be useful.

Here’s how I did it, but I feel like it’s a shaky example at best:

// Origin request handler.
const myOriginRequestHandler = new lambdaNodejs.NodejsFunction(this, "OriginRequestHandler", {
  entry: "src/lambda/myOriginRequestHandler.ts",
  handler: "myOriginRequestHandler",
  runtime: lambda.Runtime.NODEJS_10_X,
});

// A numbered version to give to cloudfront
const myOriginRequestHandlerVersion = new lambda.Version(this, "OriginRequestHandlerVersion", {
  lambda: myOriginRequestHandler,
});

// A bucket to serve content from
const myBucket = new s3.Bucket(this, "OriginBucket");

// Origin access identity for cloudfront to access the bucket
const myCdnOai = new cloudfront.OriginAccessIdentity(this, "CdnOai");
myBucket.grantRead(myCdnOai);

// The CDN web distribution
new cloudfront.CloudFrontWebDistribution(this, "Cdn", {
  originConfigs: [
    {
      s3OriginSource: {
        s3BucketSource: myBucket,
        originAccessIdentity: myCdnOai,
      },
      behaviors: [
        {
          isDefaultBehavior: true,
          lambdaFunctionAssociations: [
            {
              eventType: cloudfront.LambdaEdgeEventType.ORIGIN_REQUEST,
              lambdaFunction: myOriginRequestHandlerVersion,
            }
          ]
        }
      ]
    }
  ],
});

---

This is a 📕 documentation issue

[firxworx]

There’s the new experimental.EdgeFunction in @aws-cdk/aws-cloudfront that provides a convenience setup for creating these Lambda@Edge functions (which are created in us-east-1 as required by CloudFront, regardless of the region of the stack).

[mattrigg9]

The cross region problem is unfortunately a Lambda@Edge limitation, not CDK. There is no method that is both simple and scalable, but here are a few options:

• Manually pass the Lambda@Edge ARN with version to the CloudFront construct (this does not scale. You must update CloudFront with the new version ARN every time you update the lambda)
• Build your primary stack in your own region. Build a second stack just for Lambda@Edge in us-east-1. Inside your primary stack, build a CustomResourceProvider construct in CDK that uses a Lambda function to fetch stack outputs from other regions. I’ve toyed around with this concept myself and while its not completely functional yet, it should have most what you need to get started: https://github.com/mattrigg9/cdk-stack-output-provider