週7CloudWatch / CloudFormation

2026-09-13（日）CloudWatch, CloudFormation

この記事の目次
  1. 予習ポイント
  2. 図解イメージ（言葉で説明）
  3. 視聴後に自分でチェックしたい項目

1. 【予習ポイント】

  • CloudWatchの物理監視境界（「外側」と「内側」の違い）
    • 物理ホスト（ハイパーバイザー層）から直接見える「CPU使用率」や「ネットワークI/O」は標準メトリクスとして自動収集されますが、ゲストOSのプライベート内部領域（メモリ使用率、ディスク空き容量、システム生ログなど）を監視するには、EC2の中に「CloudWatch Agent（エージェント）」を明示的にインストールしてデータを外部送信（カスタムメトリクス化）させる必要がある点に注目してください。
  • CloudFormationによる安全なインフラ運用ライフサイクルとデータ保護
    • コード（IaC）でインフラを管理する際、不要になったスタック（環境全体）を削除すると、標準仕様ではRDSデータベースなどの永続データもろとも自動で物理消去されてしまいます。これを防ぐ DeletionPolicy（Retain：リソースを削除せず残す、または Snapshot：削除直前にバックアップを作る） の指定方法と、適用前にリソースの再作成（Replacementに伴う一時的な物理削除・データ消失）などのリスクを事前にプレビュー確認できる Change Sets（変更セット） の役割が試験に直結します。
  • 「パフォーマンス監視」「API監査」「構成・コンプライアンス適合監査」3大サービスの機能境界
    • パフォーマンス（生ログ）：システム負荷やアプリケーションのエラーを追跡する CloudWatch。
    • 行動履歴（責任追跡）：AWSアカウント内で「誰が、いつ、どこから、どのような操作（API）を行ったか」をレコーディングする CloudTrail。
    • 構成状況（自動是正）：セキュリティグループ等の設定状況を時系列で記録し、あらかじめ規定した安全ルールに適合しているかを自動評価・自動修復する AWS Config。
    • この3つは、問題文の「何を実現したいか」というシグナルキーワードと、正しい選択肢へのマッピングが完全に決定されるため、機能境界の明確な理解が不可欠です。

2. 【図解イメージ（言葉で説明）】

「学校の身体測定と、安全対策付きの3Dプリンター工作」

CloudWatchとCloudFormation、そして他のガバナンスサービスの連携モデルを、身近な例えでイメージ化します。

【CloudWatch（身体測定と病院アラート）】
・「標準メトリクス」➡ 外側から測定する（身長・体重＝CPUや物理I/O）
・「CloudWatch Agent」➡ 内視鏡カメラを飲み込ませて、体内を精密検査（メモリ使用率・内臓疾患ログ）
　　↓ しきい値を超えると…
・「SNSトピック（アラート）」➡ ナースコールが鳴り、救急搬送や自動治療（Auto Scaling等）をキック！

【CloudFormation（3Dプリンター工作）】
・「テンプレート」➡ プラモデルの精密な設計図
・「スタック」➡ プリンターで一撃で立体成形された、VPC・EC2・データベースの実体
・「DeletionPolicy: Retain」➡ プラモデル全体を片付ける（スタック削除）際、大事なSDカード（データ実体）だけを物理的に手元に安全に残す設定
  1. CloudWatchは「健康診断（とナースコール）」: 外側から測定器を当てるだけでわかる「身長（CPUUtilization）や血圧」は、何もしなくても自動で回収（標準メトリクス）されます。しかし、体内の詳細な「胃の様子（メモリ使用率やアプリケーション内の詳細ログ）」を暴くには、お腹の中に内視鏡エージェント（CloudWatch Agent）をゴクンと飲み込ませる（インストールする）必要があります。測定値がしきい値を超えると、病院のナースコール（SNSアラーム）が鳴り響き、同時に自動で心肺蘇生やベッド増設（EC2自動復旧やAuto Scalingによる追加スケール）が走る、自律管理トポロジーとなっています。
  2. CloudFormationは「全自動3Dプリンターと保護ロック」: インフラ構成図が描かれた1枚の紙（テンプレートファイル）を3Dプリンターに読み込ませると、VPC、EC2、セキュリティグループなどの街全体（スタック）が一瞬で正確に自動モデリングされます。 このモデリングされた街を、不注意でゴミ箱に丸ごと投げ捨ててしまった（スタックの削除を実行した）とき、本番の重要データが詰まった「金庫のデータ（RDSの実体やS3）」まで道連れでゴミ箱に落とされて完全粉砕されては困ります。そこで、「この金庫パーツだけは、片付け時にも手元（AWS上）に絶対に物理的に残しておくこと！」とプリンターに厳しく制限指令を定義しておくセーフティロックが、DeletionPolicy: Retain（リソースの残存保持設定） です。

3. 【視聴後に自分でチェックしたい項目】

  • ⬜︎ チェック1: EC2インスタンスの「メモリ使用率（MemoryUtilization）」をCloudWatchで監視したい場合、なぜ標準メトリクスでは不足しており、OS内にエージェントを入れる必要があるのか、その「責任共有モデル」と「ハイパーバイザー」の視点から物理仕様の根拠を説明できるか？
  • ⬜︎ チェック2: CloudFormationで定義したRDSデータベースに対して、スタック削除時にもデータ実体を物理的に残すための DeletionPolicy: Retain を設定していなかった場合、どのような事故が起きるか？また、それを回避するための設定記述の必然性を説明できるか？
  • ⬜︎ チェック3: 「セキュリティグループの設定変更を誰が行ったか（監査証跡）」「変更された設定履歴を時系列で追跡し、元の安全な状態に自動で戻す（構成是正）」「システム負荷によるアラートと自動スケールアウト（パフォーマンス監視）」の3要件に対して、CloudWatch / CloudTrail / AWS Configをどうマッピングするか、即座に境界線を説明できるか？

📊 予習要点の整理が完了しました！

システム運用の最適化と自動復旧（セルフヒーリング）のアーキテクチャ設計を司るこの第12章は、SAA-C03試験においても非常に高い配点比率（「可用性の高いアーキテクチャの設計：26%」「運用の優秀性を備えたアーキテクチャの設計」）を誇る超頻出領域です。