AWS Savings Plans（SP）は「使うだけで自動的に割引が乗る」印象が強く、導入したまま放置されているケースをよく見かけます。しかし実際にコスト明細を読み解くと、SPのカバレッジ・利用率が想定より低く、割引効果を取りこぼしている企業は少なくありません。この記事では、SP運用でよくある3つの盲点と、その確認方法をまとめます。

盲点1: インスタンスファミリー変更でカバレッジが崩れる

Compute Savings Plansは柔軟性が高い一方、EC2 Instance Savings Plansはインスタンスファミリー・リージョンを固定してコミットします。オートスケーリングやコンテナ移行でインスタンスファミリーを変更すると、既存のSPコミットメントが新しいインスタンスに適用されず、オンデマンド料金で課金され続けることがあります。

確認方法: Cost Explorerの「Savings Plans utilization report」で、カバレッジ率が95%を下回っていないか月次で確認する。急激な低下があれば、直近のインフラ変更（インスタンスタイプ変更、リージョン移行、Graviton移行など）と照合する。

盲点2: コミットメント期間中のオンデマンド価格改定リスク

SPは1年または3年の時間単位コミットメントです。コミット後にAWSがオンデマンド価格を引き下げた場合、SPの割引率（オンデマンド比）が実質的に目減りします。逆に言えば、値下げ前の古いSPを大量に抱えたまま更新していないと、本来得られるはずの割引が薄まっていきます。

確認方法: SPの購入日とAWSの価格改定履歴を突き合わせ、更新のタイミングで再計算する。特に3年コミットは値下げの影響を受けやすいため、1年コミット中心での運用も選択肢に入れる。

盲点3: Reserved Instances(RI)との二重最適化ミス

SPとRIを併用している場合、AWSの適用優先順位（Zonal RI → Regional RI → SP）を理解せずに購入すると、片方が遊休化してしまうことがあります。特にRIの自動更新設定を放置していると、SP導入後もRIが重複して残り続け、トータルのカバレッジ効率が下がります。

確認方法: RIとSPの適用範囲が重複していないか、Cost Explorerの「Coverage」タブでワークロード単位に確認する。RIの残存期間が近いものから統合を検討する。

まとめ

Savings Plansは「買ったら終わり」ではなく、インフラの変化に合わせて継続的にモニタリングしないと期待した削減効果が得られません。特に成長中の企業ほどインスタンス構成の変更頻度が高く、盲点1・3の影響を受けやすい傾向にあります。