クラウドキャリアフリーランス
技術記事 2026/7/23

AWS Compute Optimizer 入門 — EBS と Fargate の過剰プロビジョニングを推奨で見つけて直す

AWS Compute Optimizer の使い方を入門解説。EBS と Fargate の過剰プロビジョニングを推奨(finding)で見つけ、32日ルックバックの設定と料金の線引きまでを技術的事実ベースで整理します。

  • #AWS
  • #ComputeOptimizer
  • #EBS
  • #Fargate
  • #コスト最適化
  • #右サイジング

過剰にプロビジョニングされた EBS ボリュームや Fargate タスクは、「たぶん大きすぎる」という感覚ではなく、過去の利用メトリクスにもとづく**推奨(finding)**として事実ベースに見つけられます。本記事では、AWS Compute Optimizer の使い方を入門として、有効化の前提・EBS と Fargate の推奨の読み方・32日ルックバックの設定・料金の線引き・推奨が出ない条件までを、公式ドキュメントの仕様に沿って整理します。仕様・UIのラベル・料金は変わり得るため、利用時は公式の最新情報をご確認ください。

Compute Optimizer の使い方 — 有効化と前提

Compute Optimizer は opt-in(有効化が必要) のサービスです。過去の CloudWatch メトリクスなどを分析して推奨を出しますが、推奨が表示されるには各リソースが CloudWatch メトリクス要件とリソース要件を満たす必要があり、有効化してから分析が完了するまで最大24時間かかります。推奨は毎日更新されます。

料金面の前提が一つあります。Cost Explorer の有効化が必須です。Compute Optimizer は Cost Explorer の課金データを使って savings(削減見込み額)や価格情報を算出するためです。あわせて、Cost Optimization Hub の opt-in が推奨されます。Reserved Instances や Savings Plans の割引を反映した推奨を受けられるためで、有効化していない場合はオンデマンド料金ベースで算出されます。

本記事では対象を EBS ボリュームと ECS サービス(Fargate) に絞ります。なお同じルックバックの仕組みは EC2 インスタンス・EC2 Auto Scaling グループ・RDS にも適用できます。ここで扱う ECS は Fargate 上で動くサービスを指し、EC2 起動タイプ一般の話ではない点に注意してください。

EBS 右サイジング推奨の読み方

EBS ボリュームの推奨は、volume type / volume size / IOPS / throughput の4つの次元で出ます。推奨ページには、現行ボリュームのスペック・finding 分類・現行の時間単価・推奨スペック・推奨後の月額・差額が並びます。既定の分析期間は直近14日で、毎日更新され、5分間隔の最大利用ポイントから生成されます。

読み方の軸は2つです。

  • Finding = Not optimized / Optimized。Optimized と表示されても、新世代の volume type への変更が推奨されることがあります。
  • Performance risk = very low 〜 very high。volume type・size・baseline/burst IOPS・baseline/burst throughput それぞれで算出され、その最大値が示されます。推奨を適用したときに性能不足が起きるリスクの目安です。
EBSとFargateの右サイジング推奨の読み方を対比した横長の図。EBSは現行ボリュームと推奨を volume type・size・IOPS・throughput の4次元で比較し、finding(Not optimized/Optimized)と performance risk(very low〜very high)を示す。Fargateはタスクの CPUサイズ・メモリサイズの現行と推奨を比較し、finding(Under-provisioned/Over-provisioned/Optimized)を示す。数値はダミーの概念図
図1: 推奨の読み方(概念図)。EBSは4次元+finding/risk、FargateはタスクのCPU/メモリ+finding。実数はコンソール・公式pricingを参照

ブロックストレージ(EBS)を適正容量に直すこの観点は、ストレージのクラス選定でコストを下げるS3ストレージのコスト最適化とは別の論点で、コスト最適化の両輪になります。

Fargate(ECSサービス)右サイジング推奨の読み方

Fargate サービスの推奨内容は、タスクの CPUサイズ / メモリサイズ(および互換するコンテナサイズ)です。CPUUtilizationMemoryUtilization をルックバック期間で分析し、利用グラフは1分間隔の最大利用ポイントで示されます。

Finding 分類は EBS と異なり、Under-provisioned / Over-provisioned / Optimized の3つです。CPU とメモリのどちらが過剰・不足かが理由として示されます。オートスケールで「速くする」観点はECSのオートスケールを速くする設計で扱う論点で、本記事の「適正容量にする」推奨とは補完関係にあります。

32日ルックバックの設定と、なぜ月次パターンに効くか

既定の分析期間は14日ですが、これを32日に拡張できます(2026年6月3日の機能追加)。対象は EC2 インスタンス・EC2 Auto Scaling グループ・RDS・EBS ボリューム・ECS サービスの5種で、追加費用はありません

価値は、月次の利用パターンを取りこぼしにくくなることです。月初のパッチ適用、定期再起動、月末バッチといった「14日では一度しか、あるいは一度も現れない」負荷を分析期間に含められるため、推奨の精度が上がります。

