クラウドの請求額が上がってきたとき、削る前にやること

こういう状況の話です

AWS の請求額が上がってきた。何かを削らないといけないが、どこに手をつけてよいか分からない。

こうした相談で求められることは、たいてい次の2つです。

同じ相談の中で並んで出てきますが、この2つには順番があります。把握が先で、削るのは後です。順番を逆にしたときの失敗が、この記事の後半です。

上がってきた原因は、たいてい次の両方です。

典型的なのは EBS ボリュームと Elastic IP です。単体では目立たない金額ですが、積み上がります。インスタンスを整理しても、それにぶら下がっていたものが残っているケースは珍しくありません。

問題は、この2つが請求書の上では区別できないことです。合計額が上がったという事実だけでは、事業が伸びたのか無駄が積み上がったのか判断できません。だから「高くなったので削ってください」という依頼には、そのままでは応えられません。

作業は通常以下のように進めます。

1. Cost Explorer で現状を把握し、金額の大きいものを確認する

まず全体の内訳を見ます。AWS の場合、上位に来やすいのは EC2・RDS・S3 です。そこに前述の EBS・EIP の積み上がりが乗ってきます。

2. 金額の大きい部分を深掘りし、それが何に使われているか（使われていないか）をリスト化する

ここが本体です。金額の大きい順に、ひとつずつ「これは何に使われているか」を埋めていきます。

3. 削る判断は、そのリストの上で行う

この手順の効き目は、埋まらない項目が浮かび上がることにあります。「何に使われているか説明できない」ものは、削減の候補であると同時に、現状把握が足りていない場所でもあります。相談の入口にあった「どこに何が使われているか把握したい」への答えも、このリストです。

なお、こうした状況は、社内にクラウドの担当者がいない会社で起きやすいものです。その構造については別の記事で書きました。

把握を飛ばして削ると、次のようなことが起きます。いずれも実際に見てきた、あるいは相談を受けて止めたものです。

いちばん手軽に見えて、いちばん危ない削り方です。メモリや CPU が不足し、サービスレベルの低下、最悪の場合は停止につながります。

請求額は確実に下がります。ただ、サービスが落ちればその意味はありません。下げる前に、実際の使用状況を確認する必要があります。

「使っていないから」という理由で真っ先に候補に挙がりがちです。しかし、次にテスト環境が必要になったとき、再構築の手間が削減できたコストを上回る可能性があります。

削る場合でも、すぐに再現可能な形にしてからにします。構成が手順として残っていれば、消しても戻せます。残っていない状態で消すのは、コスト削減ではなく資産の廃棄です。

削減幅が大きく見えるので提案として出やすいのですが、慎重に進めるよう進言しています。理由は3つあります。

3つ目が見落とされがちです。クラウドによっては、ちょうど合っていた機能が無かったり、あっても使いにくくて苦労したりします。移行前の比較表では同等に見えても、実際に運用に入ってから差が出ます。

3つに共通しているのは、削減額は請求書に出るが、代償は請求書に出ないということです。落ちたサービス、作り直しの工数、運用の混乱は、どれもコストの欄には現れません。だから「削減できた」という結論だけが残ります。

当社はコスト削減の割合を約束していません。クラウドの使用量は変動するため、削減幅を簡単には算出できないからです。ある月と比べれば下がっていても、事業の状況が違えば意味のある比較になりません。

約束できるのは、何にいくらかかっていて、そのうちどれが説明できないものかを明らかにすることです。そこから先の判断材料は揃います。

読み終えたあと、社内で確認できることを挙げておきます。

言えない項目が多いようなら、削る前に把握するところから始めたほうが、結果的に早く済みます。