SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業はLinux EC2インスタンス50台を運用しています。デフォルトのCloudWatchメトリクスではCPU使用率しか取得できておらず、メモリ使用率やディスク使用率の監視ができていないため、OOMエラーやディスクフルが発生してから対処する状況が続いています。メモリ使用率とディスク使用率をCloudWatchに継続送信してアラームを設定する、最も運用負荷が低い方法はどれですか？
AAmazon CloudWatch AgentをEC2インスタンスにインストールし、mem_used_percentとdisk_used_percentを有効にした設定ファイルをSSM Parameter Storeに格納してSystems Manager Run Commandで50台に一括配布する
✓ 正解
CloudWatch AgentはAWSが公式に提供するエージェントで、mem_used_percentなどのOSメトリクスを標準サポートしており、SSMと組み合わせた一括配布により50台規模でも運用負荷が低い。
B各EC2インスタンスにcronジョブを設定してfreeコマンドとdfコマンドの出力をシェルスクリプトで解析し、AWS CLIのput-metric-dataコマンドでCloudWatchにカスタムメトリクスを定期送信する
cronジョブ＋シェルスクリプトは動作するが、スクリプトのバージョン管理・障害対応・設定変更を50台分個別に行う必要があり、スケールすると運用負荷が大幅に増加する。
CSSMエージェントのInventory機能を各EC2インスタンスで有効化してメモリとディスク情報を収集し、Systems Manager ExplorerでリソースキャパシティをCloudWatchメトリクスとして可視化する
SSM Inventoryはインストール済みソフトウェアやOSパッチ情報などの構成情報収集が目的であり、継続的なメモリ・ディスク使用率のメトリクス送信機能を持たない。
DAmazon Inspector v2エージェントをEC2インスタンスに導入してOSレベルのリソース使用状況をスキャンし、結果をEventBridge経由でCloudWatch Logsに転送してメトリクスフィルターでアラームを設定する
Amazon Inspector v2はCVE脆弱性スキャンツールであり、リソース使用率の継続的なモニタリングやCloudWatchカスタムメトリクスの自動送信機能を持たない。
解説
Amazon CloudWatch Agentは、EC2インスタンスにインストールすることでメモリ使用率（mem_used_percent）やディスク使用率（disk_used_percent）などデフォルトでは取得できないOSレベルメトリクスをCloudWatchに送信できるAWS公式エージェントです。設定ファイルをSSM Parameter Storeに一元管理し、Systems Manager Run Commandで50台に一括配布することで手動作業を最小化したスケーラブルな運用が実現します。
選択肢BのcronジョブとAWS CLIは技術的には動作しますが、スクリプトの管理・更新・障害時のデバッグを50台分個別に対応する必要があり、運用負荷が高い。
選択肢CのSSM Inventoryは、ソフトウェアや構成情報を収集するための機能であり、継続的なリアルタイムメトリクス送信とCloudWatchアラームの設定用途ではない。
選択肢DのInspector v2は脆弱性スキャンツールであり、OSリソース使用率の継続的なメトリクス収集とCloudWatchアラーム設定を目的とした製品ではない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →