AWS 認定資格 ラボ
コンピューティング ・

AWS Compute Optimizer 完全ガイド：ML ベースのリソース最適化レコメンドで月次コスト削減

AWS Compute Optimizer は CloudWatch メトリクスを機械学習で分析し、EC2・Auto Scaling・EBS・Lambda・ECS Fargate・RDS・NAT Gateway の各リソースに「ダウンサイズ可能」「アップサイズ推奨」「最適」のレコメンドを提示する無料サービス。Finding と Finding Reason の読み方、過去 14 日 → 93 日に拡張する Enhanced Infrastructure Metrics（$0.0003360215/h/resource）、Trusted Advisor との使い分けまで現場目線で整理する。

#AWS #Compute-Optimizer #コスト最適化 #機械学習 #コンピューティング

「とりあえずワンサイズ大きめで構築した EC2／RDS」が積もると年間コストは静かに膨らむ。Compute Optimizer はそれを CloudWatch メトリクス × 機械学習 で炙り出し、無料で具体的な代替インスタンスタイプまで提示してくれる。SOA 試験のコスト最適化問題でも頻出の「最初に開くべきダッシュボード」を整理する。

📑 目次

  1. 概要（端的に）
  2. 対応リソースの全体像
  3. Finding と Finding Reason の読み方
  4. 仕組み：14 日メトリクスから推奨が生まれるまで
  5. Enhanced Infrastructure Metrics（有料）の価値
  6. 有効化の手順（最短ルート）
  7. 現場で生きる活用パターン 5 つ
  8. Trusted Advisor / Cost Explorer との使い分け
  9. メリット・デメリット
  10. 運用ベストプラクティス
  11. 関連用語
  12. 関連サイト
  13. 🎓 試験での出題傾向

1. 概要（端的に）

AWS Compute Optimizer は、過去の CloudWatch メトリクスを機械学習で分析し、各リソースに「ちょうどよいサイズ／タイプ」を推奨する無料サービス。SOA／SAA 試験では「インスタンスサイズを継続的に最適化したい」「過剰スペックを根拠付きで削減したい」というシナリオで必ず候補に挙がる、いわば コスト最適化の最初の一歩 にあたる。

通常の Cost Explorer が「いくら使ったか」を可視化する 事後分析 であるのに対し、Compute Optimizer は「今のサイズは適正か」を レコメンド として返す。有効化するだけ・追加コストなし・推奨理由まで提示 という三拍子が揃っており、未有効化のアカウントを見かけたら最初に有効化したい標準ツールである。

2. 対応リソースの全体像

2026 年現在、Compute Optimizer は以下のリソースに対してサイジング・タイプ変更・アイドル検知のレコメンドを返す。

カテゴリ対応リソース主な推奨内容
EC2EC2 インスタンスインスタンスタイプ／世代変更（最大 3 候補）
Auto ScalingEC2 Auto Scaling グループ起動テンプレートのインスタンスタイプ
EBSEBS ボリューム（gp2/gp3/io1/io2 など）ボリュームタイプ変更・IOPS／スループット最適化
LambdaLambda 関数メモリ設定値（Power Tuning 的な推奨）
ECS（Fargate）ECS Fargate サービスタスクの vCPU・メモリ設定
RDS / AuroraDB インスタンス／ストレージDB インスタンスクラス・ストレージ最適化
NAT GatewayNAT Gatewayアイドル状態の検出（利用がないものを通知）

2026 年 4 月の機能拡張で EC2 で 162 個、RDS で 32 個の新しいインスタンスクラスがレコメンド対象に追加 された（AWS What’s New 参照）。最新世代の Graviton 系（M8g、R8g 等）もカバーされ、世代交代によるコスト削減提案が出やすくなっている。

3. Finding と Finding Reason の読み方

Compute Optimizer の出力で最初に見るべきは、Finding（推奨の総評） と Finding Reason（その理由） の 2 つ。

3-1. Finding（3 段階）

Finding意味取るべきアクション
OVER_PROVISIONED過剰スペック。CPU・メモリ・ネットワークのいずれかが過大ダウンサイズの妥当性をレビューし適用
UNDER_PROVISIONED性能不足。少なくとも 1 指標で要件を満たしていないアップサイズ or 別ファミリ検討
OPTIMIZED適正。変更不要監視継続のみ

加えて Lambda などでは NOT_OPTIMIZED（最適化余地あり）、NAT Gateway では UNUSED（アイドル）といったラベルも返る。

3-2. Finding Reason（指標単位の根拠）

