目次

• はじめに

システム構築でCDKが使われるようになるまで

システム開発の変遷とIaCの必要性

• オンプレミスなどの物理サーバーを調達する時代
• マネジメントコンソールによる迅速なインフラ構築
• マネジメントコンソールの限界
• インフラのコード化（Infrastructure as Code）
• コンサルティング現場でのIaCの定着

IaC導入で陥りがちな失敗パターン

• コードの複雑化による失敗
• 運用プロセスの失敗
• 組織・チームの失敗
• 品質・セキュリティの失敗
• 本書が目指すIaCの姿

IaCがもたらす価値とビジネス効果

• IaCの4つの価値
• チーム開発とドキュメントとしての機能
• ビジネスが求めるスピードへの対応
• IaC化の成功事例
• IaCを採用すべき場面

なぜAWS CDKを選ぶのか

• CDKを選ぶ理由
• 本書で学べる技術
• Pythonを選んだ理由

生成AI時代のAWSエンジニア

• AIがコードを生成できる時代に学ぶ意義
• 個別最適から全体最適へ
• IaCの間違いの影響の大きさ
• 役割のシフト

IaCを効率的に作成するためのアーキテクチャ理解

• なぜアーキテクチャを理解する必要があるのか
• 単一のWebサービスを新規に提供する場合
• 既存業務システムを段階的にAWSへ移行する場合
• 複数コンポーネントの大規模サービスを新規構築する場合
• サーバーレスAPIの構成

まとめ

AWS CDKの概要と比較

AWS CDKの概要と特徴

• CDKの特徴
• AWS CDKのメリットとデメリット

主要IaCツールとの比較

• CloudFormationの概要
• CloudFormation vs CDK
• Terraformの概要
• Terraform vs CDK
• 選択の指針

AWS CDKによるデプロイの流れ

• 訪問者カウンターAPIの全体像
• 前提条件
• CDKプロジェクトの初期化
• 最初のStackを作成する
• Synthesis（合成）によるCloudFormationテンプレート生成
• デプロイ
• AWSリソースの確認
• Lambda関数の追加と差分確認
• API Gatewayの追加と動作確認

AWS CDKの基本的な構造

• App、Stack、Constructの関係
• 統計取得用Lambda関数の追加
• プロジェクト構造の整理とConstruct
• ConstructをStackへ組み込む
• Appで新旧Stackを並行して定義する
• 新構成の検証と切り替え

CDK Constructのレイヤー

• L1 Construct：CloudFormationの直接マッピング
• L3 Construct：パターンとベストプラクティス
• L2 Construct：便利機能付きの高レベルAPI (推奨)
• レイヤー選択の判断フロー

AWS CDKのStack管理と運用

• なぜStackを分割するのか
• Stack間で値を受け渡す必要性
• Fn::ImportValueとExportによる値の受け渡し
• クロスStack参照による直接参照
• 環境変数とSSMパラメータを活用した疎結合
• 実践的な使い分け指針

CDK CLIコマンドの理解

• cdk diffの詳細動作
• cdk deployの実行プロセス
• cdk driftによる運用時監視
• 実践的なCLIコマンドの組み合わせ
• よく使用するオプション
• cdk watchによる継続的なデプロイ

CDK Bootstrap

• Bootstrapの必要性と役割
• 基本的なBootstrap手順
• Bootstrapによる環境の管理
• カスタムBootstrap
• 実際の運用での考慮事項
• トラブルシューティング
• Bootstrap管理のベストプラクティス

エスケープハッチ

• エスケープハッチの概念と必要性
• 訪問者カウンターアプリでのエスケープハッチ活用
• エスケープハッチの実装パターン
• エスケープハッチ使用時の注意点

カスタムリソースの有効活用

• カスタムリソースの基本概念
• 実践的な活用例：DynamoDBバックアップカスタムリソース
• カスタムリソース使用時のベストプラクティス

ハンズオンで作成したリソースの削除

開発者環境の整備

シフトレフトアプローチと開発環境整備

開発環境の選択

• 環境選択の決定要因
• オンボーディング手順の整備

