AWS CDK は『コードでインフラを書く』IaC の最先端
AWS CDK は TypeScript/Python 等の汎用言語で AWS リソースを定義できる IaC ツールです。本記事では編集部の視点で、実務で活用するための要点を公開情報をもとに整理します。Terraform 実践 もご参考に。
CDK の主要コンセプト
(1) App：CDK アプリケーションのルート。(2) Stack：CloudFormation スタック単位。(3) Construct：再利用可能なコンポーネント。L1/L2/L3 のレベル。(4> Synthesize：CloudFormation テンプレートを生成。(5) Deploy：CloudFormation 経由でデプロイ。
Terraform との比較
(1) CDK：型安全・条件分岐/ループが自然・AWS 限定。(2) Terraform：マルチクラウド・宣言的・コミュニティ大。(3) CDK for Terraform：両者の良いとこどり。(4) 判断軸：AWS 専業なら CDK、マルチクラウドは Terraform。(5) 移行容易性：CDK は CloudFormation 経由でロックイン要素あり。
Construct の使い分け
(1) L1 (Cfn*)：CloudFormation 直結。細かい制御。(2) L2 (高レベル)：デフォルト値+型安全。実務の主役。(3) L3 (パターン)：複数リソースをまとめたユースケース指向。(4) 自作 Construct：社内標準を組み込む。(5) Construct Hub：コミュニティ製品。
本番運用のパターン
(1) Stack 分割：環境別 + 機能別。(2) cdk diff：PR で差分確認。(3) cdk deploy --hotswap：開発時の高速反映。(4) Pipelines：CDK Pipeline で自己更新。(5) テスト：jest で構成のスナップショット・アサーション。CI/CD 実践 も合わせて。
シークレットと環境設定
(1) Context (cdk.context.json)：環境別の値。(2) Parameter Store / Secrets Managerからの取得。(3) Stage：複数環境への一括デプロイ。(4) IAM 最小権限：CDK のロールも厳格に。(5) 本番への手動承認：Pipeline で。Secrets 管理 も合わせて。
失敗しがちなパターン
(1) 巨大 Stack：deploy が遅い+変更影響大。(2) Construct の過剰抽象化：理解困難に。(3) L1 多用：L2 の利点喪失。(4) cdk synth せずデプロイ：意図しない差分発生。(5) ローカル AWS 認証放置：誤って本番反映。対策は、(1)Stack 分割、(2)Construct は最小、(3)L2 優先、(4)CI で synth、(5)プロファイル/AssumeRole 厳格、です。