AWS CDK（cdk）とは？スタックの仕組みとcdk deployの使い方、CloudFormation・Terraformとの違い

AWS CDK（AWS Cloud Development Kit）は、TypeScriptやPythonなどのプログラミング言語でAWSのインフラを定義し、AWS CloudFormationのスタックとしてデプロイするオープンソースのフレームワークです。開発の文脈で「cdk」と言えばこれを指します。医療のCKD（慢性腎臓病）や、生物学のCDK（サイクリン依存性キナーゼ）とは別物です。この記事では、AWS CDK v2開発者ガイドとnpm registryの値をもとに、CDKの構成要素、最初のスタックをデプロイする手順、スタックの分割とクロススタック参照、テスト、Terraformなどとの使い分けまでを2026年10月時点の版で整理します。

まとめ：AWS CDKとスタック運用の要点（2026年10月時点）

• AWS CDKはライブラリ aws-cdk-lib とCLI aws-cdk の2つでできており、書いたコードはCloudFormationテンプレートに合成されてデプロイされます。CDK自体は無料です。
• 現行はv2です。最新は aws-cdk-lib 2.275.0、CLIは2.1146.1で、Node.jsは22か24を使います。20系のCDKサポートは2026年10月30日に終わります。
• 1つのCDKスタックは1つのCloudFormationスタックになります。最初の1本は cdk init・cdk bootstrap・cdk synth・cdk diff・cdk deploy の順で出します。
• ファイルを分けたいだけならスタックは分けません。スタックを分けるのは、更新頻度が違うリソースを切り離したいときです。
• スタック間の参照は、2026年5月以降の版で Fn::GetStackOutput を使う弱い参照を選べます。新規プロジェクトはこれが既定で、既存の参照は BOTH を経由して2回のデプロイで移します。
• 1スタックのリソース上限は500です。--hotswap と cdk watch は開発環境に限ります。
• AWSに閉じた構成をTypeScriptなどで書けるチームなら採用し、マルチクラウドや既存のTerraform資産がある現場では見送ります。

AWS CDKとは：プログラミング言語でAWSインフラを定義するIaCフレームワーク

CDKは、インフラの最終形をコードで宣言するIaC（Infrastructure as Code）の道具です。「こうなっていてほしい」という最終形を書けば、CloudFormationが現状との差分を計算して作成・更新する宣言型の仕組みです。コードは手元やCIで実行され、出てくるのはCloudFormationテンプレートです。実際にリソースを作るのはCloudFormationなので、失敗時の自動ロールバックやドリフト検出もそのまま使えます。

aws-cdk-libとCDK CLIの2つの構成要素と対応する6言語

CDKは2つの部品に分かれます。1つはAWSリソースを表す部品（コンストラクト）を集めたライブラリ aws-cdk-lib、もう1つは合成やデプロイを実行する cdk コマンド（CDK CLI、npmパッケージ名は aws-cdk）です。v1ではサービスごとに別パッケージを入れていましたが、v2で aws-cdk-lib 1つにまとまりました。

公式が正式にサポートする言語は、TypeScript、JavaScript、Python、Java、C#、Goの6つです。CDK本体はTypeScriptで書かれており、ほかの言語へはJSIIというツールでバインディングを生成しています。公式のサンプルコードもTypeScriptが中心なので、言語に迷うならTypeScriptを選ぶと調べ物で詰まりにくくなります。

L1・L2・L3コンストラクトの抽象度と使い分け

コンストラクトには抽象度の違う3つの層があります（公式のコンストラクト解説）。

普段はL2で書きます。L2は権限付与の grant 系メソッドや既定値を持ち、L1で個別に設定するより記述量を減らせるからです。L1はクラス名が Cfn で始まり、CloudFormationのリソース仕様から自動生成されます。新しいリソースやプロパティがL1に載るまでには最大1週間ほどかかると公式は書いています。L2が用意されていないサービスや、L2が隠しているプロパティを直接指定したい箇所だけL1に降ります。

v1のサポート終了とv2の版・Node.jsの要件（2026年10月時点）

CDK v1は2022年6月1日に保守モードへ入り、2023年6月1日にサポートを終えています。新規に選ぶのはv2だけです。