AIコーディングアシスタントの活用

• 入力するコードの扱い
• CDK開発での活用例

この章で導入するツール一覧

Gitによるバージョン管理

• Gitホスティングサービスの選択
• 推奨設定
• CODEOWNERSファイルの活用
• セキュリティ設定

Python仮想環境の管理

• venv
• Poetry
• 依存関係の固定
• セマンティックバージョニングの理解

コード品質管理ツールの導入

• ツールのインストールと確認
• 各ツールの実行例
• 設定ファイル
• ツールの統合実行

VS Code設定の統一

cdk-nagによるセキュリティチェック

• インストールと基本設定
• チェックの実行と結果
• 利用可能なルールパック
• CI/CDパイプラインでの実行

.gitignoreの設定

Pre-commitフックの設定

自動チェックの実行タイミングの整理

開発環境の動作確認

異なる設定の開発環境を受け取る

• 設定の違いを確認する
• リポジトリのクローン
• 仮想環境の作成とセットアップ
• 設定の違いを体感する
• 動作確認
• 複数プロジェクト間の切り替え
• 開発環境のクリーンアップ
• トラブルシューティング

オプション：CloudFormation Guardによるポリシーチェック

• ルール定義
• CDKとの統合

まとめ

システムの構造化

この章の読み進め方

システムの構造化とは

• 構造化の定義と重要性

分割の基本方針

• リポジトリによる分割
• ディレクトリによる分割
• Construct分割
• Stack分割
• 基本的な分割例
• 依存関係がある場合の分割
• チーム責務による分割

Construct分割戦略

Stack分割の判断基準

• 組織構造による分割
• ライフサイクルによる分割
• クォータによる分割

Constructライブラリの設計

• 階層化された設計
• ライブラリ開発のベストプラクティス
• 別リポジトリでのモジュール管理パターン

Stack設計パターン

• 基盤・アプリケーション分離パターン
• 環境別設計パターン

分割のアンチパターン

• Stackの分けすぎ
• 循環参照
• コメントアウトしないとデプロイできないリソース

循環参照の発生と対策

• 循環参照が発生する典型例
• 対策1：依存関係の整理
• 対策2：参照の弱化

手動操作とCDK管理の混在問題

• 問題のあるパターン
• 推奨する解決策
• cdk importによる既存リソースの取り込み

共通化の判断基準と原則

• 共通化すべきもの
• 共通化すべきでないもの

CDKによるリリース戦略

システムのリリースとは

• リリースの定義と重要性
• リリースとデプロイの違い

マネジメントコンソール操作によるリリース方法とその課題

• 手動操作の問題点
• 可視性の欠如
• スケーラビリティ制限

マルチ環境、マルチアカウントの設計原則

• 各環境の役割と責務
• 開発者用環境（サンドボックス）
• アカウント分割戦略
• 同一アカウント内でのマルチ環境運用

ブランチ戦略と環境変数の管理

• ブランチ戦略の設計
• 環境変数と設定値の管理
• 環境ごとの設定値の変更方法

CDKでリリースすべきでないもの

• 機密情報の管理
• 動的に変化するリソース属性
• アプリケーションコードとコンテナイメージ
• 外部管理されるリソース

CDKによるリリースパターン

• 基本的なリリースフロー
• 段階的にリリースする方式
• 環境別のデプロイコマンド
• cdk diffによる変更確認
• 安全なデプロイのためのチェックリスト
• ロールバック戦略
• よくある失敗パターンと対策

CI/CDパイプラインによる自動リリース

• 手動デプロイからCI/CDへの移行
• GitホスティングサービスとCI/CDツールの選択
• GitHub Actionsによる基本的なパイプライン
• 定期的なドリフト検出
• 環境別のパイプライン設計
• 承認フローの実装
• cdk diffの自動実行
• テストの自動実行
• デプロイ後の自動検証
• ロールバックの自動化
• マルチアカウントデプロイの自動化
• デプロイ履歴と監査証跡
• よくある失敗パターンと対策（CI/CD編）

• おわりに
• 著者プロフィール
• 索引