AWS はじめの一歩
コスト戦略

コンピュートリソース最適化 - AWS Compute Optimizer による適正サイジング

AWS Compute Optimizer を使ったリソースの適正サイジングを解説。EC2 ・ Lambda ・ EBS ・ ECS on Fargate ・ Aurora / RDS の推奨事項、コスト削減効果の試算、導入手順を紹介します。

約 4 分で読めます執筆 / 編集: あわしろ

リソースの適正サイジングの重要性

クラウドリソースの過剰プロビジョニングは、代表的なコスト無駄の原因です。本番環境で m5.xlarge を使用しているが実際の CPU 使用率は平均 10% 以下、Lambda 関数に 1024 MB のメモリを割り当てているが実際の使用量は 200 MB 以下、gp2 ボリュームを使い続けているが gp3 に変更すれば 20% コスト削減できる、といったケースは非常に多く見られます。AWS Compute Optimizer は CloudWatch メトリクスを ML モデルで分析し、各リソースの最適な設定を推奨するサービスです。過去 14 日間 (拡張メトリクスでは最大 93 日間) の使用パターンを分析し、パフォーマンスを維持しながらコストを最適化する推奨事項を提示します。分析対象は単一のメトリクスではなく、CPU 使用率・ネットワーク入出力・ディスク I/O ・EBS ボリュームの読み書きなど複数のメトリクスで、CloudWatch エージェントを導入した EC2 インスタンスではメモリ使用率も分析対象に加わります (公式ドキュメント記載・2026 年 8 月時点)。

EC2 と Lambda の推奨事項

EC2 インスタンスの推奨では、現在のインスタンスタイプに対して最大 3 つの推奨オプションが提示されます。各オプションにはインスタンスタイプ、推定月額コスト、パフォーマンスリスク (Low/Medium/High) が含まれます。たとえば m5.xlarge (4 vCPU / 16 GB) を使用中で CPU 使用率が低い場合、m5.large (2 vCPU / 8 GB) へのダウンサイジングや、m7g.large (Graviton3) への移行が推奨されます。Graviton への移行推奨は Compute Optimizer の特徴的な機能で、ARM アーキテクチャへの移行によるコスト削減効果を具体的な金額で提示します。Lambda 関数の推奨では、メモリサイズの最適値を提示します。Lambda はメモリに比例して CPU が割り当てられるため、メモリの最適化はコストとパフォーマンスの両方に影響します。過剰なメモリ割り当ては直接的なコスト無駄になり、不足は実行時間の延長 (= コスト増) につながります。

# Compute Optimizer の有効化
aws compute-optimizer update-enrollment-status \
  --status Active \
  --region ap-northeast-1

# EC2 推奨事項の取得
aws compute-optimizer get-ec2-instance-recommendations \
  --region ap-northeast-1 \
  --query 'instanceRecommendations[].{Id:instanceArn,Finding:finding,Current:currentInstanceType,Recommended:recommendationOptions[0].instanceType}'

EBS と ECS の推奨事項

EBS ボリュームの推奨では、ボリュームタイプ、サイズ、 IOPS 、スループットの最適値を提示します。代表的な推奨は gp2 から gp3 への移行です。 gp3 は gp2 と比較してベースラインで 20% 低コストであり、 IOPS とスループットを独立して設定できるため、ワークロードに合わせた最適化が可能です。プロビジョンド IOPS (io1/io2) ボリュームでは、実際の IOPS 使用率に基づいて IOPS 値の削減を推奨する場合があります。 ECS on Fargate の推奨では、タスク定義の CPU とメモリの最適値を提示します。 Fargate のタスクサイズは CPU とメモリの組み合わせで決まり、CPU は 0.25 vCPU (256 CPU ユニット) から 16 vCPU まで段階的に選べ、段階ごとに選択できるメモリは 1 vCPU なら 2 〜 8 GB 、4 vCPU なら 8 〜 30 GB 、16 vCPU なら 32 〜 120 GB という対応です。ただし OS で選べる範囲は異なり、Windows コンテナは 1 〜 4 vCPU に限られます。0.25 / 0.5 vCPU と 8 vCPU 以上は Linux 専用で、Linux ではさらに 32 vCPU / 244 GB までの構成も選択できます (公式ドキュメント記載値・2026 年 8 月時点)。 CPU とメモリの両方が課金対象になるため、適正サイジングがコストに直結します。 Compute Optimizer は各タスクの実際のリソース使用率を分析し、パフォーマンスを維持しながらコストを最小化する設定を推奨します。

