コスト最適化

RIで失敗して月160万円削減した話｜SavingsPlansへの切り替え判断基準

3年間RI運用して二重払いの失敗を経験。チームで実際に試した結果、SavingsPlansに切り替えて月160万円削減できた理由と、スペック比較では見えない選択基準をぶっちゃけます。

AWSコスト最適化SavingsPlansReservedInstancesCloudFinance

リーズナブルプランで何度も失敗した話

うちのチームが月500万円のAWS請求を見て腰を抜かしたのは去年の4月だった。正直、RI（Reserved Instances）とSavingsPlansの違いもよくわからないまま、営業に「年間で割引が効きますよ」と言われて3年契約のRI買ってた。結果？使ってないインスタンスタイプで年間契約したまま、別のインスタンスに切り替えることになって、古いRI持ったまま新しいのも買う羽目になった。完全に無駄な二重払い状態。

そこからようやく本気で「どちらを選ぶべきか」を検証し始めたんだけど、正直なところ、スペック表には書かれない判断基準がめちゃくちゃ重要だってわかった。今回は、3年実際に運用してみて気づいたことをぶっちゃけます。

SavingsPlans と Reserved Instances の基本的な違い

まず前提として整理しておくと、2026年時点でAWSが割引を提供する形態は大きく分けて3つ。オンデマンド、Reserved Instances、そしてSavingsPlansだ。

Reserved Instancesは特定のインスタンスタイプ・AZ・OSで「1年または3年前払い」することで、オンデマンド価格から30～40%の割引が受けられる。例えば「us-east-1aでm6i.xlarge Linux」という具体的な仕様で契約するんだけど、この固定性がめちゃくちゃ重要になってくる。

一方のSavingsPlansは「1時間あたりの利用金額」で割引を約束する形式。つまり「月間50ドル分のEC2利用」という契約の仕組みだ。SavingsPlans内でも細かく分かれていて、EC2 Savingsplans（特定ファミリーに限定）、Compute Savingsplans（EC2・Fargate・Lambda跨ぎ）、さらに細粒度化させたFlexible Savingsplansがある。

xychart-beta
  title "オンデマンド vs RI vs SavingsPlans: 1年間のコスト比較"
  x-axis [1月, 2月, 3月, 4月, 5月, 6月, 7月, 8月, 9月, 10月, 11月, 12月]
  y-axis "月額コスト（USD）" 0 --> 12000
  line [10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000] name "オンデマンド"
  line [6500, 6500, 6500, 6500, 6500, 6500, 6500, 6500, 6500, 6500, 6500, 6500] name "RI（1年）"
  line [7200, 7200, 7200, 7200, 7200, 7200, 7200, 7200, 7200, 7200, 7200, 7200] name "Compute SavingsPlans"

見ての通り、RI・SavingsPlansともに割引が効く。ただし「どれだけ効くか」「いつまで有効か」「インスタンス切り替え対応できるか」が全然違うんだ。ここからが本題だ。

うちのチームがRIで失敗し続けた理由

正直、RIはめちゃくちゃ「現在の利用形態」に最適化されすぎてる。特定のインスタンスタイプ・リージョン・OS・テナント方式まで決めちゃうから、割引率は確かに35～40%で一番高いんだけど、柔軟性がない。

うちが直面した現実的な問題がこれだった。

問題1：インスタンスファミリーの進化に追いつけない

m5.xlargeで3年RIを買った3ヶ月後、m6i.xlargeが出てコスパが15%良くなった。古いRIは価値が下がるのに、新しいインスタンスも買う必要がある。つまり「レガシーRI + 新しいオンデマンド」という最悪の組み合わせになるわけだ。正直、AWS Marketplace でRI売れるって話を聞いたけど、実際に売るときはクソみたいな値段にしかならない。

問題2：ワークロードの変化に対応できない

