revert(certificatemanager): deprecate DnsValidatedCertificate

[stoyan-scava]

Undo deprecate DnsValidatedCertificate

DnsValidatedCertificate is the only construct that have automatically cleanup of
DNS validation records when the Certificate is deleted.

closes #23952
closes #23931

revert #21982

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[corymhall]

@stoyan-scava I've commented on this issue before, but hopefully I can explain our position here. Typically in the aws-cdk Custom Resources are used as glue code or to fill in minor gaps in CloudFormation functionality. In rare cases we use Custom Resources to actually create entire resources that don't have official CloudFormation resource coverage.

In the case of the DnsValidatedCertificate, it was created because the official Certificate resource did not support DNS validation. Over time this resource grew in functionality until it became clear that the expectation from users was that it would be a full fledged CloudFormation resource, but implemented as a Custom Resource. This is not a use case that we want to support in aws-cdk. There is already an official CloudFormation Certificate resource that now supports DNS validation. Any limitations in that resource should be raised with CloudFormation and should be added to the official resource. We do not want to continue to add new functionality to DnsValidatedCertificate. We could revert the deprecation, but then it would be deprecated in reality if not in name.

DnsValidatedCertificate is the only construct that have automatically cleanup of
DNS validation records when the Certificate is deleted.

This should be something that the official Certificate resource should handle.

[vincent-dm]

But the whole point of CDK is making CloudFormation usable! Pointing to other departments is really unhelpful, and it would be a much better customer experience if the CDK feature was deprecated only after CloudFormation was enhanced.

[dendle]

@corymhall Please can we entertain making a specific construct that allows us to create certificates in us-east-1, to work around the glaring issue of Cloudfront requiring certificates to be hosted there, before we deprecate the only alternative? Creating an entire stack for a certificate to exist in another region is nuts.

[corymhall]

Creating an entire stack for a certificate to exist in another region is nuts.

I am 100% onboard with doing something similar to how we handle Lambda@Edge where the cdk handles creating the stack in us-east-1 for you. We've talked about doing something in core to handle this scenario so that we don't have to reimplement it for every use case, but haven't had the time to work on it. If someone wants to work on a PR to add it to certificatemanager, we would review it.

CDK feature was deprecated only after CloudFormation was enhanced.

Deprecation in the aws-cdk means two things:

1. We will no longer add features and enhancements to the deprecated API.
2. The deprecated API will be removed in the next major release.

#1 is the reason we deprecated DnsValidatedCertificate. As I explained, maintaining this construct requires us to keep feature parity (+ additional features) with the official Certificate construct. This is not the type of thing we want to support in core.

For #2 we currently do not have any plans for a v3.

[vincent-dm]

For #2 we currently do not have any plans for a v3.

Ok, that's good to know. I didn't realize that with major release, you actually meant the number before the dot. I guess we are safe for a while indeed.