AWS Compute Optimizerとは？仕組み・レコメンデーションの読み方と料金・採用判断を実装者目線で解説

AWS Compute Optimizerは、CloudWatchのメトリクスを機械学習で分析し、EC2やEBS・Lambdaなどのリソースが過剰か不足かを判定して「適正なサイズ」を推奨するマネージドサービスです。基本機能は追加料金なしで使え、オプトインするだけで各リソースに推定コスト削減額つきのレコメンデーションが並びます。この記事では、分析の仕組みとfindingsの4分類の読み方、無料枠（14日）と拡張インフラストラクチャメトリクス（93日・有料）の料金差、オプトインからエクスポートまでの実装手順、そして「どこまで自動推奨を信じてよいか」という採用・見送りの判断基準を、AWS運用の実装者目線で整理しました。

まとめ：Compute Optimizerはrightsizingの一次スクリーニングに使う

AWS Compute Optimizerは、リソース適正化（rightsizing）の「当たりをつける」段階に向いたツールです。CloudWatchが持つCPU・メモリ・ネットワーク・ディスクのメトリクスを機械学習で読み、EC2・EC2 Auto Scaling・EBS・Lambda・ECS on Fargate・RDS/Auroraなど十数種のリソースに対して、過剰プロビジョニング／プロビジョニング不足／適正（Optimized）の判定と、変更後の推定コスト・推定パフォーマンスリスクを返してくれます。

使いどころは明確です。まずアカウント（または組織）をオプトインして無料の14日分析を回し、推定削減額の大きいリソースから人が中身を確認する。メモリ基準まで見たい場合はCloudWatch Agentでメモリメトリクスを入れ、長期の傾向で判断したいなら拡張インフラストラクチャメトリクス（1リソースあたり毎時約0.00034 USD・31日連続で月0.25 USD前後）で93日に延ばします。反対に、月次バッチのような周期負荷や、直近14日が平常でない移行直後のワークロードでは推奨をそのまま適用せず、Cost Explorerの請求実績と突き合わせて人が最終判断する——この線引きが運用の肝になります。数値・料金は2026年7月時点の公式ドキュメント記載に基づく非断定の目安です。

AWS Compute Optimizerの定義と分析の仕組み

最初に、Compute Optimizerが「何を根拠に何を返すサービスか」を押さえます。ここを取り違えると、後述のレコメンデーションを過信する事故につながりかねません。

追加料金なしで始められるオプトイン型のマネージド分析サービス

Compute Optimizerは、利用者がEC2やEBSに支払う料金とCloudWatchのモニタリング料金以外に、サービス自体の追加料金がかからないマネージドサービスです（基本機能の場合）。エージェントの常駐やコードの計装は不要で、コンソールまたはAPIでオプトインすると、AWSが既に収集しているメトリクスを裏側で分析し始めます。裏を返すと、オプトインしないうちは何も生成されません。まず有効化が起点になります。分析対象は自アカウントのリソースで、AWS Organizations配下では管理アカウントからオプトインすることで複数メンバーアカウントの結果を横断表示できます。

CloudWatchメトリクスを機械学習で読み推奨サイズを出す

推奨の根拠は、CloudWatchが保持するリソースの仕様と使用率メトリクスです。EC2であればvCPU・メモリ・ストレージといった構成に加え、CPU使用率・ネットワークI/O・ディスク読み書きなどの実測値を、機械学習モデルで過去のパターンとして分析します。デフォルトの分析期間（ルックバック）は直近14日で、レコメンデーションを生成するにはおおむね連続した実稼働メトリクスが一定量必要になります（EC2ではおよそ30時間分が目安）。立ち上げ直後のインスタンスに推奨が出ないのは、この蓄積量が理由です。メモリ使用率はEC2の標準メトリクスに含まれないため、メモリを判断材料に入れるにはCloudWatch Agentの導入が前提になります。メトリクス計装の全体像はAWSオブザーバビリティ（CloudWatch・Container Insights）の実装解説に整理しています。

コンピューティングからストレージまで対応するリソース種別の広がり

提供当初のEC2中心から対象は広がっています。2026年7月時点でコンソール上に並ぶ対象は次のリソースです。どのリソースを見たいかで、後述のメトリクス準備の要否が変わってきます。

データベース系はRDS/Aurora・DynamoDB・ElastiCache・MemoryDB・DocumentDBまで対象で、その他にNAT Gateway・WorkSpaces・SageMaker・商用ライセンスも判定されます。EC2やEBSの個々のサービス概念は、Amazon EC2の仕組みとインスタンスタイプやAmazon EBSのボリュームタイプと料金の解説と併読すると、なぜその推奨が出るのかを読み解きやすくなります。

Compute Optimizerのレコメンデーションの読み方と料金体系

Compute Optimizerの価値は、出てきた推奨を正しく解釈できるかで決まります。findingsの意味と、推定値・料金プランの違いを分けて理解しましょう。

findingsの4分類（過剰・不足・適正・データ不足）の読み分け

