はじめに
EC2まわりは地味に見えて、実は制度の動きが多い領域です。
以前は「リザーブドインスタンス（RI）かオンデマンドか」という二択に近い感覚でしたが、今は Savings Plans を軸に、オンデマンドとスポットを細かい単位で組み合わせる のが標準的な設計になっています。AWS の意思決定ガイドでも RI は「基本的に Savings Plans への置き換えを推奨する旧来のオプション」と明記されるようになりました。
この記事では、AWS 認定試験（CLF〜SAP）で問われる概念整理と、実務でのチューニングポイントの両方を、公式ドキュメントの記述をベースに整理します。
対象読者
- AWS 認定試験でコスト最適化まわりを学習中の方
- 「とりあえず RI 買っておけばいい」で止まっている方
- Savings Plans を買ったが、使用率が伸び悩んでいる方
1. 最初に：「課金の軸」と「容量確保の軸」は別物
ここが実務でも試験でも一番混同されやすいポイントです。
| 軸 | 何を決めるか | 該当するもの |
|---|---|---|
| 購入オプション | 請求金額の計算方法 | オンデマンド / Savings Plans / RI / スポット |
| キャパシティ予約 | 必要なときに枠が確保されているか | On-Demand Capacity Reservation（ODCR） / Capacity Blocks for ML |
この2つは独立していて、実務では重ねて使います。
ODCR は「使っても使わなくてもオンデマンド相当額で課金される」ものであり、それ自体に割引はありません。ただしその請求に対して Savings Plans やリージョン RI の割引を効かせられます。
「予約したのに安くならない」という誤解は、この2軸を1軸で考えていることが原因であることがほとんどです。
なお Capacity Blocks for ML は例外で、Savings Plans / RI の割引と併用できません（単独価格・前払い）。GPU 系では需給次第でオンデマンドより高くなることもあり、「割引の仕組み」ではなく「可用性を買う仕組み」と理解するのが正確です。
2. Savings Plans が軸になった理由
Savings Plans は「$/時間」でのコミットを 1年 または 3年 で行う形式です。EC2 に関係するのは2種類。
| Compute Savings Plans | EC2 Instance Savings Plans | |
|---|---|---|
| 割引率 | 最大 66% | 最大 72% |
| スコープ | リージョン・インスタンスファミリー・OS・テナンシーを問わない | 特定リージョンの特定インスタンスファミリーに限定 |
| 対象サービス | EC2 / Fargate / Lambda | EC2 のみ |
| 向いているケース | アーキテクチャが変化する、新世代インスタンスへ移行する可能性がある | 構成が安定していて、当面ファミリーを変えない |
RI の現在地
RI が依然として意味を持つ場面は、かなり限定的になりました。
- ゾーナル RI のみがキャパシティ予約を伴う（リージョナル RI には容量確保の効果はない）
- Savings Plans の対象外サービス（例：Redshift の Reserved Nodes）
一方、公式ドキュメントには「新しいインスタンスファミリーでは RI 価格が用意されていない場合がある」という記述もあります。新世代を積極的に使う環境ほど、RI は選びにくくなっています。
DB 系も 2025年12月に Database Savings Plans（最大 35%、1年・前払いなし）が登場し、Aurora / RDS / DynamoDB / ElastiCache / DocumentDB / Neptune / Keyspaces / Timestream / DMS が対象に。2026年3月には OpenSearch Service と Neptune Analytics も追加されました。「コミット割引 = Savings Plans」という整理がかなり進んだ形です。
割引の適用順序（地味に重要）
複数のコミットが有効なとき、AWS は次の固定順で割引を適用します。
リザーブドインスタンス → EC2 Instance Savings Plans → Compute Savings Plans
RI と SP を併存させている環境でカバレッジを設計する際は、この順序を前提に考える必要があります。
3. スポットは「割引」ではなく「設計」
スポットは最大 90% オフですが、押さえるべき性質がいくつかあります。
- Savings Plans の割引はスポット利用に適用されない（完全に別建て）
- 中断時は 2分前に通知。既定では終了、設定次第で停止・休止も可能
- 価格は入札制ではなく、長期的な需給トレンドに応じて緩やかに変動
- AWS 都合で最初の 1時間以内に中断された場合、その部分時間は課金されない
効くのは価格ではなくプールの広さ
スポットの実力を決めるのは、キャパシティプール（インスタンスタイプ × AZ の組み合わせ）をどれだけ広く取れるかです。公式ガイドでも「インスタンスの多様化が、最も実装が簡単で、最も効果が大きい」と言い切られています。
割り当て戦略は5種類（Price capacity optimized / Capacity optimized / Capacity Optimized Prioritized / Diversified / Lowest price）ありますが、Lowest price は非推奨と明記されており、原則 price-capacity-optimized を選びます。
Auto Scaling Group での実装例
属性ベースのインスタンス選択（Attribute-Based Instance Selection）を使うと、タイプを列挙せずに「vCPU 4〜8、メモリ 8〜32GiB、x86_64」といった要件で指定でき、新世代が出たら自動的に候補に入ります。
{
"MixedInstancesPolicy": {
"InstancesDistribution": {
"OnDemandBaseCapacity": 2,
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "price-capacity-optimized"
},
"LaunchTemplate": {
"Overrides": [
{
"InstanceRequirements": {
"VCpuCount": { "Min": 4, "Max": 8 },
"MemoryMiB": { "Min": 8192, "Max": 32768 },
"CpuManufacturers": ["intel", "amd"]
}
}
]
}
}
}
OnDemandBaseCapacity でベースラインを確保し、それを超える分をスポットに寄せる、という書き方です。
取りやすい場所を事前に測る
# ワークロード要件に対して、どのリージョン/AZ がスポットを取りやすいかをスコア化
aws ec2 get-spot-placement-scores \
--instance-types m6i.large m6a.large m5.large \
--target-capacity 100 \
--target-capacity-unit-type units \
--region-names ap-northeast-1 ap-northeast-3
中断への備え
- ASG の capacity rebalancing で rebalance recommendation に反応させる
- 長時間ジョブはチェックポイント、タスクは細かく分割（2分以内に終わるタスクは中断の影響を受けない）
- AWS FIS でスポット中断を意図的に発生させ、挙動をテストする
現実的な落としどころ：ハイブリッド
AWS が推しているのはこの形です。
締切を守れるだけのベースラインをオンデマンドまたは Savings Plans で先に確保し、その上にスポットを積んで前倒しする。
スポットが回収されても納期は割れず、取れた分だけ速く安く終わる。バッチ処理やデータ分析ではこの組み方が定番です。
4. 運用ツールは Cost Explorer だけではなくなった
「実使用量に応じて購入オプションを見直す」運用は定着してきましたが、道具立てはこの数年で増えています。
| ツール | 用途 |
|---|---|
| Savings Plans 使用率／カバレッジレポート | コミットを使い切れているか、利用のどれだけがカバーされているか |
| Savings Plans Purchase Analyzer | 「もしこの額でコミットしていたら」を過去実績に対し1時間単位でシミュレーション |
| Cost Optimization Hub | 1年/3年・前払い条件の希望を設定した上で推奨を取得 |
| AWS Compute Optimizer | コミット前のライトサイジング（過剰サイズのまま買わない） |
| EC2 Capacity Manager | 全アカウント・全リージョンのオンデマンド/スポット/予約を一元可視化 |
Purchase Analyzer には、目標カバレッジ率（10〜100%）から必要なコミット額を逆算するモードもあります。既存の Savings Plans によるカバー分を差し引いた「不足分だけ」を出してくれるほか、期限切れ間近のプランを除外した試算や、ルックバック期間の短縮（移行直後・季節変動後の実態に合わせる）も可能です。
EC2 Capacity Manager は 2025年10月に GA。2026年1月には Spot Usage Total Count / Spot Total Interruptions / Spot Interruption Rate といったスポット中断メトリクスが追加され、リージョンや AZ をまたいだ中断傾向の比較ができるようになりました。追加料金なしです。
# 使用率
aws ce get-savings-plans-utilization \
--time-period Start=2026-07-01,End=2026-08-01
# カバレッジ（どれだけの利用がSPでカバーされているか）
aws ce get-savings-plans-coverage \
--time-period Start=2026-07-01,End=2026-08-01 \
--granularity MONTHLY
# 購入推奨
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT \
--lookback-period-in-days SIXTY_DAYS
キャパシティ予約まわりの最近の動き
大規模環境ほど効いてくる変更が続いています。
- 中断可能な ODCR（2025年11月）— 未使用の予約容量を組織内の他ワークロードに一時開放できる。オーナーはいつでも回収可能で、利用側には中断通知が出る
- 将来日付キャパシティ予約のキャンセル対応（2026年6月）— 120日先まで取れる予約をキャンセル可能に。キャンセル料が事前に提示され、CUR 2.0 で追跡できる
- CUR 2.0 での ODCR / Capacity Blocks 可視化（2025年11月）— 予約ごとの利用率・カバレッジが Reserved / Used / Unused でラベル付けされ、時間単位・リソース単位で按分できる
5. 試験ではどこまで問われるか
試験対策としては、あくまで「概念として理解しているか」が問われます。レベル別の温度感は次のような形です。
| レベル | 問われ方 |
|---|---|
| CLF | 各購入オプションの名前と特徴の識別 |
| SAA / SOA | ワークロード特性（中断耐性・予測可能性・可用性要件）と購入オプションのマッピング |
| SAP | Organizations 配下でのコミット共有、RAM による予約共有、ポートフォリオ全体でのコミット設計 |
特に SAP レベルでは「複数アカウント・複数リージョンにまたがる前提」で問われます。個々のワークロードは不安定でも、ポートフォリオ全体では山と谷が相殺されて基準線が安定する（=より大きなコミットが可能になる）という考え方は、押さえておくと選択肢を絞りやすくなります。
おわりに
実務で効いてくるのは、「コミットは一度で決め切るものではない」という感覚だと思っています。
安定した分から順にトランシェを積み上げ、新しいサービスが安定したら上乗せし、1年と3年を確信度で使い分ける。公式ガイドにも同じ趣旨の記述があり、やはりそうかと納得しました。試験では概念、実務ではこの積み上げのチューニング。そこが腕の見せどころだと思います。
数値（66% / 72% / 90% / 35%）はいずれも「最大」表記なので、社内資料に転記する際は「最大」を落とさないほうが安全です。
参考
- Choosing a purchasing option for Amazon EC2（AWS 意思決定ガイド）
- Amazon EC2 billing and purchasing options
- Reserve compute capacity with EC2 On-Demand Capacity Reservations
- Reviewing your Savings Plan purchase analysis
- Announcing Amazon EC2 Capacity Manager
- Amazon EC2 announces interruptible Capacity Reservations
- Announcing Database Savings Plans with up to 35% savings