2026年10月27日時点のnpm registryでは、ライブラリの aws-cdk-lib は2.275.0（10月26日公開）でNode.js 20以上、CLIの aws-cdk は2.1146.1（10月22日公開）でNode.js 18以上を条件にしています。ただし、これはインストールできる下限の話です。CDKのNode.jsサポート表では、18系のサポートは2025年11月30日に終わり、20系も2026年10月30日に終わります。サポートが続くのは22系（2027年10月30日まで）と24系（2028年10月30日まで）なので、これから環境を作るなら22か24を入れてください。CDKはNode.jsのコミュニティEOLから6か月だけサポートを延長する方針で、前提条件のページも言語にかかわらずNode.js 22以降を求めています。

AWS CDKで最初のスタックを作る手順：インストールからcdk deployまで

1つのスタックをデプロイするまでの最短経路です。手順は公式チュートリアル「Create your first AWS CDK app」に沿っています。事前にAWS CLIの認証情報を設定しておきます。

npm install -g aws-cdkとcdk initでのスタック雛形の生成

$ npm install -g aws-cdk
$ cdk --version
$ mkdir hello-cdk && cd hello-cdk
$ cdk init app --language typescript

cdk init のテンプレートは、最小構成の app、サンプルリソース付きの sample-app、コンストラクトライブラリ用の lib の3種類です。hello-cdk ディレクトリで app を選ぶと、lib/hello-cdk-stack.ts に HelloCdkStack というスタッククラス、bin/hello-cdk.ts にそれをAppへ登録するコード、test/hello-cdk.test.ts にテストの雛形ができます。

生成されたスタッククラスにS3バケットを1つ足すと、デプロイして確かめられる最小構成になります。検証用なので、削除時にバケットごと消える設定にしています。

// lib/hello-cdk-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';

export class HelloCdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    new s3.Bucket(this, 'MyFirstBucket', {
      versioned: true,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true,
    });
  }
}

この数行から合成されるテンプレートには、バケット本体のほかにバケットポリシー、IAMロール、Lambda関数、カスタムリソースの5つが入ります。autoDeleteObjects が削除時にオブジェクトを消すための仕組みを自動で足すためです。L2の1行が複数のリソースに展開される点は、cdk synth の出力で一度確かめておくと後の差分確認が楽になります。

cdk bootstrap・synth・diff・deployの順に1スタックを出す流れ

$ cdk bootstrap aws://123456789012/ap-northeast-1
$ cdk synth
$ cdk diff
$ cdk deploy HelloCdkStack

1. cdk bootstrap：デプロイ先の環境に CDKToolkit というスタックを作り、アセット置き場のS3バケットやデプロイ用のIAMロールを用意します。アカウントとリージョンの組ごとに1回です。
2. cdk synth：コードを実行し、cdk.out にスタックごとのCloudFormationテンプレートを出力します。
3. cdk diff：デプロイ済みの状態との差分を表示します。
4. cdk deploy：変更セットを作って適用し、CloudFormationスタック HelloCdkStack が作成されます。

デプロイ後にCloudFormationのコンソールを開くと、HelloCdkStack が並んでいます。不要になったら cdk destroy HelloCdkStack で削除します。ブートストラップで作られるロールの内訳と更新手順はcdk bootstrapが作る5つのIAMロールとテンプレート版32の更新手順にまとめています。

CDKスタックとCloudFormationスタックの1対1対応と合成の仕組み

デプロイの最小単位としての1スタック1テンプレート

開発者ガイドのスタックの章は、スタックを「デプロイの単一かつ最小の単位（the smallest single unit of deployment）」と定義しています。1つのCDKスタックに含まれるリソースは、まとめて1つのCloudFormationスタックとして展開されます。CloudFormationのテンプレートに500リソースの上限があれば、CDKの1スタックに詰め込めるリソースも500までです。CloudFormation側のテンプレート構造やスタック操作はAWS CloudFormationとは？テンプレートの書き方・スタック操作と更新で消える設定の防ぎ方で扱っています。

App・Stack・Constructの階層とパラメータを使わない理由

