目次
- AWS CDKとは？LightsailからEC2 + RDSに移行して気づいた「早く知りたかった」話
- 1. これまでの構成
- 2. CDKを導入するとどう変わる？
- 3. 疑問点
- 4. 「CDKで全部管理する」こと自体は悪じゃない
- 5. まとめ
- 6. 参考リンク
AWS CDKとは？LightsailからEC2 + RDSに移行して気づいた「早く知りたかった」話
友人たちと進めていたプロジェクトで、Lightsail + MySQLからEC2 + RDS for MySQLに移行しました。
初めてのサーバー構築・DB設定に悪戦苦闘し、「VPCやサブネットってなんでこんなにややこしいんだ…」と痛感。
そんな中で出会ったのが AWS CDK（Cloud Development Kit）。
調べてみると、もしこれを最初から使っていたら構築がかなり楽になっていたかもしれない……。
この記事では、CDKの概要・メリット・デメリット・SAMとの違いを整理してまとめます。
1. これまでの構成
これまで自分たちは、以下のようなフローで作業を行っていた。
- AWS lambda ➡ AWS SAM にてdeploy(sam build && sam deploy)
- EC2 ➡ GitHub actionにてCL/CDを導入 (vscodeにてpush ➡ github action ➡ ec2といった流れ)
メリット
- 責任の所在が明確
- プロジェクトフォルダが見やすい
デメリット
- まとめて管理できないため、GUIによる操作が必要
- また、GUIによる操作のため人為的なミスの危険性あり（セキュリティグループ）
- 確認する場所がバラバラなので時間を要するし、大変
2. CDKを導入するとどう変わる？
これまで行っていたGUIでの操作をPythonやTypeScriptで可能に！！SAMの方ではテンプレートに沿って記述していたものをこうしたプログラミング言語で書くことによって、より柔軟に設定可能に！
さらに、クラスなどを用いることでより簡潔に見やすく管理できるようになる
また、SAMではLambdaしか管理出来なかったが、CDKではLambdaだけではなく、AWSほぼ全ての機能をプログラミング言語で管理可能
そのため、難しいセキュリティ系の設定もまとめて可能に✨
メリット
| 観点 | 内容 |
|---|---|
| 1. インフラをプログラムで定義できる（Infrastructure as Code） | TypeScript, Python, Java, C#, Go などで記述でき、条件分岐・ループ・再利用が容易。CloudFormationのYAMLよりも圧倒的に柔軟。 |
| 2. CloudFormationを自動生成・管理 | CDKは最終的にCloudFormationテンプレートを生成・デプロイするため、安定性と再現性を両立。 |
| 3. 高レベル抽象化（L2/L3 Constructs） | 例：new s3.Bucket() だけで暗号化・バージョニング・削除ポリシー設定まで一括生成可能。公式Constructs＋コミュニティ製Constructs（Construct Hub）も豊富。 |
| 4. スタックの依存関係を自動管理 | RDS → Lambda → API Gateway → Route53 のようなリソース間の依存を自動で解決し、正しい順序でデプロイ。 |
| 5. マルチアカウント・マルチリージョン対応 |
cdk.App() で複数の環境を一括管理可能。開発・ステージング・本番を同一コードで構築できる。 |
| 6. 差分デプロイが可能 |
cdk diff コマンドで変更点を確認、cdk deploy で差分のみ反映できる。 |
| 7. CI/CDとの統合が容易 | GitHub ActionsやCodePipelineと組み合わせて自動デプロイできる。 |
| 8. 既存のCloudFormationテンプレートを統合可能 |
CfnInclude で従来のテンプレートを取り込める。 |
| 9. コスト削減・安全性向上 | リソースの自動削除ポリシーや環境変数の安全管理（Secrets Manager連携など）をコードで定義できる。 |
デメリット
| 観点 | 内容 |
|---|---|
| 1. CloudFormationの制約を受ける | CDKは内部的にCloudFormationを利用するため、CloudFormation未対応の最新サービスはデプロイ不可。 |
| 2. デバッグが難しい | 生成されたCloudFormationテンプレートが巨大になり、スタックエラーの原因を追いにくい。 |
| 3. CDKバージョン依存が強い | v1 → v2 移行のように、Constructsの互換性が崩れるケースがあり、アップデート時にコード修正が必要。 |
| 4. 環境差分の扱いが難しい | 開発・本番の設定値を条件分岐で切り替えるため、コードが肥大化しやすい。 |
| 5. Pythonなど一部言語では型補完が弱い | TypeScript版が最も強力で、他言語だと型推論やドキュメント参照がやや不便。 |
| 6. CloudFormationスタック削除時のリスク | 誤ってcdk destroyを実行すると、全リソース（RDSなど）も削除されるため、慎重な管理が必要。 |
| 7. Terraformとの互換性がない | マルチクラウド対応が不要なら問題ないが、AWS専用設計なので他クラウドでは使えない。 |
他のツールとの比較
| ツール | 主な特徴 | 向いているケース |
|---|---|---|
| AWS CDK | AWS公式・プログラミング言語でIaC記述 | AWS中心の開発チーム、コード重視派 |
| AWS SAM | Lambda中心のサーバーレス特化IaC | Lambda/API Gateway主体の構成 |
| Terraform | マルチクラウド対応・宣言的記述 | AWS以外も使う環境、インフラ専任チーム |
| Pulumi | CDKに近いがマルチクラウド | 複数クラウド + コード派向け |
3. 疑問点
Q1, 責任の分散は？ひとつに処理をまとめると危なくない？
➡ 結論、そのままでは危ない！
CDKが「危なく見える」理由
- CDKはCloudFormationを生成するので、1リポジトリで複数サービス・複数リソースを一括デプロイできる。
- しかもcdk deploy --allとかすると広い範囲に変更が飛ぶ可能性がある。
- だから「1ファイルの変更がS3にもVPCにもLambdaにも効いてしまうのでは？」という不安が出る。
これは正しくて、設計しないで1スタックに全部詰めると被害範囲がデカくなるから危ない。
つまり正しく設定をすれば、安全な運用が可能に
Q2, じゃあどうやって“危なくない形”にするの？
ここがポイント。
(1) スタックを分ける
- ネットワーク(VPC, Subnet, SG)用スタック
- アプリ(ECS/Lambda/API Gateway)用スタック
- バッチ/分析用スタック
このように論理ごとにスタックを分ける。
→ これで 「アプリだけデプロイ」「ネットワークには触らない」 ができる。
→ CDKは スタック間参照 できるから分けても平気。
(2) アカウント/環境を分ける
- devアカウント
- stagingアカウント
- prodアカウント
に分けて、prodにデプロイできる人・パイプラインを絞る。
→ まとめて管理していても、prodを壊すハードルを上げられる。
(3) デプロイコマンドを雑に打たせない
- cdk deploy --allを人間が手で打つ運用にしない
- GitHub Actions / CodePipelineから特定スタックだけデプロイ
- cdk diffをCIで必ず出して、変更多すぎると失敗にする
→ 「知らないうちに関係ないところが変わった」を減らす
(4) IAMで“誰がどこまでできるか”を制限
CDKを使うIAMロール自体を
- このアカウントだけ
- このCloudFormationスタックだけ
に限定する。
→ CDK使える人＝全部壊せる人にしない。
Q3, SAM と CDKの使い分けは？
どちらも「IaC（Infrastructure as Code）」ですが、目的と得意分野が違います。
| 比較項目 | AWS SAM | AWS CDK |
|---|---|---|
| 主な目的 | サーバーレス（Lambda中心）を簡単に構築 | AWS全体のインフラを柔軟にコードで構築 |
| 得意分野 | Lambda, API Gateway, DynamoDB などサーバーレス系 | VPC, EC2, RDS, S3, ECS, Lambda など全AWSサービス |
| 記述形式 | YAML（テンプレートベース） | TypeScript / Python / Java / C# / Go などプログラミング言語 |
| 抽象度 | 低〜中（明示的に設定を書く） | 高（クラス化・再利用・条件分岐が可能） |
| CloudFormationとの関係 | 直接テンプレートを書く | CloudFormationテンプレートを自動生成 |
| 導入の容易さ | シンプル、すぐに使える | 初期セットアップにやや学習コストあり |
| 構成の再利用性 | 少ない（コピペ中心） | 高い（Constructでモジュール化可能） |
| 変更の追跡性 | 手動管理が多い |
cdk diffで自動差分確認 |
| CI/CD統合 | CodeDeploy / GitHub Actions対応 | 同様に対応、より柔軟 |
| 開発体験 | AWS初心者・サーバーレス特化 | AWS全体設計・チーム開発に強い |
| 向いている規模 | 小〜中規模のLambda中心アプリ | 中〜大規模のインフラ全体を含むプロジェクト |
つまり、プロジェクト、目的によって使い分けること が大切
| あなたの目的 | 選ぶべきツール |
|---|---|
| 「LambdaとAPI Gatewayだけで完結したアプリを作りたい」 | ✅ SAM |
| 「EC2・RDS・S3など、全体の構成をコードで管理したい」 | ✅ CDK |
| 「サーバーレスとEC2を両方使いたい」 | ✅ CDK（またはCDK + SAMのハイブリッド） |
4. 「CDKで全部管理する」こと自体は悪じゃない
むしろ
-
どの設定がどこにあるかがコードで見える
-
再現性がある
-
差分がレビューできる
こういったメリットからコンソールでバラバラにいじるより責任の所在ははっきりすることが多い！
危なくなるのは 「とりあえず1スタックに全部突っ込んで、みんながローカルからcdk deployしてる」 みたいな運用の時。これはCDKが危ないんじゃなくて、運用と分割の設計が足りないだけ。
5. まとめ
AWS CDKは、AWSリソースをコードで一元管理できる最強のIaCツール。
Lambdaだけを管理するSAMを超え、VPC・RDS・EC2・S3など、AWSほぼ全サービスをプログラムで構築・更新・削除できる。
適切な設計（分割・権限制御・CI/CD連携） さえ行えば、
GUI運用よりも再現性・安全性・チーム開発効率すべてを向上できる。
「これからAWSを本格的に触る人」や
「既存インフラをコード化したいチーム」に、CDKは強くおすすめです。
6. 参考リンク
補足
この記事は、Lightsail → EC2 + RDS 移行を通じて学んだ実体験をもとにまとめています。
もし同じように「GUI構築から脱却してIaC化したい」と考えている方の参考になれば嬉しいです。