Impacts of AWS Lambda end of support for Node.js 16

[larrettgee]

I recently recieved an email titled "AWS Lambda end of support for Node.js 16" mentioning that I have two impacted functions from my step-by-step deployment of this repository. Specifically they are ImgTransformationStack-imageoptimization and ImgTransformationStack-LogRetention when I look at them on the Health Dashboard.

Do you have a recommended plan of action for upgrading these to ensure support is maintained and the code continues to function as expected? Thanks!

[achrafsouk]

Hello, in the latest version of the code, we upgraded NodeJs versions. So the question is how to upgrade to the latest code version, with minimal impact on production?

I can think of the following approaches, but I haven't tested any of them yet to give you an authoritative recommendation:

• Update the CDK code with the latest version and deploy again to evolve existing resources. To validate it before deploying to production, you can deploy the old code in a different account, then update with the new code, and verify if there was no issues.
• Deploy the new code with new resources, then copy generated images to the new S3 bucket, then shift traffic to the new CloudFront distribution, by moving the CNAME from the old one to the new one, in addition to the DNS change. However with this approach, CloudFront cache will need to be populated again. Also note that you'd need to verify beforehand if you can deploy the same stack twice in a single AWS Account, because we did not test this scenario.

[JanC89]

I can add some info about your second point. I tried to to change the stack name, and then ran cdk deploy.. CDK detected it needed a new deploy, but the deploy failed with:

Invalid request provided: AWS::CloudFront::ResponseHeadersPolicy: Another response headers policy with the same name already exists within the aws account.

It seems to be because the policy name needs to be unique, and it is always set to responseHeadersPolicyName: 'ImageResponsePolicy',

[achrafsouk]

@JanC89 did a quick fix to make it work https://github.com/aws-samples/image-optimization/commit/6b4d7dd1872e0ae682e8e1de1634b1c270b5e2b5

[larrettgee]

@achrafsouk thanks for the input! I believe I'll take your second recommended approach. I am not well versed in AWS, so don't want to accidentally burn myself. Do you mind if I ask a few questions?

1. A "Deploy the new code with new resources" is effectively just following the guide again, correct? Should work with no issues now that you made this change https://github.com/aws-samples/image-optimization/commit/6b4d7dd1872e0ae682e8e1de1634b1c270b5e2b5
2. Do you have guidance on how to properly copy generated images to the new S3?
3. Any guidance on how to make DNS/CNAME changes?
4. With the CloudFront cache needing to be repopulated, this will simply cause minor delays on the users end, no loss of images, correct?

Thank you so much, I really appreciate it!

[achrafsouk]

1. Yes, but I highly recommend you to try this operation first on a non production environment
2. Use the AWS CLI, with the S3 sync command to copy all images from the old generated image bucket to the new one
3. Since both distributions are in the same AWS Account, follow steps described in Use the AssociateAlias API to move your CNAME. Don't forget at the end to change the DNS record of your domain to point to the new distribution
4. It will cause cache misses, so additional delays for your users for a couple of hours. It's best to do it in low traffic time.

[larrettgee]

Thanks so much! In the original guide, I used the option cdk deploy -c S3_IMAGE_BUCKET_NAME=’YOUR_S3_BUCKET_NAME’

Is it a valid option to have the new deploy link to the same bucket & skip the step on moving images?

[achrafsouk]

the new deploy has to point to the same bucket holding the original images. Its the bucket from which the Lambda will fetch images for processing. The bucket I was talking about was the bucket created by the solution that holds the generated images. Copying images from this bucket is optional, but highly recommended to avoid having your Lambda to generate all image variants again.

[larrettgee]

Got it, thanks. When I ran the cdk deploy command, I received the same ImgTransformationStack.ImageDeliveryDomain that I previously had. When I look at my distributions I only see 1. I also am not able to query the ListConflictingAliases endpoint after trying several method.

EDIT: I redeployed and fixed the lambda function error, but still have the same alias. Maybe I can just leave it as is?

[achrafsouk]

Ah! because you have probably used the same application name in the cdk project. It means that you have in reality followed the first option for migration, which is upgrading the existing stack, and i am glad it worked without any challenges.

[Hipocrita]

I modified several things, changed the code to add the quality option and also put two distributions together in the same cloudfront, with an alias, one for transforming images and the other for CDN.

These changes... will they reset?

[achrafsouk]

Reset following what?