導入と Organizations 統合

Compute Optimizer の有効化はアカウント単位で行い、有効化するとメトリクスの分析が始まります。公式ドキュメントでは分析の完了まで最大 24 時間かかると案内されています (2026 年 8 月時点の記載値)。基本機能では CloudWatch のメトリクスを使用して過去 14 日間のデータを分析し、最大使用率のサンプリング間隔は 5 分 (ECS services on Fargate は 1 分) です。有料オプションの拡張インフラストラクチャメトリクス (Enhanced Infrastructure Metrics) は、この分析期間を最大 93 日間まで延長する機能で、対象は EC2 インスタンス・EC2 Auto Scaling グループ内のインスタンス・RDS DB インスタンスです。メモリ使用率の分析は有料オプションではなく、CloudWatch エージェントを導入したインスタンス (Linux は CWAgent 名前空間の mem_used_percent 、Windows は Available MBytes) であれば基本機能でも分析対象になります。ただしエージェントが送信するカスタムメトリクスには CloudWatch 側の料金がかかります。また、推奨事項に推定コストや削減額を表示するには Cost Explorer の有効化が必要です。Organizations 統合により、管理アカウントから組織内の全アカウントの Compute Optimizer を一括で有効化し、推奨事項を集約できます。推奨事項は S3 にエクスポートでき、Athena や QuickSight で組織全体のコスト最適化レポートを作成できます。

Compute Optimizer の料金

以下の料金は 2026 年 8 月時点のバージニア北部および東京リージョンの値で、両リージョンで単価は同一です。Compute Optimizer 自体には追加料金がなく、推奨事項の生成と参照は無料で利用できます。無料で推奨が得られる対象には EC2 インスタンス、EC2 Auto Scaling グループ、EBS ボリューム、Lambda 関数、ECS services on Fargate などがあり、Aurora ・ RDS のデータベースや商用ソフトウェアライセンスも対象です (対象リソースの最新の一覧は公式ドキュメントを参照)。課金される軸は拡張インフラストラクチャメトリクス (Enhanced Infrastructure Metrics) の 1 つだけで、公式料金表では EC2 向けと RDS 向けの 2 行に分かれていますが単価は同じ、リソース 1 台あたり 1 時間 0.0003360215 USD です。課金対象はその月にリソースが稼働した時間数で、31 日 (744 時間) 常時稼働したリソース 1 台なら月約 0.25 USD になります。EC2 Auto Scaling グループは例外で、グループ単位ではなく稼働している EC2 インスタンスの台数分が課金されます。これとは別に、対象リソース自体の利用料金と、分析の元になる CloudWatch のモニタリング料金 (メモリ使用率のためにエージェントが送るカスタムメトリクスなど) は発生します。適正化による削減額はワークロードの過剰プロビジョニングの度合いで大きく変わるため、推奨事項に表示される推定削減額で個別に確認します。

まとめ - Compute Optimizer の活用指針

AWS Compute Optimizer は、ML ベースの分析で EC2 ・ Lambda ・ EBS ・ ECS on Fargate ・ Aurora / RDS の適正サイジングを推奨するサービスです。サービス自体に追加料金はなく、有効化するだけで推奨事項が自動生成されます。過剰プロビジョニングの検出によるコスト削減と、不足の検出によるパフォーマンス改善の両面で効果を発揮します。Trusted Advisor のコスト最適化チェックと組み合わせることで、リソースレベルの最適化 (Compute Optimizer) とアカウントレベルの最適化 (Trusted Advisor) を包括的にカバーできます。全 AWS アカウントで有効化することを推奨します。

参考資料 (AWS 公式)

本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。

本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。

関連するサービス

AWS Compute Optimizer 専門ML でリソースの使用状況を分析し、最適なインスタンスタイプやサイズを推奨するサービスAmazon EC2 定番クラウド上で仮想サーバーを提供するコンピュートサービスAWS Lambda 定番サーバー管理不要でコードを実行するサーバーレスコンピュートサービス

関連する記事