CDKアプリは、最上位のApp、その下のStack、さらに下のConstructという入れ子です。cdk synth はスタックごとに別々のテンプレートを出力し、同じクラスから作った2つのスタックでも2枚の独立したテンプレートになります。

CloudFormationでは1枚のテンプレートをパラメータで切り替えて複数回デプロイするのが一般的ですが、CDKは合成の時点で値を確定させる設計です。パラメータはデプロイ時にしか解決されず、コード側で値を見て分岐できないため、公式もCloudFormationパラメータの利用を勧めていません。環境ごとの差分はTypeScriptの if 文で書きます。同じテンプレートを複数アカウント・複数リージョンへ一括展開したいなら、CDKのマルチスタックよりCloudFormation StackSetsの権限モデル・デプロイオプションと更新の落とし穴で扱う仕組みが候補になります。

Stackクラスでスタックを定義する書き方と命名・環境の指定

lib配下のスタックとbin配下のAppの分担

スタックは Stack クラスを継承して定義し、Appの中でインスタンス化して初めてデプロイ対象になります。cdk init の lib と bin の分担はこの形です。

// bin/my-app.ts
import * as cdk from 'aws-cdk-lib';
import { MyCdkStack } from '../lib/my-cdk-stack';
const app = new cdk.App();
new MyCdkStack(app, 'MyCdkStack', {});

同じAppに new MyFirstStack(app, 'stack1') と new MySecondStack(app, 'stack2') を並べれば、そのままマルチスタック構成になります。

スタック名の自動生成規則とstackNameの明示・128文字上限

CloudFormationスタックの物理名は、コンストラクトツリー上のパスからCDKが決めます。公式の cdk ls の出力例では、beta環境とprod環境に3スタックずつ持つアプリが betacpDA8372D3 や prodmon631A1083 のように、パスの連結にハッシュが付いた名前になっています。組織の命名規則や既存のスタック名に合わせたいときは stackName で上書きします。

new MyStack(this, 'not:a:stack:name', { stackName: 'this-is-stack-name' });

スタック名の上限は128文字です。パイプラインのように階層が深い構成では自動生成の名前が長くなりやすいので、明示指定に倒します。

envの省略で起きる2つの制約とcdk.context.jsonのコミット

env を省略したスタックは環境非依存（environment-agnostic）になり、アカウントとリージョンはCloudFormationの擬似パラメータに置き換わります。

new MyDevStack(app, 'dev', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: process.env.CDK_DEFAULT_REGION,
  },
});

環境非依存にすると2か所で詰まります。1つは stack.availabilityZones で、実際のリージョンを問い合わせられないため常に2つのAZを返します。3AZを前提にした構成でも、テンプレートは2AZで出力されます。もう1つは Vpc.fromLookup() のような既存リソースの引き当てで、照会先のアカウントが決まらないので動きません。既存VPCを使う構成では env の明示が前提です。

fromLookup 系で取得した値は、プロジェクト直下の cdk.context.json にキャッシュされ、次回以降の合成はこの値を使います。公式のコンテキストの章は、cdk.json と cdk.context.json をソース管理にコミットするよう求めています。コミットしないと、CIのように別の場所で合成したときにAZやAMIの照会結果が変わり、意図しない差分が出ます。古い値を捨てたいときは cdk context で確認したキーまたは番号を指定する cdk context --reset KEY_OR_NUMBER、または全キャッシュを消す cdk context --clear を使います。

複数スタックへの分割基準とクロススタック参照の強い参照・弱い参照

スタック分割とファイル分割の切り分け：ライフサイクルで判断

ソースが肥大化したからスタックを分ける、という判断は目的と手段がずれています。CDKでは、1つのスタックのまま定義をコンストラクトとして複数ファイルへ切り出せるからです。

スタックを分ける理由になるのは、ライフサイクルが違うときです。VPCやRoute 53のホストゾーンのようにほとんど変えないリソースと、日に何度も入れ替わるLambda関数やECSサービスを同じスタックに置くと、更新のたびに前者まで変更セットの評価対象になります。同時に作られ同時に捨てられるリソースを別スタックへ切り出しても、次に述べる参照の手間が増えるだけです。