各リソースには判定（findings）が付きます。EC2を例にとると分類は次の4つで、判定名だけで機械的に動かず、推定リスクとセットで読み解くのが原則です。

• Over-provisioned（過剰プロビジョニング）：スペックが使用実績に対して過大。ダウンサイズで請求を下げられる候補。
• Under-provisioned（プロビジョニング不足）：CPUやメモリが逼迫。性能面のリスクがあり、スケールアップ候補。
• Optimized（適正）：現行構成が使用実績に見合っている状態。原則そのまま。
• None（データ不足）：メトリクスが足りず判定不能。稼働時間や計装を先に整える。

コスト削減だけを狙うとOver-provisionedばかりに目が行きがちです。ただしUnder-provisionedを放置すると障害の芽になります。削減と性能改善の両面で並べ替えるのが実務の読み方です。

推定コスト削減額とパフォーマンスリスク指標を併読する判断の要点

各推奨には、変更後の推定月額・推定削減額に加えて「パフォーマンスリスク（現行より性能が下がる可能性の度合い）」が数値で付きます。ここが単純なCPU閾値ツールとの差です。たとえば同じ「1サイズ下げる」でも、リスク指標が低い候補から着手すれば、体感性能を落とさずに請求だけを削れます。EC2の推奨には複数の代替インスタンスタイプが提示され、料金順・リスク順で比較できるため、Graviton系への乗り換え候補が混じることもあります。削減額の合算はアカウント全体のダッシュボードでも確認できますが、実際の請求インパクトはAWS Cost Explorerでのコスト可視化と突き合わせて検証しましょう。Compute Optimizerが「どのリソースをどう変えるか」を示し、Cost Explorerが「請求としてどう効いたか」を裏取りする役割分担になります。

無料の14日分析と拡張インフラストラクチャメトリクス（93日・有料）

ルックバック期間には2段階あります。無料の基本機能が分析するのは直近14日です。より長い傾向で判断したい場合は「拡張インフラストラクチャメトリクス」を有効にすると、ルックバックを最大93日（約3か月）に延ばせます。こちらは有料で、料金は2026年7月時点で1リソースあたり毎時0.0003360215 USD、31日連続で稼働するリソース1つあたり月0.25 USD前後が目安です（対象はEC2・EC2 Auto Scaling・RDS）。

週末だけ跳ねる、月末バッチで山が来るといった周期性のあるワークロードは、14日では山谷を取りこぼすことがあります。周期の1サイクルが14日を超えるなら、拡張メトリクスで93日に延ばす投資を検討しましょう。

AWS Compute Optimizerの導入・実装手順とデータ準備

ここからは実際に有効化して推奨を得るまでの流れです。つまずきやすいのはメモリメトリクスとエクスポート周りになります。

単一アカウントとOrganizations環境でのオプトイン手順

有効化はコンソールの「使用を開始する」またはAPI（PutRecommendationPreferences等）から行います。単一アカウントならそのアカウントで、Organizations環境なら管理アカウントでオプトインし、対象をメンバーアカウントに広げていきます。分析には対象リソースのメトリクス読み取り権限が必要です。初回はサービスにリンクされたロールが自動で作成されます。オプトイン後すぐには結果が出ず、14日のルックバックと必要メトリクス量が満たされるまでは一部がNone判定のままです。まっさらな環境では、数日おいてから確認する前提でスケジュールを組みましょう。

メモリ・詳細メトリクスの取得（CloudWatch Agent）

EC2の標準メトリクスにメモリ使用率とディスク使用率は含まれません。これらを判断材料に入れるには、対象インスタンスにCloudWatch Agentを導入してメモリ・ディスクのカスタムメトリクスを送る必要があります。メモリを見ずにダウンサイズ推奨を適用すると、CPUは余裕でもメモリが逼迫しているワークロードでOOMを招くおそれがあります。Javaアプリやインメモリキャッシュのように、メモリが律速になりやすい構成では、Agent導入をrightsizing着手の前提条件にすると安全でしょう。Lambdaはメモリ設定が課金と性能を直接左右するため、Agentなしでも関数ごとのメモリ推奨が得られます（AWS Lambdaのメモリ設定とコールドスタートの観点と合わせて調整します）。

推奨のS3へのエクスポートとCost Explorerとの連携

アカウントやリソースが多い環境では、コンソールを1画面ずつ見るより、推奨をS3へCSV/JSONでエクスポートして集計する方が現実的です。エクスポートしたデータをAthenaやスプレッドシートでソートすれば、Organizations横断で削減額の大きい順に棚卸しできます。あわせて、Cost Explorer側のrightsizingレコメンデーションもEC2について同様の提案を出すため、両者の突き合わせで精度が高まる点も利点です。こうしたAWSのコスト適正化やリソース適正化を運用に組み込む設計・実装を外部に相談したい場合は、AWS・クラウドインフラ構築の受託で、監視計装から棚卸しフローの整備までを支援しています。

AWS Compute Optimizerの採用条件と過信すべきでない場面