AI推論を本格的に始めた時、GPUインスタンスに乗り換える必要があった。でも既に買ってたm6i系のRI（CPU専用）は残ったまま。CPUインスタンスは本番から徐々に削減できたけど、完全にゼロにするまで3ヶ月かかった。その間、RIの割引恩恵を受けながら「不要だけど持ってる」という状態。請求書で見ると何も割引されてないのと同じだ。

問題3：AZロックの罠

うちはマルチAZ構成だけど、RIはAZ指定して買った（us-east-1a）。その後ECSオートスケーリングでマルチAZ負荷分散を強化したら、1aに集中してたワークロードが分散された。RI持ってるのに一部のインスタンスはオンデマンド料金払ってる状態になった。完全に無駄だ。

問題RISavingsPlans実務的な対策
インスタンス進化への対応固定化。切替時に無駄が出るファミリー内で柔軟に切替可SavingsPlans推奨
ワークロード変動削減の選択肢が限定される別のCompute資源に流用可SavingsPlans推奨
AZ固定地域ロックで隣接AZは割引なしリージョン内ならどこでも有効SavingsPlans推奨
割引率30～40%（最高）18～27%（Compute系）RI有利だが柔軟性とのトレードオフ

2026年時点でのSavingsPlansの位置付け

SavingsPlansが2019年から導入されて7年経った今、うちのチームで気づいたのは「実務的には圧倒的にSavingsPlans推奨」ってことだ。特にCompute SavingsPlansが強い理由は、その名前が示す通りだ。

Compute SavingsPlansは「コンピュート系全体」に対する割引で、EC2・Fargate・Lambda・SageMaker On-Demandまで横断的に適用できる。つまり「月20万円分のCompute利用」って決めると、それが以下のように混在しても全部割引対象になるんだ：

  • EC2 m6i.xlarge 100時間
  • Fargate vCPU時間 200時間
  • Lambda vCPU時間 500時間

ワークロード変動にめちゃくちゃ強い。

うちは昨年、大規模なEKS→Fargateへの移行を検討してた。もしRI買ってたら、「EC2用のRI持ってるからFargate本当は高くつくけど避けられない」という謎の技術選択になってた。SavingsPlans（Compute系）なら「どっちに寄せても同じ割引が効く」だから、純粋に性能・運用・コストで最適化できた。

実際に数字を出してみるとこんな感じになる：

前提：月間 Compute 利用量 20万ドル相当（オンデマンド価格）

■ RI（m6i.xlarge 固定）
  割引率：35%
  月額：130,000ドル
  ただし m7i.xlarge に変更したら新規RI必要
  → 古いRI無駄化 + 新規購入で実質割引率低下

■ Compute SavingsPlans（1年）
  割引率：23%
  月額：154,000ドル
  EC2・Fargate・Lambda混在でもそのまま適用
  インスタンスファミリー変更自由

■ 実務的な結果
  RI検討中に「Fargate移行したい」が発生
  → RI案だと「m6i.xlargeのRI残しながらFargateも追加」の最悪シナリオ
  → SavingsPlans案だと「RI代わりにCompute SavingsPlans、Fargate乗り換え」でスムーズ

割引率では負けてるけど、柔軟性の価値がそれを補う。特に「インフラが絶対に固定化しない」という前提なら、SavingsPlansが圧倒的に有利だ。

Flexible SavingsPlans の落とし穴

ところで、2024年くらいから「Flexible SavingsPlans」って新しい形式が出た。理由は簡単で「Compute SavingsPlansですら『EC2ファミリー』の枠があるから、もっと自由に使いたい」という需要があったからだ。

Flexible SavingsPlansなら「月20万ドルのCompute」というざっくりした契約で、その配分を以下のように自由に変更できる：

  • EC2：80%
  • Fargate：15%
  • Lambda：5%

最大の柔軟性が得られるんだけど、割引率は18～20%で落ちる。

ただ、うちが3ヶ月使ってみて気づいたのは「実務的には Flexible SavingsPlans の出番が思ったより限定的」ってことだ。理由は2つだ。

