あるEC2インスタンスのCPU使用率が80%を超えた状態が5分間継続した場合に、管理者のメールアドレスに通知を送信し、自動的に新しいインスタンスを追加するオートスケーリングを実行したいと考えています。この一連の監視とアラーム発火を担う最適なAWSサービスはどれですか？

解説

EC2インスタンスのCPU使用率などのメトリクス（性能指標）を収集し、設定した閾値に基づいてアラームを発火させる要件では、Amazon CloudWatchが最適な選択肢となります。システムを安定稼働させるための監視基盤として、AWS環境では欠かせない中心的なサービスです。CloudWatch、CloudTrail、Configの違いと使い分けAWSの運用において「CloudWatchとCloudTrailの違い」や「Configとの使い分け」は非常によく検索されるテーマです。これらは目的が明確に異なります。Amazon CloudWatch: リソースの「パフォーマンス（状態）」を監視します。CPU使用率やネットワークトラフィックなどを追跡します。AWS CloudTrail: リソースへの「誰が何をしたか（APIコール）」を記録します。セキュリティ監査やトラブル時の操作履歴調査に使われます。AWS Config: リソースの「設定の変更履歴（構成）」を記録・評価します。セキュリティポリシーに違反する設定がされていないか継続的に確認します。つまり、今回は「CPU使用率」というパフォーマンス指標をトリガーとするため、CloudWatchが正解となります。なお、AWS X-Rayはマイクロサービスなどの分散アプリケーションの通信のトレースやボトルネック特定に用いるサービスです。アラームを利用した自動復旧とスケーリングの実装実務において、CloudWatchは単にダッシュボードでグラフを眺めるだけでなく、異常検知時のアクションの自動化に真価を発揮します。たとえば、今回の問題のように「CPU使用率が80%を超えたら（アラーム状態）」という条件をもとに、Amazon SNS（Simple Notification Service）を連携させてSlackやメールに通知を飛ばす構成が一般的です。さらに、EC2 Auto Scalingと組み合わせることで、負荷が高いときだけサーバー台数を自動で増やし、負荷が下がったら減らすといった柔軟なインフラ構築が可能になります。標準メトリクスで取れない値に注意CloudWatchを利用する際によくハマる落とし穴が、「OS内部の詳しい指標はデフォルトでは取得できない」という点です。EC2インスタンスのCPU使用率やネットワークI/Oはハイパーバイザー側から取得できるため標準で用意されていますが、メモリ使用率やディスクの空き容量はOS内部に入り込まないとわからない情報です。これらを監視したい場合は、対象のEC2インスタンスにCloudWatchエージェントをインストールし、「カスタムメトリクス」として明示的にデータを送信する設定が必要です。{ "metrics": { "metrics_collected": { "mem": { "measurement": ["mem_used_percent"] } } } }このように、要件に合わせて標準とカスタムを使い分けることがシステム監視の基本となります。