AWS Compute Optimizer入門｜EC2インスタンスを自動最適化してコストを削減する実践ガイド

オンプレ環境でのサーバー調達は、将来のピーク需要を見越してスペックを盛りがちでした。結果として、平常時はCPU使用率が10%に満たないサーバーが並ぶ——そんな光景を見てきたエンジニアは多いはずです。
クラウドに移行したからといって、この「過剰スペック問題」が自動的に解決するわけではありません。AWSでも「とりあえず大きめのインスタンスで」という判断が積み重なり、気づけば毎月の請求が想定の倍になっているケースは珍しくないのです。

そこで活躍するのが AWS Compute Optimizer。機械学習でEC2の実使用データを分析し、「このインスタンス、実は2サイズ小さくしても十分ですよ」と推奨を出してくれるサービスです。

この記事では、AWS Compute Optimizerの概要から有効化手順・推奨の読み方・実務での活用Tipsまで、オンプレ経験者にもわかりやすく解説します。

なぜCompute Optimizerなのか？オンプレとの決定的な違い

オンプレでは、サーバーを「もったいなくて縮小できない」構造が根本的な問題でした。物理機器は返却できないし、VMを小さくしても月額費用は変わらない。そのため、過剰スペックのまま運用し続けることが合理的でした。

AWSは違います。インスタンスタイプはいつでも変更でき、使った分だけ課金される従量課金モデルです。つまり、スペックを最適化するほど直接コストが下がる構造になっています。

ただし「どこを最適化できるか」の判断は難しい。EC2コンソールを眺めても、個々のインスタンスの使用傾向を串刺しで分析するのは手間がかかります。Compute Optimizerはこの課題をAWSが自動で解決してくれるサービスです。

AWS Compute Optimizerで分析できるリソース

Compute Optimizerが推奨を出せるAWSリソースは以下の通りです（2026年3月時点）。

・Amazon EC2インスタンス: インスタンスタイプの変更推奨（最適化・過剰・不足を判定）
・Amazon EC2 Auto Scalingグループ: スケールアウトの閾値・インスタンスタイプの推奨
・Amazon EBSボリューム: ボリュームタイプ（gp2→gp3移行等）とサイズの推奨
・AWS Lambda関数: メモリサイズと実行時間のトレードオフ最適化
・Amazon ECSサービス（Fargateのみ）: vCPUとメモリの割り当て最適化

この記事では最もニーズが高い EC2インスタンスの最適化 に絞って解説します。

基本的な使い方（コンソール操作）

1. Compute Optimizerを有効化する

Compute Optimizerは初期状態では無効になっています。まずは有効化から始めます。

AWSマネジメントコンソールで「Compute Optimizer」と検索し、サービスページを開きます。「Get started」ボタンをクリックすると、有効化の確認画面が表示されます。

有効化には AWSが自動的にサービスリンクロール（AWSServiceRoleForComputeOptimizer）を作成する必要があります。このロールを通じて、EC2のCloudWatchメトリクス（CPU使用率・ネットワーク送受信量等）を最大13週間分取得して分析します。

# AWS CLIで有効化することも可能
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts  # Organizationsを使っている場合は全メンバーアカウントに適用

# 有効化状態の確認
aws compute-optimizer get-enrollment-status

注意点: 有効化後、最初の推奨が表示されるまで 最低12〜24時間 かかります。CloudWatchに十分なメトリクスが蓄積されていない新規インスタンスは「データ不足」と表示されます。

2. 推奨事項を確認する

Compute Optimizerのダッシュボードを開くと、以下の4分類でEC2インスタンスが整理されています。

・過剰プロビジョニング (Over-provisioned): 現在のスペックが過剰。小さくしてもよい状態
・不足プロビジョニング (Under-provisioned): スペックが足りておりパフォーマンス影響のリスクあり
・最適化済み (Optimized): 現在のインスタンスタイプが最適
・データ不足 (Insufficient data): 分析に必要なデータが不足（有効化直後や起動直後）

コスト削減の観点では、「過剰プロビジョニング」のインスタンスを重点的に確認します。クリックすると個別の推奨詳細が表示されます。

3. 推奨詳細を読む

各インスタンスの推奨画面では、以下の情報が表示されます。

・現在のインスタンスタイプ: 例）m5.2xlarge
・推奨インスタンスタイプ（最大3候補）: 例）m5.xlarge / m5a.xlarge / m6i.xlarge
・推定月額削減額（USD）: インスタンスの料金差分（オンデマンド料金ベース）
・パフォーマンスリスク: Low / Medium / High で表示（Lowのみを対象にするのが安全）
・使用率グラフ: 過去13週間のCPU・ネットワーク・ディスクIOの推移

# AWS CLIでEC2推奨を一括取得（JSON形式）
aws compute-optimizer get-ec2-instance-recommendations \
  --region ap-northeast-1 \
  --output json | jq '.instanceRecommendations[] | {
    instanceArn: .instanceArn,
    finding: .finding,
    estimatedMonthlySavings: .recommendationOptions[0].estimatedMonthlySavings
  }'