既定のExportとFn::ImportValueが参照を外すときに起こすデッドロック

別スタックのリソースは、生成側が属性として持ち、消費側のコンストラクタへ渡します（公式「Resources and the AWS CDK」）。次のコードは、バケットを公開する StackThatProvidesABucket と受け取る StackThatExpectsABucket を別に定義した前提の、接続部分の抜粋です。

const prod = { account: '123456789012', region: 'us-east-1' };
const stack1 = new StackThatProvidesABucket(app, 'Stack1', { env: prod });
const stack2 = new StackThatExpectsABucket(app, 'Stack2', {
  bucket: stack1.bucket,
  env: prod,
});

参照強度を指定していない既存プロジェクトでは、同じ環境の別スタックへの参照に対し、生成側にCloudFormationのExport、消費側に Fn::ImportValue を自動で合成します。公式はこれを「強い参照（strong）」と呼び、既定の動作です。問題は共有をやめるときに起きます。CloudFormationは使用中のExportを削除できず、消費側はExportが残っているうちに更新しないと参照を外せません。順序を誤ると次のエラーで生成側の更新が止まります。

Export Stack1:ExportsOutputFnGetAtt-****** cannot be deleted as it is in use by Stack2

従来の回避策は、exportValue() で同じ論理IDのExportを手動で残し、消費側の参照を外してから両スタックを2回デプロイする手順でした。2026年10月時点の公式ガイドも、参照の強さを制御する機能を使っていない場合の手作業としてこの手順を残しています。

Fn::GetStackOutputを使う弱い参照への切り替えとBOTHでの2段階移行

aws-cdk-lib v2.254.0（2026年5月13日）で、Exportを作らない「弱い参照（weak）」が加わりました。消費側がCloudFormationの Fn::GetStackOutput で生成側の出力を直接読むため、Exportの結び付きが無く、どちらのスタックも単独で更新・削除できます。v2.258.0（同年6月4日）からは、アプリ全体・リソース単位・参照1件単位で強さを選べます。

アプリ全体の既定は cdk.json のコンテキストで切り替えます。CLI 2.1146.1の cdk init が生成する cdk.json には、最初からこの行が入っています。キーが無い既存プロジェクトでは強い参照のままです。

{
  "context": {
    "@aws-cdk/core:defaultCrossStackReferences": "weak"
  }
}

デプロイ済みの強い参照を直接 WEAK に変えると、使用中のExportを消そうとして失敗します。移行は過渡状態の BOTH を挟んだ2回のデプロイです。BOTH では生成側がExportを残したまま出力を追加し、消費側だけが Fn::GetStackOutput に切り替わります。

import { CrossStackReferences, ReferenceStrength } from 'aws-cdk-lib';

// 1回目：Exportを残したまま、消費側をFn::GetStackOutputへ切り替えてデプロイ
CrossStackReferences.of(stack1.bucket).produce(ReferenceStrength.BOTH);

// 2回目：WEAKに変えてデプロイし、不要になったExportを外す
// CrossStackReferences.of(stack1.bucket).produce(ReferenceStrength.WEAK);

弱い参照にも代償があります。CloudFormationのリファレンスによれば、値はスタックの作成・更新時に解決され、参照先のスタックや出力が後で消えても消費側には通知されません。生成側を誤って削除しても止まらないということです。また2026年10月時点のCloudFormationには、Fn::GetStackOutput をOutputsの値に直接置く、Fn::Sub の変数マップや Fn::Base64 の中に置くといった使い方が InternalFailure になる既知の制限があります。リソースのプロパティに直接置くか、Fn::Join・Fn::If・Fn::Select で包む形なら使えます。新規の構成は弱い参照で始め、合成したテンプレートで置き場所を確かめ、共有元のスタックには terminationProtection: true を付けて守る、という組み合わせを勧めます。

1スタック500リソースの上限とNestedStackで逃がすときの制約

スタック設計に効くCloudFormationクォータと51,200バイトの壁

CDKで書いていても、合成後のテンプレートはCloudFormationのクォータを受けます（2026年10月27日確認）。