14日ルックバックと32日ルックバックで見える利用パターンの差を示す横長の概念図。14日の窓では月末バッチの負荷スパイクが分析期間の外にあり取りこぼされるのに対し、32日の窓では月末バッチのスパイクを含められることを、時間軸上の負荷グラフと2つの分析窓で対比している。数値はダミーの概念図
図2: 14日 vs 32日ルックバック(概念図)。32日に広げると月末バッチなど月次の負荷を分析期間に含められる

設定はコンソールから行います。Compute Optimizer コンソールの Rightsizing(Preferences 配下)→「Lookback period and metrics」 でルックバック期間を選びます。設定レベルは組織・アカウント・リソースから選べ、コンソールのほか AWS SDK・AWS CLI(put-recommendation-preferences)でも設定できます。UIのラベルは更新される可能性があるため、細かい文言は公式で確認してください。

精度向上の機能はもう一つあります。2026年6月18日の追加で、EBS 推奨で IOPS・スループットのスパイクが見えやすくなりましたVolumeIOPSExceededCheckVolumeThroughputExceededCheck という2つの CloudWatch メトリクスを分析し、プロビジョンド値をどれだけ超過しようとしたかを把握します。Nitro ベースの EC2 インスタンスに接続された EBS では、これらの基礎メトリクスは追加課金なしで利用できます。なお standard(マグネティック)と Multi-Attach 有効ボリュームは対象外で、ECS・Fargate タスクに接続されたボリュームには発行されません

料金の線引き — 「全部無料」と総括しない

料金は誤解しやすい部分なので、正確に分けて押さえます。

  • 本記事で扱う範囲(14日/32日ルックバック、EBS のスパイク可視化)は追加費用なしで使えます。
  • ただし、「Compute Optimizer は全部無料」とは総括できません。別機能の Enhanced infrastructure metrics は、93日(約3か月)のルックバックを提供する有料の拡張で、32日ルックバックとは別物です。長期の季節変動まで見たい場合に検討する有料オプション、という位置づけです。
  • 推奨を**「適用」した先の課金は対象サービス側**で発生します。EBS なら変更後のボリューム料金、Fargate なら変更後のタスク料金です。推奨を表示すること自体(無料)と、推奨を適用した結果のサービス料金は別と考えてください。

なお、削減率(savings)の具体的な数値は環境ごとに異なるため、本記事では断定しません。コンソールに表示される相対値や、各サービスの公式 pricing で確認してください。コスト全体の可視化や調査はCost Explorer を Amazon Q で分析するAWS FinOps Agentが担い、Compute Optimizer はそれらが束ねる「個別リソースの適正容量化」を担う単体ツールという関係です。

推奨が出ない条件 — つまずき先回り

「有効化したのに推奨が出ない」は、要件を満たしていないことが原因のことが多くあります。代表的な条件を押さえておきます。

  • EBS:稼働中のインスタンスに30時間以上、連続してアタッチされている必要があります(メトリクスはアタッチ中のみ CloudWatch に報告されるため)。デタッチすると推奨は消えます。
  • Fargate(ECSサービス):次をすべて満たす必要があります。
    • 直近14日に24時間分の CloudWatch・ECS 利用メトリクスがある。
    • step scaling ポリシーが付いていない
    • CPU とメモリの両方に target scaling ポリシーが付いていない(片方だけ target tracking の場合は、もう一方の次元について推奨が出ます)。
    • サービスの実行ステータスが SteadyState または MoreWork である。

とくに「CPU とメモリの両方に target scaling を設定していると推奨が出ない」点は見落としやすいので、推奨が空のときはオートスケール設定を最初に確認します。

まとめ

Compute Optimizer を使うと、EBS と Fargate の過剰プロビジョニングを推奨(事実)として見つけ、適正容量に直せます。要点は次のとおりです。

  1. 前提を整える:opt-in で有効化し、Cost Explorer を有効化(必須)、Cost Optimization Hub を opt-in(推奨)。分析完了まで最大24時間。
  2. 推奨を読む:EBS は4次元+finding/performance risk、Fargate はタスクの CPU/メモリ+finding で読む。
  3. ルックバックを広げる:既定14日を32日に拡張すると月次パターンに強くなる(追加費用なし)。
  4. 料金を分ける:本記事スコープは追加費用なし、93日の Enhanced infrastructure metrics は有料、適用後はサービス側課金。
  5. 出ない条件を疑う:EBS は30時間連続アタッチ、Fargate は24時間メトリクス・step scaling 無・CPU/メモリ両軸 target scaling 無など。

コストの入口を整理するAWSの請求管理の基本から一歩進めて、個別リソースを推奨で適正容量に直すのが本記事の具体策です。東京リージョンでも利用できますが、コンソールの表示や料金ティアは公式の最新情報をあわせてご確認ください。

出典

For Freelancers

AWSフリーランス案件、お探しですか?

案件探しから単価交渉・契約手続き・参画後のフォローまで、専任コンサルタントが伴走します。 お名前とメールだけで、まずは無料でご相談いただけます。

案件を探す