AWS Savings Plansのコミットメント、いくらが適正か?サイジング問題と、推測に頼らない方法

短い答え

この記事から1つだけ持ち帰るなら、これです。平均的な週でもピークでもなく、恒常的なベースライン——本当に24時間稼働しているコンピューティング——に対してコミットすること。それを説明可能なカバレッジポリシー(支出のどれだけをコミットメントでカバーしたいか、そして超えない上限)に落とし込み、一度の大きな購入ではなく小さなステップでコミットメントを積み増して目標に近づいていくのです。

以下では、なぜそれが正しい答えなのか、なぜ通常のプロセスではそれが難しいのか、そしてスプレッドシートに張り付かずに継続的に運用する方法を説明します。

なぜ「いくら」が本当に難しいのか

まず、混同されがちだが区別すべき2つの言葉から始めましょう。カバレッジと使用率です。

• カバレッジは、対象となるオンデマンド支出のうち、どれだけがコミットメントでカバーされているか。Savings Plans対象のコンピューティングを約80ドル/時で稼働させていて、そのうち60ドル/時がカバーされていれば、カバレッジは75%です。
• 使用率は、購入したコミットメントのうち、実際に使われた割合。70ドル/時をコミットして、マッチする使用量が60ドル/時しか発生しなければ、使用率は約86%。遊休となった14%に対しても、コミット済みレートを払い続けることになります。

ここが厄介なところです。この2つは、どちらかを押し上げると逆方向に動きます。カバレッジを追求すればコミットメントを多く購入することになり、使用量が落ちたときに使用率が下がりやすくなる。使用率を守ろうと控えめに買えば、カバレッジ——つまり節約額——は低いまま。コミットメントのサイジングとは、まさにこのシーソーのどこに座るかを選ぶ行為なのです。多くのチームはこの選択を明示的に行わず、ただ場当たり的に反応しているだけです。

さらに、それぞれ計算を左右するレバーが存在します:

選択項目	選択肢	トレードオフ
期間	1年 vs. 3年	3年は割引が深くなる一方、ロックインされる期間は3倍になります。
支払い方法	前払いなし / 一部前払い / 全額前払い	前払いを増やすとレートはわずかに良くなりますが、キャッシュが拘束され、間違えたときの痛手が大きくなります。
プランの種類	Compute SP vs. EC2 Instance SP	Compute SP(最大約66%オフ)はインスタンスファミリー、サイズ、リージョン、OS、テナンシー、さらにはFargate/Lambdaまで柔軟に対応。EC2 Instance SP(最大約72%オフ)は割引が少し深い代わりに、リージョン内の特定インスタンスファミリーに固定されます。ここでも柔軟性 vs. 割引です。

これらの選択にどれだけの価値があるかは、1つのインスタンスの価格への影響を見ればわかります。同じc6a.8xlargeを同一リージョンで、Compute Savings Planの期間と支払いオプション(およびオンデマンド)ごとに価格比較したものです:

その差は歴然です。同じマシンが、オンデマンドの約1.22ドル/時から、3年のCompute Savings Planでは約0.54ドル/時まで下がります。約56%もの差が、どう買うかだけで決まるのです。しかも差分は均等ではありません。1年から3年に移るとレートはほぼ半減しますが、前払いの選択(なし/一部/全額)は数パーセント動く程度。細則に見えるレバー——期間の長さ——こそが、実際にお金を動かすレバーなのです。

これらの選択はすべて、契約期間全体にわたってworkloadsがどうなるかを知っている前提に立っています。3年・全額前払い・EC2 Instanceプランでは、コミットメントのサイジングをしているのではなく、2028年のアーキテクチャを予言しているのです。これが本当の難しさです。数字を計算するのが難しいのではありません。その数字が依存する未来を知るのが難しいのです。

標的を動かし続ける5つの力

使用量が水平な直線なら、これはスプレッドシートの演習問題で済みます。しかし、そうであった試しはありません。コミットした後も「適正な」数字を引きずり回す、5つの力があります。