未ブートストラップの環境で最初に当たるのが51,200バイトの壁です。CDK CLIのドキュメントは、ブートストラップしていない環境では、アセットを持たず合成後のテンプレートが51,200バイト未満のスタックしかデプロイできないと書いています。cdk bootstrap を済ませればテンプレートはS3経由になり1MBまで伸びますが、500リソースの上限はそのままです。

NestedStackで回避できる範囲とcdk listに出ない制約

500を超えるときの逃げ道が NestedStack です。ネストしたスタックは親の中で1リソースと数えられ、内部にさらに500リソースまで持てます。ただし階層全体で1回のデプロイが扱えるのは2,500リソースまでです。

代わりに、ネストしたスタックは cdk list に出ず、cdk deploy で単独デプロイもできません。重いのは差分表示の制約で、デプロイ前に表示されるセキュリティ関連の変更はトップレベルのスタックの分だけです。ネスト内でIAMロールやセキュリティグループの権限が広がっても、承認の判断材料に出てきません。cdk deploy --parameters の値もネスト側には伝わりません。リソース数かテンプレートサイズが上限に迫っているときだけ使い、構成の整理が目的ならコンストラクトへの切り出しを選びます。

cdk deployでのスタック指定と承認・ロールバック・hotswapの制御

–all・ワイルドカード・–exclusivelyでの対象選択

デプロイ対象はスタックのコンストラクトIDで指定します。cdk list で名前を確かめてから渡すのが基本です（CDK CLIリファレンスのcdk deploy）。

$ cdk list
$ cdk deploy CdkHelloWorldStack CdkStack3
$ cdk deploy --all
$ cdk deploy 'PipelineStack/Prod/**'
$ cdk deploy Stack2 --exclusively

パイプラインのように階層がある場合、--all とワイルドカードの * は最上位のスタックにしかマッチしません。階層下まで含めるには ** を使います。zshなどのシェルは ** を自分で展開しようとして止まるので、パターンは引用符で囲みます。スタック名を指定すると依存先のスタックも一緒にデプロイされ、指定したものだけに絞るのが --exclusively（短縮形 -e）です。依存先の変更は反映されないので、依存先が最新でデプロイ済みだと分かっているときに限ります。並行デプロイの --concurrency は既定値が1で、数を渡さないかぎり直列です。

変更セットcdk-deploy-change-setと承認・ロールバックの既定値

既定のデプロイ方式は変更セット（--method の既定値が change-set）で、名前は既定で cdk-deploy-change-set です。--change-set-name で変えられますが、変更セットを作らず即時に適用する --method=direct とは併用できません。デプロイ時にこの名前を含むエラーが出たら、CDKが毎回この固定名を使う仕様を思い出すと切り分けが早くなります。

承認の既定値は --require-approval broadening で、権限やセキュリティグループの範囲が広がる変更のときだけ手動承認を求めます。CIで止まらないよう never にすると、セキュリティ関連の変更を無確認で通すことになります。ロールバックは既定で有効で、失敗すると直前の安定状態に戻ります。--no-rollback で失敗状態を残せますが、リソースの置き換えを伴う更新は失敗します。

–hotswapとcdk watchを開発環境に限る理由と–revert-drift

cdk deploy --hotswap は、Lambda関数のコードやStep Functionsの定義などの変更を、CloudFormationを通さずサービスのAPIで直接書き換えます。cdk watch はファイルの変更を監視して、既定でこのhotswapを繰り返すコマンドです。

公式リファレンスは、hotswapが速さと引き換えにCloudFormationのスタックへ意図的にドリフトを持ち込むと明記し、本番のデプロイには使わないよう書いています。ECSサービスの最小ヘルシー率が0になるなど、既定値が通常のデプロイと変わる項目もあります。hotswapの後で通常のデプロイに戻すときは、cdk deploy --revert-drift でドリフトを解消する変更セットを使います。開発用アカウントでは cdk watch、ステージングと本番は通常の cdk deploy、と分けることで、本番へのhotswapによるドリフトの持ち込みを避けられます。

cdk destroy時のRemovalPolicy既定値RETAINとリソース残存

