LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AWS Compute Optimizerとは—MLでrightsizing推奨を出す無料サービス

AWS Compute Optimizerとは、Amazon CloudWatchのメトリクスを機械学習で分析し、EC2・EBS・Lambda等のリソースに対して「ダウンサイズ可能」「アップサイズ推奨」「最適」の判定を自動で提示する無料のAWSサービスです^*1。rightsizing（ライツサイジング）とは、実際の利用状況に合わせてリソースサイズを適正化する取り組みを指します。

AWSのクラウド環境では、初期構築時に「余裕を持たせた」サイズで設計されたリソースが、そのまま放置されるケースが少なくありません。負荷が軽い時間帯や季節を問わず、過剰なインスタンスタイプが動き続けることで、無駄なコストが毎月積み上がります。

Compute Optimizerは、過去の実利用データ（CPU・メモリ・ネットワーク等のCloudWatchメトリクス）を分析し、「このEC2インスタンスはm5.2xlargeから m5.largeに変更できる」といった具体的な推奨を自動で提示します。人が手作業でメトリクスを集計・判断するのではなく、機械学習が継続的にパターンを学習して推奨を生成する点が特徴です。

Compute Optimizerの対象リソース—EC2からNAT Gatewayまで7種類

AWS Compute Optimizerが推奨を生成できるリソースは、2024年時点でEC2・Auto Scaling・EBS・Lambda・ECS on Fargate・RDS・NAT Gatewayの7カテゴリに対応しています^*1。

• EC2インスタンス：インスタンスタイプのダウンサイズ・ファミリー変更（例：M系→T系・Graviton移行）の推奨
• Auto Scalingグループ：スケーリングポリシーに合わせたインスタンスタイプ最適化
• EBSボリューム（Elastic Block Store）：ボリュームタイプ・サイズのダウンサイズ推奨
• Lambda関数：メモリサイズの過剰割り当て検出と適正化推奨
• ECS on Fargate：タスク定義のCPU・メモリ設定の最適化推奨
• RDSインスタンス：DBインスタンスクラスのrightsizing推奨
• NAT Gateway：転送量に基づいた利用状況の分析推奨

Compute Optimizerは基本的に無料で利用できます。ただし、Enhanced Infrastructure Metricsを有効にすると過去3か月分のメトリクスを利用した高精度な推奨が得られますが、その場合はリソース数に応じた追加料金が発生します^*1。

なお、AWS Cost ExplorerのRightsizing推奨とCompute Optimizerは同一のレコメンデーションエンジンを使用しています^*1。Cost Explorerはコスト・節約額の表示が付加されており、金額ベースで判断したい場合に役立ちます。

AWS Trusted Advisorとは—Well-Architectedの観点で運用全般を横断点検

AWS Trusted Advisorとは、AWS Well-Architected Framework（AWSが提唱するクラウド設計のベストプラクティス集）に沿って、アカウントの設定・リソース状態を自動でスキャンし、コスト最適化・セキュリティ・性能・耐障害性・サービス上限という5つの観点から改善点を提示するサービスです^*2。

Compute Optimizerが「リソースのサイズ適正化」に特化しているのに対し、Trusted Advisorは運用全般を横断的に点検します。コスト最適化の推奨だけでなく、セキュリティグループの過剰な開放・IAMポリシーのリスク・サービスクォータの逼迫なども同時に検出できる点が特徴です。

Trusted Advisorのコスト最適化チェックの代表例

コスト最適化カテゴリでは、アイドル状態のEC2インスタンス・未使用のElastic IP・使われていないEBSボリュームといった、無駄なリソースの検出が主な役割です^*2。これらはCompute Optimizerの「サイズダウン推奨」とは異なり、「使われていない・不要なリソース」を特定する検出です。

Trusted Advisorの一部のチェック機能（特にビジネス以上のサポートプランが必要なもの）は、AWSサポートプランのグレードによって利用可能な項目数が異なります。基本チェックはすべてのアカウントで利用できますが、詳細な点検項目へのアクセスにはSupportプランが影響することを把握しておくとよいでしょう。

3サービスの使い分けと月次FinOpsレビューの進め方

FinOps（Financial Operations、クラウドコストの可視化・最適化・ガバナンスを組み合わせた運用手法）において、Compute Optimizer・Trusted Advisor・Cost Explorerは役割が異なります。3つを月次レビューで順に確認するのがAWSやエンジニアコミュニティが推奨する定番の運用サイクルです^*1。

3サービスを順に確認することで、「個別リソースのサイズ」「不要リソースの存在」「コスト全体の流れ」という異なる粒度での点検が揃います。どれか一つだけを使うよりも、組み合わせることで見落としが減ります。

外注で進める場合の具体的な手順—調査から変更確認まで5ステップ

AWSコスト最適化を外注する場合、以下の流れで進めると成果につながりやすくなります。

手順1：現状のコストとCompute Optimizerの推奨をCost Explorerで事前把握する

委託先との打ち合わせ前に、Cost Explorerで直近3か月のサービス別コスト推移を確認しておきましょう。Compute Optimizerでどのリソースに推奨が出ているかの概要も把握しておくと、委託先との対話が具体的になります。「月額のおよその内訳」と「Compute Optimizerで警告が出ているリソース数」の2点を整理しておくだけで十分です。

手順2：対象スコープと変更承認プロセスを事前合意する

委託先に丸投げするのではなく、対象とするAWSアカウント・リージョン・リソースの範囲を最初に決めます。また、「変更実施前に社内担当者が承認する」「本番環境の変更は夜間メンテナンス時間帯に限定する」などの変更管理ルールも合意しておくことが大切です。スコープが曖昧なまま進むと、想定外のリソースに変更が加わるリスクがあります。

