週7CloudWatch / CloudFormation
2026-09-12（土）CloudWatch, CloudFormation
1. 【このハンズオンで使うAWSサービスと役割】
| サービス | 役割 |
|---|---|
| Amazon EC2 | 監視対象となる仮想サーバー。今回はこのインスタンスにかかるCPU負荷を監視のトリガーとします [p.21]。 |
| Amazon CloudWatch (監視のコア) | EC2がハイパーバイザー経由で自動送信する標準メトリクス（CPU使用率）を収集・モニタリングし、設定したしきい値を超えた際に「アラーム（Alarm）」状態へと遷移させる監視司令塔です [p.22, 245]。 |
| Amazon SNS (Simple Notification Service - 通知の仲介) | CloudWatchアラームと連携するプッシュ型メッセージ配信サービス [p.22, p.227-228]。アラーム発生のシグナルを受け取り、あらかじめ登録された配信先（管理者のメールアドレスなど）へメッセージを一斉送信（パブリッシュ）する役割を担います [p.228]。 |
2. 【操作前に知っておくべき設定項目】
- 監視メトリクス名（CPUUtilization）: EC2が標準でCloudWatchに送信しているCPU使用率のデータ項目名です。
- 統計方法と期間（評価基準）: メトリクスを評価する単位です。一般的には「平均（Average）」を選択し、期間は「5分」（標準モニタリング）または「1分」（詳細モニタリング）を設定します。
- アラームのしきい値（Threshold）: アラームをトリガーする境界条件です（例：CPU使用率が「80%以上」の状態が「1回（5分間）」継続した場合、など）。
- SNSトピックとARN: 通知先を論理的に束ねる共通の「グループ名（トピック）」を作成し、生成される一意の識別子（ARN：Amazon Resource Name）をCloudWatchアラームの通知アクションにマッピングします [p.228]。
- サブスクリプション（配信先登録）: 作成したSNSトピックに対して、どのようなプロトコルで誰に届けるかを設定します。今回のハンズオンでは、プロトコルに「Email」、エンドポイントに「受信したいメールアドレス」を指定します [p.228]。
3. 【よくある詰まりポイント・注意点】
- ⚠️ 詰まりどころ：確認メールの承認（Confirm Subscription）漏れ
- SNSでメールアドレスを登録（サブスクリプション作成）した直後は、ステータスが「Pending Confirmation（確認待ち）」の保留状態になります [p.228]。指定したアドレス宛てにAWSから自動送信される承認メール内の「Confirm subscription」リンクを必ずクリックしてください。ステータスが「Confirmed（確認済み）」に変わらない限り、アラームが発生してもメールは1通も届きません [p.228]。
- ⚠️ 注意点：標準モニタリングによる「5分間」のタイムラグ
- EC2の標準モニタリングはデフォルトで「5分間隔」でデータをCloudWatchに送信します。そのため、EC2に高負荷をかけてしきい値を超えさせたとしても、CloudWatch側がそれを検知してアラーム状態に切り替わりメールを送信するまでに最大5分程度のタイムラグが発生します。ハンズオン中に「設定したのにメールがすぐに来ない」と焦る必要はありません。
4. 【このハンズオンが対応する試験論点】
- 標準メトリクス（外側）とカスタムメトリクス（内側）の境界線
- 今回の「CPU使用率（CPUUtilization）」は、ハイパーバイザー層（仮想マシンの外側）から自動収集できる標準メトリクスであるため、EC2に特別な設定をせずとも最初から監視可能です。
- 試験では、「OS内部の情報（メモリ使用率：MemoryUtilization やディスク空き容量、内部ログ）」を監視したい場合は、標準機能では取得できず、ゲストOS内に「CloudWatch Agent（エージェント）」をインストールしてカスタムメトリクスとして送信しなければならないという境界線が、極めて高い確率で出題されます。この挙動の違いを頭に叩き込んでおきましょう。
- 「疎結合（Decoupling）」による高可用アーキテクチャの体現 [p.22, p.227-228]
- CloudWatchが直接特定のメールアドレスに向けてメールを送信するのではなく、間に「SNS（トピック）」という仲介サービスを挟んでいます [p.22, p.227-228]。
- このようにシステム同士を直接依存させず、メッセージングサービスを挟んでつなぐアプローチを疎結合設計と呼びます [p.22, p.227]。これにより、将来的に「通知先メールアドレスを増やす」「通知と同時にSlackに飛ばす」「Lambda関数を起動してEC2を自動停止させる」といった拡張を行う際も、CloudWatch側のアラーム設定を変更することなく、SNSトピック側の設定（サブスクリプション）を増やすだけで簡単かつ高可用に対応できる、AWSのベストプラクティス（セルフヒーリング設計）の基本思想を実感してください [p.228, 245]。
🏁 5分前の前提知識チェックは完璧です！
実機で「CloudWatch」と「SNS」がどう連携し、どのようにメール通知がトリガーされるのか、データの流れを意識しながらハンズオンを大成功させてきてくださいね。いってらっしゃいませ！