AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

1. サービス概要

Amazon CloudWatch は、AWSリソース・アプリケーション・オンプレミス環境を対象とした、フルマネージドのモニタリング/オブザーバビリティサービスです。 メトリクス（数値の時系列データ）、ログ（CloudWatch Logs）、イベント（EventBridge）の3本柱でシステムの状態を可視化・分析し、しきい値超過時のアラームや自動アクションを実現します。

CloudWatchはリージョン単位のサービスであり、メトリクスやログはリージョンごとに保持されます。多くのAWSサービスは追加設定なしで基本メトリクスを自動送信し、アプリ独自の指標はカスタムメトリクスとして送信できます。

主なユースケースは、インフラ/アプリのパフォーマンス監視、ログ集約と検索、異常検知、Auto Scalingのトリガー、運用の自動化（EventBridge連携）、エンドユーザー体験の計測（Synthetics/RUM）などです。

2. 主な特徴と機能

2.1 メトリクス（名前空間・ディメンション・解像度）

• 名前空間（Namespace）: メトリクスのコンテナ（例: AWS/EC2）。AWS提供はAWS/で始まる。
• ディメンション（Dimension）: メトリクスを識別する名前/値のペア（例: InstanceId）。最大30個まで。
• 標準解像度: 1分粒度。高解像度（High-Resolution）: カスタムメトリクスで1秒粒度まで指定可能。
• EC2の標準モニタリングは5分間隔（無料）、詳細モニタリング（有料）は1分間隔。
• メモリ・ディスク使用量はゲストOS内部の値のためハイパーバイザーからは取得できず、CloudWatch Agentが必要。

2.2 カスタムメトリクス

PutMetricData APIでアプリ独自の指標を送信できます。複数データポイントを集約して送る「統計セット（StatisticSet）」でAPIコールを削減できます。

2.3 アラーム

• 状態: OK / ALARM / INSUFFICIENT_DATA。
• メトリクスアラーム: 単一メトリクスのしきい値監視。複合アラーム（Composite）: 複数アラームをAND/ORで組み合わせ、通知ノイズを抑制。
• 異常検出（Anomaly Detection）: 機械学習でメトリクスの正常帯（バンド）を学習し、逸脱を検知。
• アクション: SNS通知、EC2アクション（停止/終了/再起動/復旧）、Auto Scalingポリシー、Systems Manager等を起動。

2.4 CloudWatch Logs

• ロググループ / ログストリーム: ロググループ単位で保持期間（1日〜10年/無期限）と暗号化を設定。
• メトリクスフィルター: ログのパターン一致回数などをメトリクス化し、アラーム化できる（例: ERROR件数）。
• サブスクリプションフィルター: ログをほぼリアルタイムでLambda、Kinesis Data Streams/Firehose、OpenSearchへ配信。
• Logs Insights: 専用クエリ言語でログを高速検索・集計。
• 送信元: CloudWatch Agent、Lambda、VPCフローログ、Route 53、API Gatewayなど。

2.5 CloudWatch Agent / 統合CloudWatch Agent

EC2/オンプレミスにインストールし、メモリ・ディスク・プロセス等のOSレベルメトリクスとログの両方を収集します（旧来のCloudWatch Logs Agentの後継）。

2.6 EventBridge（旧 CloudWatch Events）

AWSサービスの状態変化やAPI呼び出しをイベントとして捕捉し、ルールでLambda/SNS/SQS/Step Functions等へ配信します。スケジュール実行（cron/rate）も可能で、サーバーレスな運用自動化の中核です。

2.7 ダッシュボードと拡張オブザーバビリティ

• ダッシュボード: メトリクス/ログを可視化。クロスリージョン/クロスアカウント表示に対応。
• Container Insights / Lambda Insights: ECS/EKS/Lambdaの詳細なパフォーマンス指標を収集。
• Synthetics（Canary）: 定期的に擬似トラフィックを送り、エンドポイントの可用性/レイテンシーを外形監視。
• RUM: 実ユーザーのブラウザ操作（ページ表示性能/エラー）を計測。

3. アーキテクチャおよび技術要素

1. 各AWSサービスが標準メトリクスを自動送信し、アプリ/Agentがカスタムメトリクス・ログを送信する。
2. CloudWatchはメトリクスを時系列で保持し、ダッシュボードやAPIで可視化する。
3. アラームがメトリクスを評価し、しきい値超過や異常検出でアクション（SNS/Auto Scaling/EC2等）を起動する。
4. EventBridgeがイベント/スケジュールに基づきLambda等のターゲットを実行する。
5. Logsはメトリクスフィルターやサブスクリプションで分析/転送される。

EC2・RDS・Lambda・ELB・API Gateway・DynamoDBなど主要サービスと統合され、Auto Scalingや運用自動化の起点として機能します。

4. セキュリティと認証・認可

• IAMによるアクセス制御: メトリクス/ログ/アラームの操作をポリシーで細かく制御。Agentには専用ロールを付与。
• 暗号化: CloudWatch Logsは保存時にKMSで暗号化可能。転送はTLS。
• VPCエンドポイント（PrivateLink）: インターネットを経由せずCloudWatch/Logsへ送信。
• CloudTrail連携: CloudWatchへのAPI操作を監査。逆にCloudTrailログをCloudWatch Logsへ送り、メトリクスフィルター+アラームで不審操作を検知できる。

5. 料金形態

• メトリクス: カスタムメトリクス数で課金。標準メトリクスの多くは無料、詳細モニタリング（1分）は有料。
• API: PutMetricData/GetMetricData等の呼び出し回数で課金。
• ログ: 取り込み量（GB）・保存量（GB）・Logs Insightsのスキャン量で課金。
• アラーム: アラーム数で課金（高解像度/複合/異常検出は単価が異なる）。
• ダッシュボード: 一定数まで無料、超過分は月額。
• Synthetics/RUM/Insights: 実行回数やイベント数で課金。
• コスト最適化: ログ保持期間の設定、不要メトリクス削減、サブスクリプションでの集約が有効。

6. よくあるアーキテクチャ・設計パターン

• Auto Scaling連携: CPU使用率やカスタムメトリクスのアラームでスケールアウト/インを駆動。
• エラー監視: アプリログをメトリクスフィルターで集計し、ERROR急増時にSNS通知。
• OSメトリクス収集: CloudWatch Agentでメモリ/ディスクを取得し、しきい値アラーム。
• ログのリアルタイム処理: サブスクリプションフィルター → Lambda/Kinesis/OpenSearchで分析・可視化。
• 運用自動化: EventBridgeルールでイベント駆動のLambda/Step Functionsを起動。
• 外形監視: Synthetics Canaryで主要URLの可用性を継続監視。
• セキュリティ監視: CloudTrail → CloudWatch Logs → メトリクスフィルター + アラームで不正操作を検知。

7. 設定・デプロイ手順（ハンズオン例）

1. EC2に統合CloudWatch Agentをインストールし、メモリ/ディスク/ログ収集の設定を適用する。
2. ロググループを作成し、保持期間とKMS暗号化を設定する。
3. ログにメトリクスフィルターを作成し、ERROR件数をメトリクス化する。
4. そのメトリクスにアラームを作成し、SNSトピックで通知する。
5. CPU使用率アラームをAuto Scalingポリシーに関連付ける。
6. EventBridgeルールでスケジュール実行のLambdaを設定する。
7. ダッシュボードを作成し、主要メトリクスとログを可視化する。

8. 試験で問われやすいポイント