手順3：委託先がCompute Optimizer推奨を精査し優先度リストを作成する

Compute Optimizerの推奨はあくまで機械学習による分析結果です。アプリケーションの特性（バースト型の負荷・深夜帯の一時的なスパイク等）によっては、ダウンサイズ推奨に従うと性能影響が生じる場合があります。AWS実績のある委託先が推奨を一つひとつ精査し、「適用可能」「要調査」「適用不可」に仕分けしたリストを作成するステップが実務上重要です。

手順4：影響確認・テスト環境での検証を経て本番変更を実施する

優先度リストの中から「適用可能」と判定したリソースから着手します。本番環境に適用する前に、テスト・ステージング環境で動作確認を行うことで性能劣化リスクを抑えられます。変更後は一定期間CloudWatchアラームを監視し、異常が検出された場合は即時ロールバックできる手順を準備しておきましょう。

手順5：Trusted Advisorの点検結果を月次レポートで受け取る

Compute Optimizerのrightsizingと並行して、Trusted Advisorのコスト最適化チェック結果を月次でレポートしてもらう体制を整えます。アイドル状態のリソース・未使用のElastic IPなどは定期的に発生するため、月次の棚卸しを習慣化することが長期的なコスト管理につながります。

内製と外注の比較—必要スキルとリスク管理の違い

Compute Optimizer・Trusted Advisorを活用したコスト最適化を内製で進めるか外注するかは、社内のAWSスキルセットと変更管理体制によって判断が変わります。

内製で推奨を適用する場合に必要なスキルと工数

内製でCompute Optimizerの推奨を適用するには、EC2インスタンスファミリーの特性（M系・C系・T系・Graviton等）を理解したうえで、アプリケーションの負荷特性と照合できる知識が必要です。CloudWatchメトリクスの読み方・Auto Scalingの挙動・EBSのIOPS特性なども把握していなければ、推奨の精査が難しくなります。

作業工数の観点では、複数リソースの推奨を精査し、テスト環境での検証・本番適用まで行う場合、専任エンジニアが並行して調査・変更管理を担う体制が実務上必要になります。兼務で対応する場合は着手が後回しになり、コスト削減の機会が先送りされがちです。

推奨を誤って適用した場合の影響も考慮が必要です。ECSタスクのメモリ設定を過度にダウンサイズすると、高負荷時にOOM（Out of Memory）が発生しタスクが停止します。Lambda関数のメモリ削減では実行タイムアウトのリスクも生じます。本番環境への影響が出た場合の復旧対応は、変更作業そのものより工数がかかる場合があります。

注意点—推奨の鵜呑み適用と性能影響リスクへの対処

Compute OptimizerとTrusted Advisorの推奨を活用する際に、実務上見落とされやすいリスクがあります。

Compute Optimizerの推奨はアプリ特性を完全には反映しない

Compute Optimizerの分析はCloudWatchメトリクスをベースにしています。そのため、定期的なバースト（月次バッチ処理・キャンペーン時の突発的なアクセス増）があるシステムでは、過去の平均負荷だけを見るとダウンサイズ推奨が出やすくなります。推奨をそのまま適用すると、バースト時に処理能力が不足するリスクがあります。

Enhanced Infrastructure Metricsを有効化して過去3か月の詳細データを分析に使う方法や、負荷テストを実施して推奨後のサイズでの動作を事前確認する方法が、リスクを下げる実務的なアプローチです。

Trusted Advisorの「アイドルリソース」検出にも確認作業が必要

Trusted Advisorがアイドル状態と判定したEC2インスタンスであっても、実際には「常時低負荷で動き続けることが設計上の意図」であるケース（監視エージェント・ジャンプサーバー・待機系サーバー等）があります。検出結果を機械的に削除対象にするのではなく、リソースの用途を確認してから判断することが大切です。

変更後の監視体制を整えてから本番適用する

インスタンスタイプ変更・EBSボリュームタイプ変更は、適用直後にCPU・メモリ・ディスクのメトリクスを通常より高頻度でモニタリングできる体制が必要です。CloudWatchアラームのしきい値を事前に設定し、異常が検知された場合に即時通知される仕組みを整えたうえで変更作業を実施することをお勧めします。

まとめ—Compute Optimizer/Trusted Advisorコスト最適化の3つの判断軸

本稿では、AWS Compute OptimizerとTrusted Advisorの役割・対象リソース・3サービスの使い分け・外注で進める手順・注意点を整理しました。要点を3つに集約すると次の通りです。

第一に、Compute Optimizerはリソースのrightsiizng推奨に特化し、Trusted Advisorは運用全般の横断点検を担います。2つは補完関係にあり、Cost Explorerと組み合わせた月次レビューが FinOps運用の定番サイクルです。

第二に、Compute Optimizerの推奨は機械学習による分析結果であり、アプリケーションの負荷特性を考慮した精査が必要です。推奨を鵜呑みにすると性能影響リスクがあるため、テスト環境での検証と変更管理プロセスのセットが実務上不可欠です。

第三に、AWS実績のある外注先に委ねることで、推奨の精査・テスト検証・変更管理を一貫して任せられます。外注時は元請（プライムベンダー）体制・月次レポートの提供・変更承認フローの整備を確認することが大切です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「AWS Compute Optimizer」（AWS公式）
2. *2　出典：Amazon Web Services「AWS Trusted Advisor best practice checks – Cost optimization」（AWS公式ドキュメント）

Tweet