「総評」だけでなく、どの指標で過小／過剰なのか が明示されるのが Compute Optimizer の強み。代表的なラベル：

  • CPUUnderprovisioned / CPUOverprovisioned — CloudWatch CPUUtilization から判定
  • MemoryUnderprovisioned / MemoryOverprovisioned — CloudWatch Agent の mem_used_percent から判定（要追加設定）
  • NetworkBandwidthOverprovisioned — ネットワーク帯域が余っている
  • EBSThroughputUnderprovisioned / EBSIOPSUnderprovisioned — ストレージ I/O のボトルネック
  • DiskIOPSOverprovisioned — 過剰な IOPS プロビジョニング

メモリ判定だけは CloudWatch Agent でメモリメトリクスを送信していないと推奨が出ない ため、ベストプラクティスとして CloudWatch Agent を全本番ホストに常駐させておく構成が定着しつつある。

3-3. リスク区分（移行のしやすさ）

各レコメンドには Risk が Very Low → Low → Medium → High の 4 段階で付き、変更による性能劣化の懸念度 を示す。本番系では Very Low / Low のみ自動化対象とし、Medium 以上 は人手レビューに回す運用が現実的。

4. 仕組み：14 日メトリクスから推奨が生まれるまで

裏側のフローを簡略化すると次の通り。

  1. オプトイン：管理アカウントで AWS Organizations 連携を有効化、または個別アカウントで「Get started」を押す
  2. メトリクス取り込み：直近 14 日分 の CloudWatch メトリクス（CPU・ネットワーク・ディスク等）を Compute Optimizer 側に集約
  3. ML 推論：AWS が学習済みのモデルでワークロード特性（バースト型・定常型・週末ピーク型 等）を判定
  4. 代替タイプ評価：現行ファミリと数百種類の代替タイプを比較し、要件を満たす最廉価候補を最大 3 件提示
  5. 節約額計算：オンデマンド単価で「年額換算 $X」の削減見込みを併記
  6. ダッシュボード／API で公開：マネジメントコンソール、AWS CLI、SDK、Cost Optimization Hub から閲覧可能
EC2: i-0abcd...
現状: m5.4xlarge ($0.992/h, ~$8,690/年)
推奨1: m5.2xlarge ($0.496/h, ~$4,345/年) — 50% 削減, Risk: Very Low
推奨2: m6i.2xlarge ($0.448/h, ~$3,924/年) — 55% 削減, Risk: Low
推奨3: m7g.2xlarge ($0.408/h, ~$3,574/年) — 59% 削減, Risk: Medium（Graviton 移行）
理由: CPU 平均 12% (p95: 28%), メモリ 35%, ネットワーク 5% (過去 14 日)

最低 30 時間以上の稼働実績 が必要で、起動から 1 日程度の新規インスタンスや 24 時間だけの検証用は対象外になる点に注意（要件ドキュメント）。

5. Enhanced Infrastructure Metrics（有料）の価値

「無料で十分なのか？」という疑問への AWS の回答が Enhanced Infrastructure Metrics という有料オプション。

観点標準（無料）Enhanced
分析期間過去 14 日過去 93 日（最大 3 ヶ月）
料金$0約 $0.0003360215/h/resource（$0.25/月相当）
対応リソース全リソースEC2 / RDS
設定単位アカウント全体アカウント・OU・個別リソース

「14 日では業務サイクルが捉えきれない」場合（月次バッチ、四半期決算系、季節性のあるサービス）に有効。1 リソースあたり月 $0.25 という安さで、年 1 回の繁忙期を見越したサイジング判断ができる。

6. 有効化の手順（最短ルート）

6-1. シングルアカウント

  1. マネジメントコンソール →「Compute Optimizer」へ移動
  2. 「Get started」→ 「Opt in」 を選択
  3. 必要に応じて AWSServiceRoleForComputeOptimizer の作成を許可
  4. 12〜24 時間以内に初回レコメンドがダッシュボードに出現

6-2. AWS Organizations 配下を一括有効化

# 管理アカウントから組織全体をオプトイン
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

6-3. Enhanced Infrastructure Metrics の適用

# EC2 で 93 日メトリクス分析を有効化
aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --enhanced-infrastructure-metrics Active \
  --scope Name=AccountId,Value=123456789012

6-4. レコメンドのエクスポート（S3）

S3 バケットへ CSV／Parquet 形式でエクスポートでき、社内 BI ツールや FinOps ダッシュボードに統合できる。

aws compute-optimizer export-ec2-instance-recommendations \
  --s3-destination-config bucketName=my-finops-bucket,keyPrefix=co-export/

7. 現場で生きる活用パターン 5 つ

7-1. 月次の右サイジングレビュー

毎月 1 回、Compute Optimizer の Over-provisioned 一覧を CSV 出力 → コストオーナーへ通達。Risk: Very Low/Low のみ自動承認し、Medium 以上は四半期レビューへ。この運用だけで月 5〜15% のコスト削減実績が出るアカウントは珍しくない。

