AWS CDK実践ガイド─クラウドインフラをコードで構造化する

- はじめに
- システム構築で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編）
- おわりに
- 著者プロフィール
- 索引