Use new CloudFormation support for Lambda@Edge to avoid duplicate CloudFront updates

As mentioned in this discussion, CloudFormation support is now available (LambdaFunctionAssociation property).

Of course, this plugin is still super useful because it fixes the AssumeRolePolicy Principal and the log group names & env variables problems, but since CloudFormation support is available we can now avoid the double CloudFront distribution update and define the trigger in serverless.yml as follows:

resources:
  Resources:
    ...
    WebsiteDistribution:
      Type: AWS::CloudFront::Distribution
      Properties:
        DistributionConfig:
          DefaultCacheBehavior:
            ...
            LambdaFunctionAssociations:
              - EventType: 'origin-response'
                LambdaFunctionARN: XXX

The problem is that XXX should contain the Function Version as well, and there doesn’t seem to be a way to easily reference it (CC @alexdebrie @pmuens).

[jthomerson]

@alexcasalboni - sorry for the delay on this. I’m actually working on a version 2.0 of the plugin that programmatically obtains the logical name to the Lambda::FunctionVersion resource and uses it as a Ref for LambdaFunctionARN so that the plugin can directly modify the CloudFormation template to add the associations for you, thus allowing CloudFormation’s newfound support for Lambda@Edge to do all the heavy lifting for you. This will - as you mention - remove the need for the duplicate CloudFront deployment (and developers everywhere rejoice at the time savings!)

cc @alexdebrie @pmuens

[jthomerson]

Yeah, we haven’t done any work to support simulating CloudFront events offline. That said, the format of CloudFront events is super simple, so it’s easy to write unit tests for your CloudFront-event-handling functions. That’s what we do. HTH