1. 使用量は一定ではない。 実際のコンピューティング支出は、バッチジョブ、ローンチ、季節的なトラフィック、大口顧客のオンボーディングなどで週ごとに変動します。好調な週に合わせてサイジングしたコミットメントは、静かな週には過剰コミットメントになります。恒常的なベースラインが実際には60ドル/時なのに、忙しい週に合わせて70ドル/時でサイジングすれば、落ち着いた瞬間から余分な10ドル/時は遊休コミットメントとなり、使っていないキャパシティに年間約87,600ドルを支払うことになります。追い求めていた割引よりも、生み出した無駄のほうが大きいのです。

2. ライトサイジングと移行がベースラインを縮める。 これが最も静かに、最も多くのお金を宙に浮かせる要因です。今日の使用量に合わせてコミットした後、チームは本来の仕事として、過剰プロビジョニングされたインスタンスをライトサイジングし、サービスをGravitonに移し、モノリスをリファクタリングします。使用量は下がり、コミットメントは下がりません。60ドル/時のベースラインにコミットした後、チームがGravitonに移行してベースラインが50ドル/時に落ち着いたとします。一夜にして、約10ドル/時分のコミットメントの行き場がなくなります。3年プランの残り約2年で、およそ17.5万ドルが宙に浮く計算です。エンジニアリングとして正しいことをしたのに、罰を受けたわけです。正しい順序はその逆で、まずライトサイジングし、その後にスリム化された定常状態にコミットすること。しかし、ほとんど誰もそうしません。コミットメントとライトサイジングが、別々のチームのバックログに存在しているからです。

3. コミットメントは失効し、失効は固まってやってくる。 1年前に購入したSavings Planは、特定の日に消滅します。まとめて購入していれば、まとめて失効し、カバレッジは一夜にして急落します。更新にはサイジング作業全体のやり直しが必要で、しかもそれは最も注意が向いていないタイミングでやってきます。見逃せば、失効した分は完全なオンデマンド料金に逆戻りです。

4. カバレッジの目標は使用率という結果を保証しない。 80%のカバレッジを目指していても、購入後に使用量が軟化すれば使用率は低迷します。目標は過去に基づいて設定され、使用率は未来に実現される。その間のギャップは純粋な無駄であり、請求書が届くまで見えません。

5. 時間そのもの。 「十分な確実性」を待つ1日1日が、オンデマンド料金で過ごす1日です。訪れることのない確信を追い求めて何カ月もコミットメントを先送りするチームは多く、先送りした割引は二度と戻ってきません。コミットメントの失敗に関する記事でも述べたとおり、移行中や不確実な状況でも、一部でもコミットするほうが、何もコミットしないより優れています。

これらはどれも計画の失敗ではないことに注目してください。単なる現実です。インフラは変化するのが当然なのです。問題は標的が動くことではなく、ほとんどのコミットメントプロセスが、標的は動かないという前提で作られていることです。

なぜ手動のアプローチは破綻するのか

実際のサイジングは、たいてい次のように行われます。

四半期に一度、誰かがAWSのSavings Plans購入推奨を開きます。AWSは一定期間——7日、30日、最大60日から選択——を振り返り、最大の節約に最適化された時間あたりコミットメント額を1つだけ提示します。誰かがそれを眺め、「念のため」少し割り引き、承認を取り、購入する。

このフローには、3つの問題が組み込まれています。

第一に、単一の振り返り期間から出た単一の数字であること。最大節約の推奨は、直近の過去がそのまま未来であると仮定し、カバレッジを高く押し上げます。使用量が安定していれば素晴らしいですが、そうでなくなった瞬間に高くつきます。

第二に、一括購入であること。四半期分のコミットメント判断を、1日の1回の取引で実行します。その日がたまたま使用量スパイクの頂点だったら、1年分のコミットメントをピークに固定してしまったことになります。