4. 推奨に従ってインスタンスタイプを変更する

Compute Optimizerの推奨はあくまでも「参考情報」であり、変更はコンソールやAWS CLIから手動で行います（自動変更はしません）。

インスタンスタイプの変更手順:

・インスタンスを停止する（stop状態にしないとタイプ変更不可）
・EC2コンソール→インスタンス→「インスタンスタイプの変更」を選択
・推奨されたタイプを選択して適用
・インスタンスを起動して動作確認

料金の仕組み（コスト感覚）

AWS Compute Optimizerの基本機能は無料で利用できます（2026年3月時点）。

ただし、追加の分析機能には費用が発生します。

・強化型インフラストラクチャメトリクス（Enhanced Infrastructure Metrics）: メモリ使用率などOSレベルのメトリクスも加えた精度の高い分析。EC2インスタンス1台あたり約$0.003/時間（東京リージョン、2026年3月時点）
・外部メトリクス統合: DatadogやDynatrace等の外部監視ツールのデータを取り込む機能（別途費用）

基本機能だけでも十分なコスト削減の推奨が得られます。まずは無料機能から始めることを推奨します。

【コスト削減の試算例】
m5.2xlarge（東京リージョン、オンデマンド）→ m5.xlarge に変更した場合:
・m5.2xlarge: 約$0.384/時間 × 730時間 ≒ 約$280/月
・m5.xlarge: 約$0.192/時間 × 730時間 ≒ 約$140/月
・削減額: 約$140/月（年間約$1,680）

これが5台あれば年間約$8,400のコスト削減につながります。

応用・実務Tips

【重要】Organizations全体に適用してスケールする

複数のAWSアカウントをOrganizationsで管理している場合、管理アカウントからCompute Optimizerを一括有効化できます。全メンバーアカウントのEC2を横断的に分析できるため、コスト最適化の効果が大幅に広がります。

推奨をCSVエクスポートして定期レビューに活用

コンソールの「推奨のエクスポート」機能を使うと、推奨内容をS3バケットにCSV形式で出力できます。これをスプレッドシートに取り込み、月次のコストレビュー資料として活用するのが実務での定番アプローチです。

# AWS CLIでEC2推奨をS3にエクスポート
aws compute-optimizer export-ec2-instance-recommendations \
  --s3-destination-config bucket=my-cost-report-bucket,keyPrefix=compute-optimizer/ \
  --region ap-northeast-1

# エクスポートジョブの確認
aws compute-optimizer describe-recommendation-export-jobs

変更前後に必ずCloudWatchで監視を強化する

インスタンスタイプを変更した直後は、CPU使用率・メモリ使用率・レイテンシを72時間集中的に監視します。Compute Optimizerの推奨は過去データに基づくため、季節性や突発的な負荷増加には対応できていない場合があります。

変更後に問題が発生した場合は、すぐに元のサイズに戻せるよう変更手順をRunbookとして文書化しておくことを推奨します。

EBS gp2→gp3移行も見逃さない

Compute Optimizerの推奨には、EC2インスタンス以外にEBSボリュームの最適化提案も含まれます。特に gp2ボリュームのgp3移行は、同等のパフォーマンスを保ちながら約20%のコスト削減が見込める定番施策です。EC2の推奨と合わせて確認しましょう。

クラウドセキュリティの観点から適切なリソース管理とコスト制御を行う方法については、姉妹サイトSecurityMasters.TOKYOでも詳しく解説しています。

よくあるトラブルと対処法

推奨が「データ不足」のまま変わらない

原因: EC2インスタンスの起動直後や、CloudWatchの詳細モニタリングが無効になっている場合に発生します。
対処法: EC2の「詳細モニタリング」を有効化し、1〜3日間待機してください。詳細モニタリングを有効にすることで、1分間隔のメトリクス取得となり分析精度が向上します。

推奨通りに変更したら性能が低下した

原因: Compute Optimizerが分析できるのはCPU・ネットワーク・ディスクIOのみで、メモリ使用率は標準では含まれません。メモリを大量に使うJavaアプリやDBサーバーは要注意です。
対処法: CloudWatch Agentをインストールしてメモリ使用率をCloudWatchに送信するか、「強化型インフラストラクチャメトリクス」を有効化して分析精度を上げてから推奨を再評価してください。

推奨に「パフォーマンスリスク: High」が多い

原因: CPU使用率が一時的にスパイクするワークロードや、分析データが少ない場合にリスクが高くなります。
対処法: パフォーマンスリスクがLowのインスタンスだけを最適化の対象にし、MediumやHighは実際の負荷パターンを詳しく確認してから判断することを推奨します。

本記事のまとめ

AWS Compute Optimizerは、オンプレで「見て見ぬふり」にしていた過剰スペック問題をAWSが自動で可視化してくれる強力なツールです。

基本機能は無料で使えます。まずは有効化して「過剰プロビジョニング」のリストを確認することから始めてみてください。意外な削減余地が見つかるはずです。