AWS Compute Optimizer で実現するリソース最適化 - インスタンスのライトサイジングCloudWatch メトリクスを ML で分析し、EC2・Lambda・EBS・ECS Fargate のリソースサイズを最適化する推奨を生成する。Graviton 移行推奨と拡張メトリクスによる精度向上の活用法を解説します。Amazon EFS で構築する共有ファイルストレージ - Lambda ・ ECS ・ EC2 からのマウントと設計指針パフォーマンスモードとスループットモードの選定基準を明確にし、ライフサイクル管理による IA 階層への自動移行でコストを最適化する手法を紹介します。Amazon API Gateway の設計パターン - REST API と HTTP API の選定基準HTTP API と REST API の選定基準を明確にし、Cognito・Lambda オーソライザーの認証パターンとスロットリング設計の実践手法を紹介します。

同じテーマの記事

AWS の料金計算の裏側 - 1 秒課金・100ms 課金・リクエスト課金はどう計測されているのかEC2 の 1 秒課金、Lambda の 1ms 課金、S3 のリクエスト課金など、AWS の多様な課金粒度がどのように計測・集計・請求されているのかを、メータリングシステムの仕組みから解説します。AWS の 90% はお客様の声から生まれる - Working Backwards と顧客起点のイノベーションWorking Backwards プロセスと Customer Obsession の原則が AWS のサービス開発をどう形作っているかを解説。PR/FAQ ドキュメントから始まるイノベーションの仕組みと、顧客フィードバックの反映プロセスを紹介します。AWS の値下げの文化 - 2006 年以来 100 回以上の値下げを支えるフライホイールと規模の経済スケールメリットを顧客に還元する AWS の値下げ文化と、その背景にある規模の経済・ハードウェア世代交代・競争戦略を分析する。過去の主要な値下げ事例とその影響を紹介します。AWS の料金モデルはなぜ複雑なのか - 従量課金の裏にある経済学とゲーム理論オンデマンド、リザーブドインスタンス、スポットインスタンスという 3 層の料金構造を、航空業界のイールドマネジメントや需要予測の経済学から読み解き、料金の複雑さの合理的な理由を解説します。AWS Budgets で実現するコスト管理 - 予算アラートと自動アクション実績値と予測値の両方にアラートを設定し、Budget Actions で IAM ポリシー適用やインスタンス停止を自動実行する。Slack 連携でチーム全体のコスト意識を高めます。クラウドコスト予算管理 - AWS Budgets による支出制御とアラートAWS Budgets を使った予算設定・コストアラート・自動アクションを解説。Cost Explorer との使い分け、予算タイプの選択、Organizations 統合による組織全体の予算管理を紹介します。CloudWatch Logs の料金が想定外に高くなる理由 - 取り込み・保存・分析のコスト構造CloudWatch Logs の取り込み料金が保存料金の 20 倍以上である料金構造、VPC フローログや Lambda ログが引き起こすコスト爆発、Infrequent Access クラスや S3 エクスポートによる最適化戦略を解説します。AWS Compute Optimizer で実現するリソース最適化 - インスタンスのライトサイジングCloudWatch メトリクスを ML で分析し、EC2・Lambda・EBS・ECS Fargate のリソースサイズを最適化する推奨を生成する。Graviton 移行推奨と拡張メトリクスによる精度向上の活用法を解説します。

内容が近い記事 / サービス

AWS Compute Optimizer機械学習で CloudWatch メトリクスを分析し、EC2・EBS・Lambda・ECS のリソースサイズを最適化する推奨を提示するサービスAWS Compute Optimizer で実現するリソース最適化 - インスタンスのライトサイジングCloudWatch メトリクスを ML で分析し、EC2・Lambda・EBS・ECS Fargate のリソースサイズを最適化する推奨を生成する。Graviton 移行推奨と拡張メトリクスによる精度向上の活用法を解説します。AWS コスト管理ツール群 - Cost Explorer・Budgets・Compute Optimizer のネイティブ統合AWS は Cost Explorer、Budgets、Compute Optimizer、Trusted Advisor といったコスト管理ツールをネイティブに統合しています。Azure Cost Management や GCP の課金管理と比較し、AWS のコスト可視化と最適化の優位性を分析します。ECS on Fargate のコスト構造を分解する - Spot・ARM・スケーリングの実践的な組み合わせECS on Fargate の料金体系を CPU・メモリ・ストレージの 3 軸で分解し、Fargate Spot、Graviton (ARM)、Service Auto Scaling を組み合わせたコスト最適化の実践手法を解説します。