第三に、すでに古いこと。推奨がレビューされ、承認され、購入されるまでに数日から数週間が経ち、使用量は動いています。現在の現実にコミットしているのではなく、すでに過ぎ去った現実のスナップショットにコミットしているのです。

より深い問題は、サイクルの頻度です。使用量は連続的に変化するのに、手動プロセスは四半期ごとにしか動きません。動き続けるシグナルを年に4回サンプリングし、各サンプルに数週間遅れで対応している。スプレッドシートをどれだけ厳密にしても、サンプリングレートの問題は解決できません。

より良いメンタルモデル:ベースラインに合わせてサイジングし、段階的に近づく

解決策は実は2つの別々の仕事に分かれており、名前を付けると理解しやすくなります。サイジング(適正な数字を選ぶこと)とラダリング(そこへ安全にたどり着くこと)です。それぞれの考え方を2つ変えましょう。

変更その1 — サイジング:恒常的なベースラインを基準にする。 これは数字を選ぶ仕事です。「適正なドル金額はいくらか」ではなく、対象支出のどれだけをカバーしたいかを、恒常的なベースライン——24時間稼働している部分——を基準に決め、ドル金額はそこから自然に導き出します。これにより、際限のない推測が、理屈で判断できるポリシーに変わります:

• 保守的(カバレッジ約65%)。 使用率を守り、柔軟性を確保します。意図的に一部の節約を諦めます。変動が大きい、または変化の速い使用量に適しています。
• バランス型(カバレッジ約80%)。 安定した本番workloadsの大半にとってのデフォルト。落ち込みへの十分なバッファを保ちつつ、意味のある節約が得られます。
• 積極的(カバレッジ約90%)。 最大の節約、最小のバッファ。ベースラインが本当に安定していて予測可能な場合にのみ適切です。

では、なぜ常に積極的を選ばないのか?カバレッジには収穫逓減があり、最後の一切れこそが危険だからです。使用量の底、つまり24時間365日稼働している部分はカバーするのが最も安全で、そこでの割引は実質的にタダで手に入るお金です。カバレッジを高く押し上げるほど、使用量の変動する上層部、つまりスパイク時にしか存在しない時間帯に対してコミットし始めます。この限界的な支出こそ最も消えやすい支出であり、約80%を超えて追加するカバレッジは、最も信頼性の低い節約しか生まないのに、過剰コミットメントリスクの大半を抱え込みます。正しい姿勢は「すべてをカバーする」ではありません。「安定した基盤は積極的に、変動する上層部は慎重にカバーする」です。

変更その2 — ラダリング:小さなステップで到達する。 これは別の仕事です。何をコミットするかではなく、どうやってそこに到達するか。1回の大きな購入ではなく、目標までの距離を、時間をかけた小さな段階的コミットメントの連続に分割します。ラダリングは、5つの力のうち複数を同時に解決します:

• 小さく頻繁なステップにより、単一の購入がピークに固定されることがなくなります。投資でドルコスト平均法を使うように、コミットメントを平均化しながら積み上げていくのです。
• 開始日がずれることで失効時期もずれ、更新時の急落がなくなります。プランが一度にではなく、少しずつロールオフしていくからです。
• 段階的にコミットすることで、使用量が軟化した瞬間に停止または減速でき、ロックされた契約の1年後に過剰コミットメントを発見する事態を避けられます。

ただし、この2つの仕事は分けて考えてください。ラダリングが管理するのはタイミング——購入の集中と失効の崖——であって、サイジングではありません。積極的すぎる目標を救うことはできないのです。間違った数字に向かってゆっくり階段を上っても、数週間遅れで過剰コミットに至るだけです。まずベースラインを正しく捉え、その後にラダリングで近づきましょう。

問題はここです。動くベースラインへのサイジング、毎週のカバレッジ確認、失効への調整、下降局面での一時停止は、正真正銘の継続的な仕事です。手作業でやれば、誰も担っていないパートタイムの役割になります。このギャップこそ、自動化が埋めるために作られたものです。