AWS CDK
TypeScript や Python などのプログラミング言語で AWS インフラを定義し、CloudFormation テンプレートとしてデプロイできる IaC フレームワーク
概要
AWS Cloud Development Kit (CDK) は、使い慣れたプログラミング言語 (TypeScript、Python、Java、C#、Go) で AWS インフラストラクチャを定義できるオープンソースの Infrastructure as Code (IaC) フレームワークです。CDK で書いたコードは内部的に CloudFormation テンプレートに変換 (シンセサイズ) され、CloudFormation 経由でデプロイされます。L1 (CloudFormation リソースの 1 対 1 マッピング)、L2 (ベストプラクティスが組み込まれた高レベル抽象化)、L3 (複数リソースを組み合わせたパターン) の 3 層のコンストラクトにより、数行のコードで本番品質のインフラを構築できます。
L1・L2・L3 コンストラクトの使い分け
CDK のコンストラクトは抽象度によって 3 つのレベルに分かれます。L1 コンストラクト (CfnXxx) は CloudFormation リソースの直接的なラッパーで、CloudFormation で設定可能なすべてのプロパティにアクセスできます。L2 コンストラクトは最も多用されるレベルで、たとえば s3.Bucket を作成すると、暗号化の有効化、パブリックアクセスのブロック、バージョニングの設定などがデフォルトで適用されます。L3 コンストラクト (パターン) は LambdaRestApi のように複数のリソース (Lambda + API Gateway + IAM ロール) を一括で構築します。実務では L2 を中心に使い、L2 で対応できない細かい設定だけ L1 のエスケープハッチで補完するアプローチが推奨されます。
プログラミング言語で書く IaC の強みと注意点
CDK の最大の特徴は、TypeScript や Python などの汎用プログラミング言語でインフラを定義できる点です。ループ、条件分岐、関数、クラス継承などの言語機能を活用でき、複雑なインフラパターンの再利用や動的な構成生成が容易になります。Terraform の宣言型言語 (HCL) と比べると、コードの表現力は圧倒的に高い反面、プログラミング言語の柔軟性が裏目に出て意図しないリソース変更が発生するリスクもあります。cdk diff で差分を確認する習慣が重要です。マルチクラウド対応が必要な場合は Terraform が適しますが、AWS 専用環境では CDK の生産性が際立ちます。IaC の関連書籍 (Amazon) で設計パターンを体系的に学べます。
スタック分割とテスト戦略
CDK の実務導入で最初に決めるべきは、スタックの分割戦略です。すべてのリソースを 1 つのスタックに詰め込むと、デプロイ時間が長くなり、1 つの変更が全リソースに影響するリスクがあります。ネットワーク (VPC)、データストア (RDS、DynamoDB)、コンピュート (Lambda、ECS) のように責務ごとにスタックを分割し、スタック間の依存は SSM パラメータストアや CloudFormation エクスポートで疎結合にする設計が推奨されます。テスト面では、cdk-nag によるセキュリティ・コンプライアンスチェック、Assertions モジュールによるスナップショットテスト・ファイングレインドテストが標準で利用でき、インフラコードの品質を CI/CD パイプラインで自動検証できます。CloudFormation テンプレートへの変換 (シンセサイズ) 結果をテストすることで、デプロイ前に意図しない変更を検出できるのが CDK ならではの強みです。