cdk destroy でスタックを消してもS3バケットやDynamoDBテーブルが残るのは、CDKの RemovalPolicy の既定が RETAIN だからです。公式ガイドは、これがCloudFormationのDeletionPolicyの既定とは逆だと書いています。残ったリソースはスタックから切り離され、同じ名前で再デプロイすると名前の衝突でエラーになります。開発環境では RemovalPolicy.DESTROY を明示し、中身の入ったS3バケットには autoDeleteObjects: true も付けます。DESTROY だけでは、オブジェクトが残っているバケットをCloudFormationが削除できません。

デプロイ前にスタックを検証する：合成時の検証とassertionsのテスト

cdk validateは試験段階：–unstable=validateでの実行と合成時に走るCloudFormation Validate

CLI 2.1146.1には、合成したテンプレートをポリシールールに照らして検査する cdk validate があります。ただし試験段階の機能で、そのまま実行すると「'validate' is unstable」と表示されて止まり、cdk validate --unstable=validate と明示的にオプトインしたときだけ動きます。2026年10月27日時点で、開発者ガイドのCLIコマンド一覧にはまだ載っていません。CIの必須ゲートに据えるのは、正式な機能になるまで待つのが安全です。

正式な経路は合成の中にあります。aws-cdk-lib は cdk synth のたびに、合成したテンプレートを既定のCloudFormationルール（スキーマ検証、ベストプラクティスのリント、よくある設定ミスの検出）で検査します。何も設定していないプロジェクトでは違反は警告として表示されるだけで、フィーチャーフラグ @aws-cdk/core:validateAgainstDefaultRules を true にするとエラーになって合成が止まります。このフラグはv2.262.0（2026年7月）で入ったもので、CLI 2.1146.1の cdk init が作る cdk.json では最初から true です。古いプロジェクトでは、合成のたびに警告が流れていないかを一度確認してください。

Template.fromStackによる細粒度アサーションとスナップショットテスト

合成したテンプレートには、aws-cdk-lib/assertions でユニットテストを書けます。公式のテストの章は2種類を挙げています。「このリソースがこの値のプロパティを持つ」を確かめる細粒度アサーションと、前回保存したテンプレート全体と比べるスナップショットテストです。最初の例のスタックなら、次のテストが npm test で通ります。

// test/hello-cdk.test.ts
import * as cdk from 'aws-cdk-lib';
import { Template } from 'aws-cdk-lib/assertions';
import { HelloCdkStack } from '../lib/hello-cdk-stack';

test('バージョニング有効のバケットが1つだけ作られる', () => {
  const app = new cdk.App();
  const stack = new HelloCdkStack(app, 'TestStack');
  const template = Template.fromStack(stack);
  template.resourceCountIs('AWS::S3::Bucket', 1);
  template.hasResourceProperties('AWS::S3::Bucket', {
    VersioningConfiguration: { Status: 'Enabled' },
  });
});

公式によれば、よく使われるのは細粒度アサーションのほうです。スナップショットはリファクタリングで出力が変わっていないことの確認には向きますが、CDKを上げるだけでも合成結果が変わるため、スナップショットだけで正しさを担保するのは無理があります。権限やセキュリティに関わるプロパティは細粒度アサーションで固定します。

AWS CDK・CloudFormation・Terraform・SAMの違いと採用判断

4ツールの記述方法・対応範囲・失敗時の挙動の比較

CDKとSAMはCloudFormationの上に乗るので、ロールバックやドリフト検出をそのまま使えます。TerraformはAPIを直接呼ぶぶんAWS以外も扱えますが、適用が途中で失敗すると作成済みのリソースが残り、修正して再適用するか破棄する作業が要ります。

CDKが向く条件：AWSに閉じてTypeScriptなどで書ける構成

CDKを選んでよいのは、インフラがAWSに閉じていて、アプリと同じ言語でインフラを書けるメンバーがいるときです。この条件なら、if 文やループで環境差分を書ける利点と、L2コンストラクトが権限やログの既定値を埋めてくれる利点がそのまま効きます。CloudFormationの深い知識は最初から要りませんが、スタック・変更セット・ロールバックの意味が分かっていないとデプロイの失敗を読めません。IaCの導入そのものを検討している段階ならIaC（Infrastructure as Code）の仕組みと導入判断で費用対効果から確認できます。AWS上の構成設計からCDKやTerraformでのコード化までを外部に任せたい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）の支援で既存環境の棚卸しから相談を受けています。

