はじめに
こんにちは、クロスインダストリー第2本部 クラウド活用推進課の岡野です。
私は普段から既存のお客様を中心に、AWSにおけるカスタマーサクセスを叶えるべく、クラウドの利活用を推進しております。
以下のようなご相談をよくお客様からいただくことがあります。
お客様「コストの最適化って、まずは1年か3年か前払いする、RI？SP？を買えばいいんだよね？？」
岡野「いえ、実はですね……」
今日はそんなご質問に回答するべく、AWSコスト最適化の「正しい順序」について記載します。 AWSの利用料が急増した際、「まずは安くするためにReserved Instance (RI) や Savings Plans (SPs) を買おう」と考える方は少なくありません 。 しかし、カスタマーサクセスとして多くの現場を見てきた経験から断言できるのは、「順序を間違えたコスト最適化は、逆に負債を生む」 という事実です。
- はじめに
- コスト最適化における「よくある勘違い」
- 鉄則：コスト最適化の「4 つの手順」
- なぜ「スペック見直し」が先なのか？
- 自動化で稼働時間を削り、分母を減らす
- まとめ：RI/SPsは「最後の奥の手」
本記事では、個別セミナーでも反響の大きかった「コスト最適化 4 つの手法」をベースに、プロフェッショナルが実践する技術的選定ロジックを深掘りします 。
コスト最適化における「よくある勘違い」
「前払いすれば安くなるんでしょ？」と、いきなり長期コミットメント（RI/SPs）に走るのは、いわば「穴の空いたバケツに水を注ぎ足す」ようなものです 。 RI/SPsは強力な割引が得られますが、一度購入すると1年または3年の支払い義務が生じてしまいます 。そのため、「本来不要なリソース」や「過剰なスペック」に対してコミットしてしまうことこそが、最大のコストリスクとなります 。
鉄則：コスト最適化の「4 つの手順」
AWSドキュメントや弊社のこれまでの経験・実績に基づき、以下の順序で検討することを強く推奨しています 。
- 利用していないリソースを洗い出し、削除する
- 利用中リソースのスペックを見直す（ライトサイジング）
- 利用中リソースの稼働時間を見直す
- 常時稼働が確定したリソースに対して購入オプション（RI/SPs）を適用する
なぜ「スペック見直し」が先なのか？
RIやSPsは「最後の奥の手」であり、最初に行うべきではありません。なぜなら、過剰なスペックに対して長期契約（コミットメント）をしてしまうと、後から構成を変更しても支払い義務だけが残る「無駄の固定化」を招くリスクがあるからです。
「①器（スペック）を最小化する → ②時間を絞る → ③最後に確定分だけを安く買う」という順序を守ることが、クラウドコスト最適化の鉄則です。
AWS Compute Optimizer：まずはツールで「無駄」のアタリをつける
スペック選定には、AWS Compute Optimizer を活用します。ここで注意すべきは、ツールのデフォルト設定です。標準では非常に保守的な判定（P99.5：一瞬のスパイクも逃さない設定）を行うため、なかなか削減案が出ないことがあります。
そこで、「ライツサイジングの推奨事項の設定」から、しきい値を「P95（バランス）*1」に変更することを検討してください。これにより、突発的なノイズを除外した「実効的な負荷」に基づいた、より踏み込んだ削減案を得ることが可能になります。
コスト最適化シミュレーション：設定変更 ＋ 検証
| 項目 | ケースA：さらなるコスト削減の深掘り | ケースB：最新世代へのアーキテクチャ刷新 |
|---|---|---|
| 対象リソース | EC2 インスタンス (m5.large等) | EC2 インスタンス (c5.xlarge等) |
| 推奨設定の変更 | [バランス] (P95) 設定へ変更 | [デフォルト] または [パフォーマンス重視] |
| プロの視点 (CloudWatch) | P95グラフで実効負荷が低いことを確認 | 負荷は適正だが、世代が古く効率が悪い |
| 推奨アクション | さらなるスケールダウン (t3.medium等) | 最新世代・他ファミリーへの変更 (c6i / c7g等) |
| 活用サービス | Compute Optimizer ＋ CloudWatch | Trusted Advisor ＋ Compute Optimizer |
| 想定削減率 | 最大 約72% (RI/SPs適用時) | パフォーマンス向上を伴うコスト削減 |
推奨設定を「P95」へカスタマイズする
Compute Optimizer の 「ライツサイジングの推奨事項の設定（Rightsizing recommendation preferences）」 機能を使うと、AIが分析に使うしきい値を変更できます。
- デフォルト（P99.5）： ほとんど全てのスパイクを考慮するため、推奨が保守的になりがちです。
- バランス（P95）： 上位 5% の突発的なスパイクを除外して分析します。これにより、非本番環境やスパイク耐性のあるシステムでは、より踏み込んだコスト削減案が提示されるようになります。
このように、「ビジネス要件に合わせて分析のしきい値を自ら調整する」 ことも検討されてください。
Compute Optimizer のこちらの機能について詳細を記載している弊社のブログもございますので、合わせてご確認ください。
【実践】CloudWatch で P95 の根拠を裏付ける手順
設定を P95 に変更して Compute Optimizer が出した推奨が「本当に妥当か」を、最後は自分の目で CloudWatch の生データを見て確認しましょう。
- CloudWatch コンソールから、対象インスタンスの [CPUUtilization] を表示します。
- 上部の [グラフ化したメトリクス] タブを選択します。
- [統計] カラムで [カスタム] ＞ 「p95」 を入力し、適用します。
これで、ツールが分析のベースにした「上位5%の異常値を除いた、実質的な最大負荷」を視覚的に確認できます。
判断基準
- P95 と最大値（Max）の差が激しい場合： 1日のうち数分だけ負荷が跳ね上がっています。この場合はサイズを下げすぎず、バースト機能（一時的なパワーアップ）を持つ T系インスタンス への変更が技術的に最も効率的です。
自動ツールの設定を最適化しつつ、自らデータで裏付けを取る。この Analyze（分析）→ Apply（適用） のプロセスを回すことで、無駄な支払いを徹底的に防ぐことができます。
自動化で稼働時間を削り、分母を減らす
さらに、検証環境やステージング環境においては、24時間365日の稼働自体を疑うべきかもしれません。 第3ステップの「稼働時間見直し」において、弊社が開発しているSaaSツールの Cloud Automator の活用は非常に有効です。AWS標準機能でも自動停止は可能ですが、日本の祝日対応や、非エンジニアでも操作できる直感的なGUIを活用することで、「開発者が運用スクリプトを維持管理する工数（人件費）」という隠れたコストまで最適化できるからです。
少し営業トークになってしまいますが、サーバーワークスのAWS請求代行アドバンスドをご利用いただいているお客様は無償で「Cloud Automator」が利用し放題となっています。 有償契約も可能でございますのでご興味がございましたら公式サイトをご参照ください。
Cloud Automator で「運用コスト」も最適化する
インスタンスの夜間・休日停止には Cloud Automator を活用します。AWS標準の Instance Scheduler 等と比較して、「日本の祝日」への対応や、エンジニア以外の事務担当者でも操作できる 直感的なGUI を備えている点が大きなメリットです。
これにより、開発者がスクリプトをメンテナンスする「人件費（見えないコスト）」を削減でき、真の意味での全体最適化が実現します。
「停止できる時間は止める」という運用を徹底した上で、それでも残った「常時稼働分」こそが、RI/SPsを適用すべき領域です 。
まとめ：RI/SPsは「最後の奥の手」
なぜ RI / SPs は「最後」の奥の手なのか？
ここで最も避けるべきは、「過剰なスペックに対して、長期の支払い約束（コミットメント）をしてしまうこと」 です。
例えば、m5.large に対して RI を 1 年契約した後に、「実は t3.medium で十分だった」と判明しても、契約期間中の支払いは止まりません。
「①器（スペック）を最小化する → ②時間を絞る → ③最後に残った確定分だけを安く買う」。
この順序を守ることが、余剰コストを生まないための唯一の正解です。
コスト最適化のゴールは、単に単価を下げることではなく、「ビジネス価値を生まない支出をゼロにする」 ことにあります。
まずは AWS Trusted Advisor や Compute Optimizer で無駄を可視化しましょう
次に、自動化ツールで稼働時間を最適化しましょう
最後に、残ったリソースに対して Savings Plans で長期的な割引を確保してください
*1:P95（95パーセンタイル） : 上位5%の突発的な負荷を除外した統計値
岡野 雄飛（Yuhi Okano）(執筆記事の一覧)
クロスインダストリー第2本部
クラウド活用推進課 課長
IT企業歴12年目。好きなAWSサービスはIAM。
AWS認定資格 CLF SAA SOA DVA SAP DOP AIF
