クラウドコスト最適化の盲点：AWSのSP管理に払っている「見えない工数」
TL;DR
- AWSのSavings Plans/RIは最大72%割引だが、「割引を維持するための管理コスト」が見えていない
- OCIのUniversal Creditsは年間総額コミット型。サービス・リージョンを問わず自由に使えるため管理がほぼ不要
- 「安い単価を獲得するコスト」まで含めると、AWSの優位性は思ったより薄い
なぜ管理負荷が問題になるのか
クラウドコストの議論は「割引率が何%か」に集中しがちだ。しかし現場では、もう一つのコストが静かに積み上がっている——割引モデルを最適な状態に保つための人的工数だ。
AWSのSavings Plansを運用していると、こんな場面が繰り返される：
- アーキテクチャを変えたら、既存SPが適用されなくなった
- DBをRDSに移したら、Compute SPが当たらず別途Database SPが必要と判明
- 東京リージョンを追加したら、想定より単価が高くて予算を超えた
- SP期限が切れる前に次の利用予測を立て直す月次タスクが発生している
これらは「AWSを使いこなせていない」のではなく、AWSの設計思想そのものが生み出す運用負荷だ。
1. AWSの割引モデル：細分化が生む複雑性
AWSの割引体系は、複数のレイヤーが積み重なっている。
| モデル | コミット対象 | 最大割引 | 主な制約 |
|---|---|---|---|
| On-Demand | なし | 0% | 基準価格 |
| Reserved Instances (RI) | インスタンスタイプ+リージョン | 72-75% | ファミリー・OS変更不可（Standard）。非推奨化が進行中 |
| Compute Savings Plans | $/hour コミット | 66% | EC2・Fargate・Lambda横断。DBには適用不可 |
| EC2 Instance Savings Plans | $/hour コミット | 72% | リージョン・ファミリー固定 |
| Database Savings Plans | $/hour コミット | 35% | Aurora/RDS/DynamoDB等。2024年新設 |
| Spot Instances | なし | 最大90% | 中断リスクあり。本番常用は困難 |
この表を見て「組み合わせれば最大化できる」と思うのが正しい反応だが、そこに罠がある。
「$/hour コミット」という設計の罠
Savings Plansのコミット単位は 1時間あたりの利用金額（$/hour） だ。未使用分はその時間に消滅する（Use-it-or-lose-it）。
# 月$10,000のCompute SPを契約した場合
平日日中（8h × 22日 = 176h）: $15/hour の高負荷
夜間・休日（残り554h） : $3/hour の低負荷
結果：
- 176h分 → $10コミットを超える $5/hour はOn-Demand課金
- 554h分 → コミットした $10 のうち $7/hour 相当が毎時消滅
ワークロードが均一でない限り、コミット額の「最適点」は常にズレる。低めに設定すれば高い時間帯がOn-Demand、高めに設定すれば低い時間帯が無駄になる。
サービスをまたぐと別のSPが必要になる
さらに管理を複雑にするのが、SPの適用範囲がサービスカテゴリごとに分断されている点だ。
- Compute SPはEC2・Fargate・Lambdaに適用できるが、RDSやDynamoDBには適用できない
- DBコストを最適化するには別途Database SPが必要
- Database SPはエンジンごとに割引率が異なる（Aurora Serverless最大35%、RDSプロビジョンドは最大20%）
アーキテクチャの変更（EC2上の自己管理DBからRDSへの移行など）が、財務上のコミット計画を根本から崩す。技術的に正しい判断が、財務的に「損」になるという逆転が起きる。
リージョンを増やすたびに価格計算が変わる
AWSはリージョンごとに価格が異なる。東京は米国比で+10〜20%、ロンドンはさらに高い。グローバル展開やDR構成を追加するたびに、既存のSP設計を見直す必要が生じる。
2. OCIのUniversal Credits：管理を「年1回」に集約する
OCIの支払いモデルは対照的にシンプルだ。
- Pay-As-You-Go（PAYG）: 従量課金。AWSのOn-Demandと同等
- Annual Universal Credits（UC）: 年間総額をコミット。全サービスを横断して自由に消費できる
UCは「年間デポジット」として機能する。
# 年間コミット $120,000 の場合
1月: $2,000 利用 → プールから引き落とし（残 $118,000）
3月: $10,000 利用 → プールから引き落とし
11月: $25,000 利用 → プールから引き落とし（トラフィック急増）
...
→ 年間合計が $120,000 以内なら、月次の増減は一切問題なし
AWSとの本質的な違いを並べるとこうなる：
| 観点 | AWS Savings Plans | OCI Universal Credits |
|---|---|---|
| コミットの粒度 | $/hour × サービス別 | 年間総額（サービス自由） |
| 未使用分の扱い | 毎時消滅 | 年間プール内で吸収 |
| サービス間の流動性 | SP種別ごとに分断 | 全IaaS/PaaS横断 |
| 超過時の課金 | On-Demand定価 | 契約レートで継続課金（ペナルティなし） |
| リージョン価格差 | あり（最大2倍以上） | グローバル均一価格 |
| 管理タイミング | 月次〜随時 | 年次契約のみ |
「コンピュートをDBに振り替えたい」「新しいリージョンを試したい」「新サービスを使い始めたい」——どれもUCのプールから引き落とすだけで、再交渉も再計算も不要だ。
UCの割引率は非公開
一点補足しておく。OCIのUC割引率はAWSと違い非公開で、コミット額に応じてOracleと個別交渉する。公開されているAWSのSP割引率（66%・72%）と直接数値比較できない点は留意が必要だ。ただし、後述のベースプライスの差を踏まえると、割引率の大小だけで優劣は語れない。
3. ベースプライスの差：割引前から安い
管理負荷の話に加えて、そもそもの定価が違う点も無視できない。
| リソース | OCIの優位性（対AWS） | 備考 |
|---|---|---|
| コンピュート | 30〜50%安価 | Qiita検証記事：AWS m6i.large約12,300円/月 vs OCI E4.Flex約4,200円/月（参照） |
| ブロックストレージ | 最大70%安価 | 高IOPSワークロードで差が顕著 |
| データ転送（エグレス） | 最大80%安価 | OCI: 月10TB無料 / AWS: 月100GB無料 |
「AWSでSPをフル活用した環境」と「OCIのPAYG」を比較した実移行事例でも、コストが約半額になったケースが報告されている（AWS から OCI に移行してコストを約半額にした話 - Qiita）。
つまり、UCの割引が乗る前の定価ベースで既にAWSより安いケースが多い。そこにUC割引が加わるため、「SPで最適化したAWS」と「UCを使ったOCI」の実質差は、割引率の数字差より大きくなりやすい。
4. 管理工数を並べると
最後に、FinOps担当者の日常作業として比較する。
| タスク | AWS（SP/RI運用） | OCI（UC運用） |
|---|---|---|
| 利用予測 | サービス別・リージョン別に月次で実施 | 年間総額の概算のみ |
| コミット調整 | SP満了のたびに再購入判断（年1〜3回 × SP種類数） | 年次更新のみ |
| 未使用監視 | 時間単位で未使用率を追う | 年間プールの消化率のみ |
| アーキテクチャ変更時 | 既存SPとの整合を確認・再設計 | UCから自動的に付け替え。手続き不要 |
| リージョン追加時 | 価格差を計算し直してSP設計を更新 | 均一価格。技術要件だけで判断できる |
| ツール | Cost Explorerは無料。最適化の精度を上げるにはサードパーティ（$500〜$5,000/月）が必要 | OCI Cost Managementで完結 |
まとめ
AWSのSavings Plansは「正しく使えば強力」だが、正しく使い続けるためのコストが発生し続ける。SPの種類・コミット額・適用範囲の管理は、エンジニアリングではなく財務最適化の専門知識を要する作業だ。
OCIのUniversal Creditsはその複雑さを「年間総額を決める」という一点に集約する。割引率の数字ではなく、**「その割引を維持するために何をしなければならないか」**まで含めてコストを見ると、選択肢の景色が変わる。
参考