ある企業はオンプレミスからのリフトアンドシフト移行直後に 200 台の EC2 インスタンスを運用しています。移行時にオンプレミスのスペックをそのままコピーしたため、インスタンスの多くが過剰プロビジョニングになっている可能性があります。最小限の運用工数でコスト削減の機会を特定し、適切なインスタンスタイプへ変更するための最適なアプローチはどれですか？
AWS Compute Optimizer は、過去 14 日間の CloudWatch メトリクス（CPU・メモリ・ネットワーク・ディスク I/O など）を機械学習で総合分析し、EC2 インスタンス・Auto Scaling グループ・EBS ボリューム・Lambda 関数・ECS on Fargate サービスに対してリサイズ推奨を提供します。単純な閾値ではなくリソース使用パターン全体を考慮するため精度が高く、200 台分の推奨を一括取得できるため運用工数を最小化できます。基本機能は追加費用なしで利用できます。 選択肢Aの CloudWatch メトリクスの手動レビューは 200 台のインスタンスに対して非常に大きな工数がかかります。メトリクスの解釈も属人的になりがちで、最小限の運用工数という要件を満たしません。 選択肢Cの AWS Trusted Advisor のコスト最適化チェックは CPU 使用率の単純な閾値（例：14 日間平均が低いインスタンス）に基づく分析であり、メモリや I/O など他のリソース指標を考慮しないため、Compute Optimizer と比べて推奨精度が低くなります。 選択肢Dの EC2 Auto Scaling はトラフィックに応じてインスタンス数をスケールイン・アウトするサービスです。個々のインスタンスタイプを最適化するライトサイジングとは目的が異なります。