CDKを見送る場面：マルチクラウド・既存Terraform資産・小規模サーバーレス

Google CloudやAzureも同じコードで管理したい、あるいは社内にTerraformのstateとモジュールが積み上がっているなら、CDKを足しても管理ツールが2系統に割れるだけです。CDKの書き味でTerraformを動かすCDK for Terraformは、2025年12月10日にHashiCorpによるサポートと保守が終了しているため、新規採用は勧めません。経緯と移行先はCDK for Terraform（CDKTF）の提供終了後の移行判断で整理しています。

Lambda関数とAPI Gatewayが中心で、チームに既存のCDK資産がなく、ローカル実行を優先するなら、まずAWS SAMを選びます。テンプレートとローカル実行の仕組みがセットになっており、CDKより学ぶ量が少なく済みます。使い方はAWS SAMのテンプレートとCLIの使い方で解説しています。より上位の部品を組み合わせるだけでよいなら、AWS BlocksとCDKの違いと採用判断も比べる対象です。この3つのどれにも当たらないときにCDKを選ぶ、と決めておけば判断がぶれません。

AWS CDKとAWS SDKの違い：合成時に動くかアプリ実行時に動くか

名前が似ていますが、CDKはデプロイ前にテンプレートを作る道具で、SDKはアプリの実行中にAWSのAPIを呼ぶライブラリです。

実際のシステムでは両方を使います。CDKでLambda関数とS3バケットを定義してデプロイし、そのLambdaのコードの中でSDKを使ってバケットへ書き込む、という分担です。SDK側はAWS SDK for JavaScript v3の使い方とS3・DynamoDBの実装例で解説しています。

AWS CDKに関するよくある質問

CDKのスタックとCloudFormationのスタックは別物ですか？

同じものです。CDKのスタックに含まれるリソースは1つのCloudFormationスタックとして展開され、マネジメントコンソールのCloudFormation画面に並ぶスタックがその実体です。テンプレート1枚あたり500リソースという上限も、CDKのスタックにそのまま効きます。

cdk bootstrapは毎回必要ですか？

いいえ。アカウントとリージョンの組ごとに最初の1回だけです。同じ環境への2回目以降のデプロイでは再実行しません。新しいリージョンを使い始めるときと、CDKの更新でブートストラップのテンプレート版が上がったときに実行し直します。

AWS CDKの利用に料金はかかりますか？

CDK自体は無料のオープンソースです。AWSは2019年7月の一般提供開始の告知で、CDKの利用に追加料金はかからず、作成したEC2インスタンスやロードバランサーなどのリソース分だけを支払うと説明しています。cdk bootstrap が作るS3バケットなども通常どおり課金対象です。

AWS CDKのバージョンはどう確認しますか？

CLIは cdk --version、ライブラリはプロジェクト内で npm ls aws-cdk-lib を実行して確かめます。package.json の ^2.273.0 のような指定は許容範囲なので、実際に入っている版とは限りません。v2のCLIとライブラリは番号の体系が別で、2026年10月27日時点の最新はCLIが2.1146.1、aws-cdk-lib が2.275.0です。プロジェクトの環境情報をまとめて見たいときは cdk doctor も使えます。

CDKとCKDは違いますか？

別物です。この記事のCDKはAWSのインフラ構築用フレームワークで、医療で使われるCKD（慢性腎臓病）とは綴りが似ているだけです。生物学で「CDK」と書く場合はサイクリン依存性キナーゼを指し、これも無関係です。

関連記事

• AWS CloudFormationとは？テンプレートの書き方・スタック操作と更新で消える設定の防ぎ方
• cdk bootstrapが作る5つのIAMロールとテンプレート版32の更新手順
• CDK for Terraform（CDKTF）とは？提供終了後の移行判断を解説
• AWS CloudFormation Expressモードとは？最大4倍高速化の仕組み・制約と本番適用の判断を実装者目線で解説
• AWS SDK for JavaScript v3とは？使い方・v2からの移行手順とS3・DynamoDB実装例