引き継いだリポジトリを開くと、YAML ではなく TypeScript や Python のファイルが並んでいて、「これを実行したら何が作られるのか」が見えない。そんな場面から始めます。コードを動かすと AWS に直接リソースが作られるのか、cdk synth や cdk deploy や cdk bootstrap は何をするのか。CDK と CloudFormation の関係が分かれば、この疑問はほぼ解けます。
この記事の結論
- AWS CDK（Cloud Development Kit）は、プログラミング言語でインフラを定義し、AWS CloudFormation 経由でプロビジョニングするオープンソースのフレームワークです。
- 構成は「Construct Library（construct の部品集）」と「CDK Toolkit（cdk コマンド）」の2つで、app → stack → construct の入れ子で書きます。
- construct には、CloudFormation リソース1つに対応する L1、既定値つきの高水準な L2、複数リソースのパターンである L3 の3段階があります。
cdk synthでテンプレートを作り、cdk deployでスタックとして更新します。デプロイ先の環境には事前にcdk bootstrapが必要です。- ループや条件分岐、テストが使える反面、生成されるテンプレートを読めないと障害時に困ります。CloudFormation の知識は不要になりません。
AWS CDK とは何か｜コードで書いて CloudFormation に変換する
AWS CDK は、インフラの設計図を TypeScript や Python などのプログラミング言語で書けるようにした仕組みです。公式の説明では、コードでインフラを定義し、それを CloudFormation でプロビジョニングするとされています。つまり CDK 自身がリソースを作るのではなく、CDK は書き方の層、実際に作るのは CloudFormation という分担です。
IaC の「宣言型」の考え方（あるべき姿を書き、差を埋めるのは道具に任せる）は、IaC とは何かで扱いました。CDK はその考え方を保ったまま、あるべき姿の書き方を YAML から普通のプログラミング言語に変えたものです。
READ ALSO — 学習中向け・段2 構成
IaC とは何か｜手作業との違いと宣言型、CloudFormation・CDK・Terraform の位置づけ
書き方が変わると、次のことができるようになります。
- 同じ形の定義を、ループで繰り返し書かずに生成できる
- 環境（開発・本番）によって値や構成を条件分岐で変えられる
- 関数やクラスに切り出して再利用できる
- コードなので、テストや型チェック、エディタの補完が使える
試験の文脈でも、「使い慣れた言語でインフラをコードとして定義し、CloudFormation テンプレートに合成してデプロイする」道具として問われるのは CDK です。CloudFormation そのものは、テンプレートを書いてスタックとして作成・更新・削除するサービスで、CDK はその上に乗る書き方の一つ、という位置づけで覚えておくと混ざりません。
CODE TO STACKコードからリソースまで
CDK は書き方の層で、作るのはCloudFormation
-
コード
TypeScript・Python など
-
cdk synth
テンプレートに合成
-
テンプレート
CloudFormation の形式
-
cdk deploy
スタックとして渡す
-
スタック
ここでリソースができる
CHECK 1ここまでの確認
CDK で書いたアプリをデプロイするとき、AWS 上にリソースを実際に作成・更新するのはどれ?
答えと解説
答え: 2. CDK が合成したテンプレートを、CloudFormation がスタックとして処理する
CDK は書き方の層で、公式も「CloudFormation 経由でプロビジョニングする」と説明しています。「AWS CDK とは何か」の章を読み直してください。
CDK は何でできているのか｜app・stack・construct と L1・L2・L3
CDK は2つの部品でできています。
| 部品 | 役割 |
|---|---|
| Construct Library | construct（インフラの部品）の集まり。コードの中で new して使う |
| CDK Toolkit | cdk コマンド。合成・差分の確認・デプロイなどを行う |
コードの構造は、入れ子の3階層で考えると読めます。
- app: 全体の入り口。1つのプログラムの単位
- stack: デプロイの単位。CloudFormation のスタックに対応する
- construct: stack の中に置く部品。S3 バケットや Lambda 関数など
stack が CloudFormation のスタックに対応することが、CDK と CloudFormation をつなぐ要点です。CDK のリポジトリで stack のクラスが2つあれば、デプロイすると CloudFormation のスタックが2つできる、と読めます。
L1・L2・L3 の違い
construct は抽象度の違いで3段階に分かれます。
| 区分 | 中身 | 自由度と手間 |
|---|---|---|
| L1 | CloudFormation リソース1つにそのまま対応する（CFN リソースとも呼ばれる） | 全項目を自分で指定する。抽象化は無い |
| L2 | L1 に既定値や便利な書き方を足した高水準の部品 | 少ない記述で書ける。細部は部品の既定に従う |
| L3 | 複数のリソースを組み合わせた、よくある構成のパターン | 一括で作れるが、中身を把握しにくい |
普段の実務で最も多く目にするのは L2 です。L2 は必要な既定値を持ち、関連する権限の設定を補ってくれる場合もあります。便利な分、書いていない設定が裏で入ることになるので、何が作られるかはテンプレートで確かめる習慣が要ります。次の章がその話です。
CONSTRUCT LEVELSconstruct の3段階
上の層ほど楽、下の層ほど自由
L1
- L1: CloudFormation リソース1つに対応
- L2: 既定値つきの高水準な部品
- L3: 複数リソースのパターン
L2
- L1: CloudFormation リソース1つに対応
- L2: 既定値つきの高水準な部品
- L3: 複数リソースのパターン
L3
- L1: CloudFormation リソース1つに対応
- L2: 既定値つきの高水準な部品
- L3: 複数リソースのパターン
自分で指定する部品が補う
CHECK 2ここまでの確認
CloudFormation のリソース1つにそのまま対応し、既定値などの抽象化を持たない construct はどれ?
答えと解説
答え: 1. L1
L1 は CFN リソースとも呼ばれ、テンプレートのリソースと1対1です。L2 は既定値つき、L3 は複数リソースのパターンです。「構成」の章を読み直してください。
コードからリソースができるまでの流れは？｜synth・diff・deploy
cdk コマンドの役割を、順番に並べます。
cdk synth: コードを実行して、CloudFormation テンプレートに合成する（synthesize）。出力はテンプレートcdk diff: 現在デプロイされている内容と、これからデプロイする内容の差を見るcdk deploy: 合成したテンプレートをスタックとしてデプロイする。実際の作成・更新は CloudFormation が行う
ここで大事なのは、コードを実行した時点ではまだ何も作られていない点です。コードは「テンプレートを生成するプログラム」で、AWS 上の変更はデプロイで初めて起きます。
synth の出力は普通のテンプレートなので、デプロイ前に目で読めます。L2 の既定値で何が補われたか、IAM の権限がどう生成されたかは、ここで確認できます。CDK のコードを読んでも見えないものが、テンプレートには全部出ています。
各コマンドの引数やバージョンごとの違いはここでは扱いません。公式の CDK ガイドで確認してください（この記事では個別コマンドのページまでは確かめていません）。
なお、CDK で書いたアプリのデプロイをパイプラインに載せる場合は、CDK Pipelines という仕組みで、パイプライン自体もコードで定義できます。詳しい話は CI/CD の記事で扱います。
READ ALSO — 学習中向け・段2 構成
CI/CD の仕組み｜コミットから本番まで、ビルド・テスト・デプロイが自動で流れて止まる理由
CHECK 3ここまでの確認
cdk synth の出力として正しいものは?
答えと解説
答え: 2. CloudFormation テンプレート
synth はコードをテンプレートに合成する段階です。デプロイ前に中身を目で確認できるのが利点です。「流れ」の章を読み直してください。
cdk bootstrap とは何か｜デプロイの前に環境へ置かれるもの
初めて CDK を使う環境では、デプロイの前に cdk bootstrap が必要です。これは、デプロイを成り立たせる土台をその環境に用意する作業です。公式の説明では、bootstrap によって次のものが作られます。
- アセット（Lambda のコードなど、テンプレートに収まらないファイル）を置く S3 バケット
- コンテナイメージを置く ECR リポジトリ
- デプロイなどに使う IAM ロール
これらは、既定では CDKToolkit という名前のスタックとして作られます。つまり bootstrap も、中身は CloudFormation のスタックです。
押さえる点は、環境ごとに必要ということです。環境とは「アカウントとリージョンの組」のことで、アカウントやリージョンが増えるたびに、その環境で bootstrap が要ります。「他のアカウントでは動くのに、新しいアカウントでデプロイが失敗する」とき、最初に疑う項目の一つです。
CHECK 4ここまでの確認
新しいアカウント・リージョンに初めて CDK でデプロイする前に、bootstrap が要るのはなぜ?
答えと解説
答え: 2. アセットの置き場や実行用の権限など、デプロイの土台を環境に用意するため
bootstrap は S3 バケット・ECR リポジトリ・IAM ロールなどを環境ごとに用意します。環境ごとに独立しているので、環境が増えればその数だけ必要です。「bootstrap」の章を読み直してください。
CDK と CloudFormation（YAML）・Terraform はどう使い分けるか
3つを並べて比べます。
| 観点 | CDK | CloudFormation（YAML） | Terraform |
|---|---|---|---|
| 書く言語 | TypeScript・Python などのプログラミング言語 | YAML または JSON のテンプレート | 専用の設定言語 |
| 実行する裏側 | CloudFormation（テンプレートに合成して渡す） | CloudFormation | Terraform 自身がプロバイダ経由で API を呼ぶ |
| 状態の持ち方 | CloudFormation のスタックが持つ | CloudFormation のスタックが持つ | Terraform の状態として別に持つ |
CDK VS CFN VS TERRAFORM書き方と裏側の違い
CDK と CloudFormation は裏側が同じ
CDK / CloudFormation
裏側は CloudFormation
- 書く言語CDK はプログラミング言語、CFN は YAML
- 状態スタックが持つ
Terraform
裏側は Terraform 自身
- 書く言語専用の設定言語
- 状態Terraform の状態として別に持つ
Terraform の中身は、IaC とは何かの範囲に留めます。ここで言えるのは次の整理です。
- CDK と CloudFormation は、裏側が同じ。違うのは書き方だけで、デプロイ後に見える姿（スタックやイベント）は同じ
- Terraform は裏側が別。AWS 以外も同じ道具で扱いたい、すでに Terraform の資産とスキルがある、といった事情で選ばれる
- どれが優れているかは断定できない。書く人のスキル、既存資産、運用の体制で決まる
注意したい点
CDK は書きやすい反面、テンプレートを読めないと困ります。デプロイが失敗したとき、エラーは CloudFormation のイベントとして出ます。リソースの論理 ID も CDK が自動で付けたもので、コードの変数名とは違います。また、手作業でコンソールから変更された場合のドリフトも、CloudFormation の機能で検出します。CDK を使っても、CloudFormation の知識は不要になりません。
READ ALSO — プロフェッショナル向け・段4 設計
AWS CloudFormation とは何か｜変更セット・ドリフト・StackSets で基盤をコードで持つ設計の入口
実務で CDK のリポジトリを渡されたら最初に見る場所
最初の1時間でやることを、順に並べます。動かす前に読むのが基本です。
- app の入り口を探す: どの stack をいくつ作っているか。stack の数がデプロイされるスタックの数になる
- 対象の環境を確認する: どのアカウント・リージョンに向けているか。bootstrap 済みかどうかもここで分かる
cdk synthでテンプレートを出す: コードではなく、出力されたテンプレートでリソースの一覧と IAM の権限を確認するcdk diffで差を見る: 今デプロイされているものと、自分の変更の差を見てからデプロイする- どの construct が L1・L2・L3 かを見る: L2・L3 は書いていない設定が入るので、裏のテンプレートと突き合わせる
この順番は、「コードを実行する前に、何が起きるかをテンプレートで確かめる」という考え方にそろえてあります。
Cloudory 執筆者（AWS 認定 全冠）
CDK は便利ですが、CDK を使っていることが「CloudFormation を知らなくてよい」理由にはなりません。この記事は公式ドキュメントを根拠にまとめたもので、CDK を本番で運用した経験として書いたものではありません。次に読む CloudFormation の記事とセットで、テンプレートを読む力をつけてください。
まとめ
- CDK はプログラミング言語でインフラを書く層で、実際の作成は CloudFormation が行う。stack が CloudFormation のスタックに対応する
- construct は L1（1対1）・L2（既定値つき）・L3（パターン）の3段階。L2 以上は書いていない設定が入る
cdk synthでテンプレートを作り、cdk diffで差を見て、cdk deployでスタックとして更新する- 新しい環境（アカウントとリージョンの組）には、デプロイの前に
cdk bootstrapが要る - テンプレートが読めれば、CDK は強い道具になる。次は CloudFormation を読む
参照ソース
- AWS CDK 開発者ガイド（What is the AWS CDK?） — CDK の定義（プログラミング言語で定義し CloudFormation でプロビジョニング）、Construct Library と CDK Toolkit の2部構成の根拠
- AWS CDK の Constructs — construct の L1・L2・L3 の区分の根拠
- AWS CDK の Bootstrapping — bootstrap で S3 バケット・ECR リポジトリ・IAM ロールが作られること、環境ごとに必要なこと、既定のスタック名 CDKToolkit の根拠