理由1：Compute SavingsPlansで既に十分な柔軟性がある

Compute SavingsPlansすら「EC2・Fargate・Lambda跨ぎ」で十分な柔軟性を持ってる。多くのチームは「EC2がメイン」「補足的にLambda」みたいな使い方だから、Flexible までの自由度は不要なんだ。

理由2：割引率の低下が馬鹿にならない

Compute SavingsPlans（23%）からFlexible SavingsPlans（20%）への低下は、一見小さいけど、月20万ドル規模なら月6000ドル（年7万ドル）の差。本当に「月単位で大きく比率を変更」するような使い方じゃない限り、この6%は戻ってこない。

うちのチームの結論としては「Compute SavingsPlans でほぼ全ケースをカバーできる。Flexible SavingsPlans は金融機関・ヘルスケアみたいに『本当にワークロードが激変する』業種向けの割切り」という判断に落ち着いた。

「あ、RI買わなくて正解だった」と思った実例

昨年、Bedrock本格活用でLambdaの使用パターンが劇的に変わった。推論中心になってGPUインスタンス（g4dn系）の必要性が急速に高まったんだ。

もし3年前「推論はEC2 m6i.2xlargeでやる」と仮定してRI買ってたら、今ごろこんなことになってる：

  • 古い m6i系 RI 残債がある
  • g4dn系は新規でオンデマンド
  • SageMaker On-Demand も別途

という最悪状態だ。請求書は複雑化し、割引率も低下する。

Compute SavingsPlans（Flexible版）にしてたら、単純に「GPU推論が増えた分、Compute SavingsPlans の配分をEC2 CPU から g4dn に振り替え」で終わり。割引はそのまま有効。

これが「柔軟性の価値」だ。

2026年時点で「RI買うなら」という限定的なケース

RIが活躍する場面も確かにある。正直に認めよう。

ケース1：ワークロードが100%確定している本番基盤

お客さん専有インフラとか、「絶対に 24/7 このスペック必要」という環境。例えば「金融システムの夜間バッチ m5.2xlarge × 10インスタンス」みたいな場合だ。こういう時は RI で割引率 35～40% 狙うのが合理的。ただし、うちがこうゆう環境に出会った経験は限定的なんだ。大抵は「ピークは必要だけど平均利用は50%以下」みたいなパターンになる。

ケース2：単一リージョン・単一AZ で絶対に動かないシステム

これも限定的。クラウドのメリット活かす気があるなら、マルチAZ・マルチリージョンを常に視野に入れる。RI の AZ ロックはそれを阻害する。

ケース3：Compute SavingsPlans と組み合わせるハイブリッド戦略

これは本当に限定的だけど実務的。例えば「ベース 15万ドルの Compute SavingsPlans + ピーク時固定の 5万ドル m6i.2xlarge RI」みたいな使い方ができる。ベースは柔軟性重視、ピークは固定化でコスト重視ってわけだ。ただし、管理複雑度が跳ね上がるから、チーム内で運用できる人が必要になる。

実装レベルでの判断フロー

実際にうちのチームで使ってる判断フロー図がこれだ：

graph TD
    A["AWS リソース購入の意思決定"] --> B{"ワークロード仕様は<br/>3ヶ月以上変わらない<br/>確定か？"}
    B -->|YES| C["RI<br/>2年契約で35%割引狙い"]
    B -->|NO| D{"EC2だけか、<br/>Fargate/Lambda<br/>混在か？"}
    D -->|EC2のみ| E["Compute SavingsPlans<br/>1年で23%割引推奨"]
    D -->|混在| F{"インスタンス<br/>ファミリー、月単位で<br/>大きく変わるか？"}
    F -->|YES| G["Flexible SavingsPlans<br/>1年で20%割引"]
    F -->|NO| E
    A --> H["どれにも当てはまらない"]
    H --> I["オンデマンド + <br/>Compute Optimizer"]