Compute Optimizerは万能の自動チューナーではありません。どこで効き、どこで判断を人に戻すべきかを言い切ります。

Compute Optimizerを導入して効果が出やすい条件

次の条件がそろう環境では、費用対効果が高く出ます。まず、EC2やRDSを常時起動で複数台運用し、スペックを「とりあえず余裕を持って」選んだまま見直していないケース。次に、負荷が定常的で、14日のメトリクスに実運用が代表されているケース。そして、削減提案を人がレビューしてから適用する運用フローが用意できるケースです。追加料金なしで全体像が把握できるため、まだ棚卸しをしていない組織であれば、まずオプトインして削減額の合計を見るだけでも投資判断の材料になります。

自動推奨をそのまま本番適用すべきでない代表的な4つの失敗パターン

一方で、次の場面では自動推奨を鵜呑みにしないでください。第一に、月末・四半期末に負荷が集中する周期ワークロードを14日だけで見ると、山を含まない谷の期間が代表値になり、過小なダウンサイズを提案されます。この場合は拡張メトリクスで93日に延ばすか、ピーク期を含む期間で判断しましょう。第二に、システム移行・リリース直後でトラフィックが平常でない時期の推奨は、平常化するまで保留するのが安全です。第三に、メモリメトリクス未計装のままのダウンサイズは、前述のOOMリスクがあるため見送ります。第四に、Auto Scalingで水平にさばく設計のワークロードでは、1台のスペックを縮める垂直方向の推奨より台数ポリシーの調整が効くことがあり、推奨の方向性そのものが構成意図と合わない場合もある点に注意が必要です。Compute Optimizerは「候補の抽出」までを担い、本番適用の可否は構成意図とビジネス要件を知る人が決める——この分担を崩さないことが、コスト削減と可用性を両立させる条件になります。

よくある質問

AWS Compute Optimizerの導入検討でよく挙がる疑問を、実装者目線で整理します。

AWS Compute Optimizerは無料で使えますか？

基本機能は追加料金なしで使えます。支払うのは対象リソース（EC2等）の料金とCloudWatchのモニタリング料金だけです。ルックバックを93日に延ばす拡張インフラストラクチャメトリクスのみ有料で、2026年7月時点で1リソースあたり毎時0.0003360215 USD、31日稼働で月0.25 USD前後が目安になります。まず無料の14日分析から始め、周期負荷の判断が必要なリソースだけ拡張を有効にする使い分けが現実的です。

Compute OptimizerとCost Explorerの違いは何ですか？

役割が異なります。Compute Optimizerはメトリクスを機械学習で分析し「どのリソースをどのサイズに変えるか」という技術的な適正化案を出します。一方のCost Explorerは請求データを可視化し「コストがどこにいくらかかっているか」を分析するツールです。実務では、Compute Optimizerで変更候補を抽出し、適用後にCost Explorerで請求がどう変わったかを裏取りする、という順で併用します。

メモリ使用率も見て推奨してくれますか？

標準のままではメモリを見ません。EC2のメモリ使用率とディスク使用率はデフォルトのCloudWatchメトリクスに含まれないため、対象インスタンスにCloudWatch Agentを導入してカスタムメトリクスを送る必要があります。メモリを送っていない状態でのダウンサイズ推奨はCPUのみを根拠にしており、メモリ律速のワークロードでは適用前に必ず確認しましょう。LambdaやFargateはメモリ設定自体が構成要素のため、Agentなしでもメモリに関する推奨が得られます。

推奨が「None（データ不足）」になるのはなぜですか？

分析に足るメトリクスが蓄積されていないためです。オプトイン直後や、起動して間もないインスタンス（EC2ではおよそ30時間分の連続メトリクスが目安）、停止と起動を繰り返すリソースではNoneになりやすくなります。時間の経過でメトリクスがたまれば判定が付きます。恒常的にNoneが続く場合は、対象リソースが分析要件を満たす稼働をしているか、必要なメトリクスが送信されているかを確認しましょう。

推奨どおりに変更すれば自動で反映されますか？

いいえ、Compute Optimizer自体はリソースを変更しません。提示されるのは推奨と推定値までで、インスタンスタイプの変更やEBSの再設定は利用者が実施します。誤った適用を避けるため、レビュー→ステージングで検証→本番適用というフローを挟むのが安全でしょう。大規模環境では推奨をS3へエクスポートし、削減額順に棚卸ししてから計画的に反映します。

関連記事

• AWS Cost Explorerとは？コスト可視化・分析の仕組みと料金：Compute Optimizerの推奨を請求実績で裏取りする併用先。
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル：rightsizing推奨の主対象。タイプ選定の前提知識。
• Amazon EBSとは？仕組み・ボリュームタイプと料金モデル：EBSボリューム推奨（タイプ・IOPS）の背景。
• AWS Lambdaとは？仕組み・料金体系とコールドスタート対策：Lambdaメモリ推奨とチューニングの観点。
• AWSオブザーバビリティの実装（CloudWatch・Container Insights）：判断材料となるメトリクス計装の全体像。