I would like to be able to access the SHA256 hash of the zipfile created by a Lambda function's build process, whether built through Code.fromAsset or via a higher-level package like aws-lambda-nodejs.

Use Case

My specific use-case has to do with Lambda@Edge functions (see also #1575), and the requirement that those functions have a deployed version. However, this request would benefit any user who wanted a new lambda Version created when they change their Lambda's source code.

From the searching I've done, it appears that some folks manually read in the contents of the lambda function and create a hash manually, like this:

const sha256 = require('sha256-file');
const version = lambda.addVersion(':sha256:' + sha256('./lambda/index.js'));

However, with the introduction of additional build functionality via aws-lambda-nodejs, this process starts to break down. Imagine updating your lambda's dependencies via package.json or package-lock.json. The source file (e.g. index.ts) does not get updated, but the resultant zipfile would get a new hash, with the new dependencies. So, what you'd really want in this case, is access to the SHA256 of the zipfile after the build process has completed.

Proposed Solution

I could see allowing access to the source hash via a property on the lambda function. For instance:

const myLambda = new lambda.NodejsFunction(this, 'MyFunction', {
  entry: path.join(__dirname, 'my-lambda', 'index.ts')
  handler: 'myExportedFunc'
});

const version = new lambda.Version(this, `Version-${myLamda.zipFile.sha256}`, {
  lambda: myLambda
});

// Reference `version` later on, like in the CloudFront Lambda@Edge config

The only issue I see right away is when the lambda code is not generated locally, like when it references an S3 object. In that case, maybe we'd need to throw a runtime exception? I'm not 100% sure.

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

This is a 🚀 Feature Request