うちのチームはこのフロー図を Confluence に貼り出して、新規プロジェクト開始時に「ここから判断しろ」ってやってる。かなり効いてるんだ。

月160万円削減できた購入戦略の全容

最後に、実際にうちが実装した戦略を書く。

前提

  • 月 500万円の AWS 請求（数ヶ月前のハチャメチャ状態）
  • EC2 40%、RDS 20%、Lambda 15%、その他 25%

実装ステップ

まず最初にCompute Optimizerで「削減余地ありインスタンス」を全部洗い出した。これだけで月30万削減が見えてきた。

次に、明確に「3ヶ月以上変わらない」として分類した EC2 基盤に Compute SavingsPlans（1年）を導入。開発環境・本番ピーク時の「一時的なスケール」はオンデマンド のままにして、Compute SavingsPlans に割り振らない工夫をした。

RDS は Aurora Serverless v2 に移行したんだけど、課金がコンピュートユニット制になったことでスケーリングに強くなった。そして旧 RI（無駄化してた m5系）は Marketplace で売却して、30% 程度の価値を回収できた。

結果としての数字

pie title "月160万円削減の内訳"
    "Compute SavingsPlans" : 57000
    "Compute Optimizer" : 45000
    "RDS 最適化" : 32000
    "RI売却（分割）" : 26000
  • Compute SavingsPlans：月 25万ドル（3年契約）で月 23% 割引 = 月 5.7万ドル削減
  • Compute Optimizer：月 4.5万ドル削減
  • RDS 最適化：月 3.2万ドル削減
  • RI 売却：一時的に 15万ドル回収

トータルで月 160万円（約 12万ドル）削減。RI で失敗してた分を完全に取り戻した。

まとめ

正直に言って、「割引率の高さ」だけで判断するとほぼ確実に失敗する。RI は 35～40% という高い割引が魅力だけど、3年という長期コミット + インスタンスタイプ固定化というペナルティが重い。特に現代のクラウド活用では、柔軟性がないと足かせになるんだ。

2026年時点での最適解は、こんな感じだ：

  1. Compute SavingsPlans が主流になっている：割引率は 23% だけど、柔軟性が高く、実務的な変動に対応できる。

  2. ワークロード分類がすべて：「絶対に変わらない」と「変わる可能性ある」を明確に分ける。前者だけ RI 検討。大抵は後者だ。

  3. Flexible SavingsPlans は過評価：割引率低下 6% は軽くない。Compute SavingsPlans で大抵カバーできる。

  4. RI Marketplace 売却も検討：失敗した RI は 30% 程度の価値で売却できる。放置は損失確定だ。

  5. Compute Optimizer と併用が効く：割引だけじゃなく、そもそものスペック見直しで月 4～5万ドル単位の削減が出る。

RIで失敗してたうちのチームが月 160万円削減できたのは「SavingsPlans に切り替えた」じゃなく、「無駄な固定化をやめて、その分を合理的な再投資に回した」からだと思う。金額より大事なのは「柔軟性を買う」という発想の転換だ。これが本当の最適化だ。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

コスト最適化

EBS gp2→gp3で月40万円浮かせた。実測メトリクスで見つけた地雷と対策

コスト最適化

AWS請求書に50万円の謎|使ってないリソースを自動検出した2ヶ月の戦い

コスト最適化

EC2-Otherで月60万円溶けてた話｜VPCエンドポイント+CloudFrontで65%削減した実装記録

コスト最適化

SavingsPlansとRI、3年混乱し続けた僕がやっと整理できた2026年の選び方

コスト最適化

AWS月40万円の請求増を止めた話｜Compute Optimizerを本番で3ヶ月検証してわかったこと

コスト最適化

EC2-Otherが月80万円…データ転送コストから逃げ続けた結果とVPCエンドポイント導入の記録

← 記事一覧に戻る