7-2. 移行直後（リフト＆シフト）の最適化

オンプレからの移行は 「現行スペックそのまま」 で決めることが多く、ほぼ確実にオーバープロビジョニングが残る。移行から 1 ヶ月後に Compute Optimizer を回すと、EC2／RDS いずれも「明らかなダウンサイズ余地」が大量に出てくる。

7-3. EBS gp2 → gp3 一括移行

S-006「EBS ボリュームタイプ完全比較」でも触れる通り、gp2 → gp3 で約 20% コスト削減 かつ性能据え置きが基本。Compute Optimizer の EBS レコメンドはこの移行候補をピックアップするのに最適。

7-4. Lambda メモリチューニング

Lambda は メモリ設定が CPU 配分にも連動する ため、「大きすぎる ≠ 安全」「小さすぎる ≠ 安価」。Compute Optimizer は実行時間と消費メモリから「コスト最小化」「実行時間最小化」のそれぞれを別軸で推奨してくれる。

7-5. Idle NAT Gateway の発見

検証アカウントで作って放置された NAT Gateway は時間課金で年 $400〜。Compute Optimizer のアイドル推奨で月次に検知して掃除する運用は、コスト × セキュリティ両面で効く。

8. Trusted Advisor / Cost Explorer との使い分け

似たような「最適化」系サービスとの守備範囲を整理しておくと、試験でも現場でも判断が早くなる。

Compute Optimizer / Trusted Advisor / Cost Explorer の比較
評価項目
Compute Optimizer 推奨
Trusted Advisor
Cost Explorer
一言で コンピュート系の右サイジング 5 領域のベストプラクティス点検 コストの可視化・将来予測
推奨方式 機械学習 ルールベース 集計・予測
料金 無料（拡張のみ有料） Business 以上で全機能 無料（粒度オプションは有料）
EC2 タイプ変更 ◎ 代替候補を 3 件提示 ○ 低利用率を検出 △ 集計のみ
RDS タイプ変更 ◎ クラス変更を提示 △ アイドル検出のみ ×
コスト予測 × × ◎ 6 ヶ月先まで
出力 推奨カード・CSV/Parquet エクスポート チェックレポート グラフ・レポート
『現状の妥当性』は Compute Optimizer、『運用全般の点検』は Trusted Advisor、『お金の流れ』は Cost Explorer。

3 つを 同じ画面で順番に見る 月次レビューを定例化するのが、FinOps を回す現場の鉄板パターン。

9. メリット・デメリット

10. 運用ベストプラクティス

  • 全本番アカウントで Day 1 から有効化 — 無料・有効化だけなので「使うかどうか」を悩む必要がない。組織標準として AWS Control Tower 等で強制したい。
  • CloudWatch Agent でメモリ／ディスクメトリクスを送る — メモリ判定が出ないと EC2 推奨の半分は活かせない。
  • 季節性のあるサービスに Enhanced Infrastructure Metrics を選択適用 — 月次バッチ・繁忙期がある業務系は 93 日分析が必須。
  • S3 エクスポート → Athena で SQL 分析 — 数千リソースを抱えるアカウントは UI だけでは捌けない。
  • Risk: Very Low/Low だけ自動化、Medium 以上は人手レビュー — 自動化と慎重さの両立。
  • Trusted Advisor のアイドル EC2／RDS 検出と組み合わせる — 「サイズを最適化する前にそもそも要らない」を Trusted Advisor で先に潰す。
  • Savings Plans は右サイジング後に組む — 過剰スペックのまま長期コミットすると損失が固定化する。順序は「ダウンサイズ → SP／RI コミット」が鉄則。
  • AWS Budgets のアクションと連動 — 予算超過時に Compute Optimizer の推奨を Slack 通知するワークフローが、AWS Budgets Actions ＋ EventBridge で組める。

11. 関連用語

12. 関連サイト

AWS 公式

参考記事

🎓 試験での出題傾向

試験重要度主な出題パターン
CLF低コスト最適化サービスの選択肢として名前を識別できれば十分
SAA中「インスタンスサイズを根拠付きで最適化したい」「過去メトリクスから機械学習で推奨してほしい」シナリオ
DVA低Lambda のメモリ最適化推奨を選ぶ問題で稀に登場
SOA高月次の右サイジング運用、Trusted Advisor / Cost Explorer との使い分け、Enhanced Infrastructure Metrics の必要性判断

特に SOA では「機械学習で → Compute Optimizer、ルールベースの 5 領域点検なら → Trusted Advisor、コストの可視化と将来予測なら → Cost Explorer**」と即答できるかが分岐点。3 つを並べる選択肢が頻出するため、「機械学習」「ルールベース」「予測」のキーワードで切り分けられるようにしておくと安全。