あるプラットフォームエンジニアリングチームは、複数のアプリケーションチームが利用できる標準化された再利用可能なインフラコンポーネント（VPC・ECSクラスター・RDS など）を提供する必要があります。アプリケーションチームは TypeScript を主に使用しており、IDE のコード補完・型安全性・ユニットテスト機能を活用してインフラを定義したいと考えています。プラットフォームチームが社内ベストプラクティスを封じ込めた高レベルな抽象化を提供する場合、最も適切なアプローチはどれですか？
AWS CDK（Cloud Development Kit）は TypeScript などの汎用プログラミング言語でインフラを定義できるフレームワークです。L3 Construct（Pattern Construct）と呼ばれる高レベル抽象化を作成することで、複数の AWS リソースをベストプラクティスで構成した再利用可能なコンポーネントをパッケージ化できます。TypeScript パッケージとして内部 npm レジストリに公開することで、アプリケーションチームは IDE のコード補完・型安全性・ユニットテスト（Jest）を活用しながらインフラを定義でき、ループや条件分岐などプログラミング言語の機能をそのまま使えます。 選択肢AのAWS CDK カスタム Construct は TypeScript パッケージとして npm レジストリで配布でき、IDE の補完・型チェック・ユニットテストをフル活用したプログラマティックなインフラ定義が実現できます。問題の要件（TypeScript・IDE 補完・型安全性・ユニットテスト・高レベル抽象化）をすべて満たします。 選択肢BのCloudFormation ネストスタックは YAML/JSON テンプレートベースであり、TypeScript の IDE 補完・型チェック・ユニットテスト機能を直接提供できません。クロススタック参照でのリソース共有は可能ですが、プログラマティックな高レベル抽象化という要件は実現できません。 選択肢CのAWS Service Catalog は承認済みテンプレートのカタログ管理とガバナンスに優れますが、TypeScript でのプログラマティックなインフラ定義や IDE 補完・型安全性・ユニットテストという要件には対応していません。 選択肢DのCloudFormation モジュールは、テンプレート内での CloudFormation リソース定義の再利用を可能にしますが、TypeScript の型安全性・IDE 補完・ユニットテスト機能は提供されず、プログラミング言語による高レベル抽象化もできません。