変更要約: in-scope サービス網羅: コンピュート/スケーリング/ストレージ(EC2 Auto Scaling/AWS Auto Scaling/ECS/Fargate/Lambda/S3)を追加
4.3IaC によるネットワークの自動化
コードで再現可能に——CloudFormation、CDK、Terraform、変更セット/ドリフト検出、繰り返し可能なデプロイ——を理解します。手作業のドリフトを排除します。
ネットワーク（VPC・サブネット・ルート・SG・エンドポイント・TGW）は IaC（Infrastructure as Code） で定義すると、繰り返し・一貫して・監査可能に構築できます。手作業の設定ドリフトを防ぎます。
4.3.1IaC の道具と効果
- CloudFormation：AWS ネイティブな宣言的テンプレート（YAML/JSON）。変更セットで適用前に差分を確認。
- CDK：プログラミング言語で記述し CloudFormation を生成。再利用しやすい。
- Terraform：マルチクラウド対応の IaC。state でリソースを管理する。
- ドリフト検出：実環境がテンプレートからずれていないか検出し、再現性を担保する。
「ネットワークを繰り返し・一貫して構築＝IaC（CloudFormation/CDK/Terraform）」「適用前の差分確認＝変更セット」「手作業のずれ検出＝ドリフト検出」 は ANS-C01 で頻出です。本番ネットワークは手動変更（クリックオプス）を避け、IaC で管理します。
ANS-C01 では「組織全体へ同じネットワーク構成を展開する」運用が問われます。単一アカウントなら CloudFormation スタック、複数アカウント/複数リージョンへ一括展開するなら StackSets を使い、AWS Organizations と連携すれば新規アカウント作成時に基盤ネットワーク（VPC・サブネット・ルート・エンドポイント）を自動で配備できます。共有の考え方も重要で、AWS RAM（Resource Access Manager）で Transit Gateway やサブネット、Route 53 Resolver ルールを他アカウントに共有すれば、各アカウントが個別に作らず中央で定義したネットワークを使えます。ネットワーク固有の落とし穴として、CloudFormation はリソースの依存関係（IGW のアタッチ→ルート作成の順序など）を DependsOn や参照で明示しないと作成順序の不整合で失敗することがあります。また CIDR やサブネット ID のような後から変えにくい値はパラメータや Mappings で外出しし、環境ごとに使い回せる設計にします。変更管理では、変更セットで差分を事前確認し、削除ポリシー（DeletionPolicy: Retain）で重要リソースの誤削除を防ぎ、ドリフト検出で手動変更を定期的に洗い出します。
| 道具/機能 | 役割 | 使いどころ |
|---|---|---|
| CloudFormation スタック | 単一アカウントの宣言的構築 | 1 アカウント/1 リージョンの一括管理 |
| StackSets | 複数アカウント/リージョンへ展開 | 組織全体に基盤を配備 |
| AWS RAM | TGW/サブネット/Resolver 共有 | 中央定義を各アカウントで利用 |
| 変更セット | 適用前の差分確認 | 意図しない変更を防ぐ |
| ドリフト検出 | テンプレートとのずれ検出 | 手動変更の定期洗い出し |
シナリオ：組織の全 100 アカウントに、同一の VPC・サブネット・S3 ゲートウェイエンドポイント・共有 TGW アタッチメントを一貫配備し、新規アカウントにも自動適用したい。→ CloudFormation StackSets を Organizations 連携（自動デプロイ）で構成し基盤ネットワークを全 OU に展開。共有 TGW は中央アカウントで作成し AWS RAM で各アカウントへ共有、各アカウントは自前で作らずアタッチするだけにする。
FAQ：Q. スタック更新でルート作成が「依存先がない」と失敗する? A. IGW のアタッチや TGW アタッチメントの完了を DependsOn/参照で明示し、作成順序を保証する。Q. 複数リージョンに同じ構成を入れたい? A. リージョン依存値（AZ・AMI）は Mappings やパラメータで分離し、StackSets でリージョンを指定して展開する。
ひっかけ：「ドリフト検出があれば手動変更しても自動で元に戻る」は誤り。ドリフト検出は“ずれている事実を検出”するだけで、修正はしない。是正にはテンプレートを正として再デプロイ（または変更を取り込む）必要がある。自動修復が要件なら別途パイプラインや AWS Config の修復アクションを組む。
4.3.2コンピュート・スケーリング・ストレージの in-scope サービス
ネットワークの実装では、トラフィックを処理するワークロードのコンピュートとスケーリングも範囲です。EC2 群は Amazon EC2 Auto Scaling がヘルスチェックに基づく自動置換と希望/最小/最大台数の維持・ポリシースケールを行い、EC2 以外（ECS/DynamoDB 等）も含めた横断計画は AWS Auto Scaling が統合管理します。コンテナ化したネットワークサービスは Amazon Elastic Container Service（ECS）と AWS Fargate でサーバー管理なしに実行し、イベント駆動の自動化は AWS Lambda でサーバーレスに行います（CloudWatch/EventBridge から修復を起動）。 VPC フローログやネットワーク監査ログの長期保管は Amazon S3 が低コストで高耐久、後から Athena で直接クエリできます。
4.3.3この節のまとめ
- 自動化＝CloudFormation/CDK/Terraformで再現可能に
- 安全な適用＝変更セット、整合性＝ドリフト検出
- スケール＝EC2/AWS Auto Scaling、コンテナ＝ECS/Fargate、自動化＝Lambda、ログ保管＝S3
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 同一構成の VPC ネットワークを開発・検証・本番で繰り返し・一貫して構築したい。最適な方法は？
Q2. CloudFormation でスタックを更新する前に、どのリソースがどう変わるか確認したい。何を使いますか？
Q3. IaC で構築したネットワークが、誰かの手作業でテンプレートとずれていないか確認したい。何を使いますか？