feat(synthetics): enable auto delete lambdas via custom resource

[kaizencc]

Synthetics used to have a property deleteLambdaResourceOnCanaryDeletion that has since been deprecated and erased from cloudformation docs. Although this property still works today synthetics makes no promises that this is supported in the future.

Here in CDK land, this PR serves as a replacement to the deleteLambdaResourceOnCanaryDeletion property (called enableAutoDeleteLambdas on the L2 Canary) by implementing a custom resource similar to what we have in S3 and ECR.

This PR deprecates enableAutoDeleteLambdas in favor of cleanup: cleanup.LAMBDA, an enum that achieves the same thing but via custom resource

Closes #18448

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[kaizencc]

Struggling whether to call this a breaking change. The behavior should stay the same... the implementation will be wildly different. I'm tempted to call it a breaking change just to make sure people's attention are called to this PR.

Also: this PR is missing proper testing

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[rix0rrr]

Struggling whether to call this a breaking change. The behavior should stay the same... the implementation will be wildly different. I'm tempted to call it a breaking change just to make sure people's attention are called to this PR.

I think the deprecation of one parameter in favor of another is the right implementation, and makes this not a breaking change. People will get deprecation warnings on using the old API, which will enough reason for them to move off of it.

[rix0rrr]

Mostly a set of questions, biggest one being the rollbackability of these cleanup handlers. Consider the following scenario:

• UPDATE target resource (replacement, creates a new resource)
• UPDATE custom resource (old -> new)
• (...stuff happens...)
• ERROR, triggers a rollback
• UPDATE custom resource (new -> old)
• DELETE target resource (deletes the new resource, remembers the existing one)

Won't we have deleted the old Lambda at that point? Since you probably copy/pasted this, it might be that all cleanup handlers suffer from this problem, but let's make sure we fix it here and then also fix it for the other ones after.

[rix0rrr]

Ufff. Is that a good experience? I don't care so much about the log group, but the S3 bucket seems like a pain?

Alternative solution:

cleanup: Cleanup.CLEANUP_LAMBDA

Which we can extend in the future with Cleanup.CLEANUP_ALL ?

[rix0rrr]

Conditionally shipped; I think the onUpdate handler can be simplified a bit more.

[rix0rrr]

This might be correct, but it feels more natural to me to get this from PhysicalResourceId.

And then the rest of this method is also quite trivial, because you can always just return newCanaryName (if it's the same, that's fine!)

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 3f582cf
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).