開発チームがAWS CloudFormationを使用してインフラをプロビジョニングしています。スタック作成・更新・削除のライフサイクルに応じて、DynamoDBテーブルへの初期データ投入やサードパーティAPIへの登録など、CloudFormationがネイティブにサポートしていないカスタム処理を自動実行する必要があります。最も適切な実装方法はどれですか？
CloudFormationカスタムリソース（AWS::CloudFormation::CustomResourceまたはCustom::MyResource）を使用すると、CloudFormationがネイティブにサポートしていない処理をスタックのライフサイクルに組み込めます。Lambda関数をバックエンドとして設定すると、スタックのCreate・Update・Delete時にLambdaが自動呼び出しされカスタムロジックを実行できます。LambdaはCloudFormationへの応答（SUCCESS/FAILED）をプリサインドURLへ送信する必要があり、処理の成否がスタックの進行に反映されます。 選択肢AのAWS::CloudFormation::Initは、EC2インスタンス上でcfn-initを使ったソフトウェアインストール・設定に特化したメタデータであり、EC2インスタンスが存在しないカスタム処理やDynamoDB操作などの汎用処理には使えない。 選択肢CのWaitConditionは外部シグナルを待つ同期処理に使いますが、カスタムロジック自体を実行する機能ではなく、外部でシグナルを送る仕組みを別途構築する必要があり、スタック削除時には機能しない。 選択肢DのSystems Manager Automationは有効なサービスですが、EventBridgeとの組み合わせではCloudFormationのライフサイクルと緊密に統合されておらず、スタック削除時の確実な連動が難しい。