開発チームがAWS CloudFormationでインフラをコード管理しています。CloudFormationがネイティブサポートしていない外部DNSプロバイダー（Route 53以外）へのDNSレコード追加を、スタックのデプロイ・削除のライフサイクルと連動して自動管理したいと考えています。最も適切なアプローチはどれですか？
CloudFormation Custom Resource（AWS::CloudFormation::CustomResource または Custom::プレフィックスの独自タイプ）は、CloudFormationがネイティブサポートしていない任意の処理をスタックのCreate/Update/DeleteライフサイクルにネイティブUI統合する機能です。ServiceTokenにLambda関数ARNを指定すると、スタック操作のたびにLambda関数が呼び出されます。Lambda関数は外部DNSプロバイダーのAPIを呼び出した後、cfn_responseモジュール（またはPresigned URLへのHTTPリクエスト）でCloudFormationにSUCCESS/FAILUREを通知します。スタック削除時にはRequestType: Deleteとして呼び出されるため、DNSレコードの自動削除も確実に実現できます。 選択肢AのWaitConditionはEC2インスタンスなど既存リソースからのシグナルを待機してスタック作成を一時停止する機能であり、外部APIの呼び出しやリソースのCRUD操作を管理する機能ではありません。 選択肢CのEventBridgeによるイベント駆動構成では、スタック削除イベントを確実に検知してDNSレコードを削除する保証が困難で、スタックの状態とDNSレコードの整合性が保証できません。 選択肢DのStep FunctionsはCloudFormationスタックのCreate/DeleteライフサイクルイベントへのネイティブUIフック機能を持たないため、Custom Resourceの代替にはなりません。