AWS コストを「前月比」で語るときにハマる罠

「先月よりコストが N% 増えた／減った」── コスト管理でよく使うこの比較、
実は素朴にやると 構成変更がなくても増減して見える ことがあります。

毎月のコスト比較レポートを自動化する過程で踏んだ「罠」を、備忘録として残しておきます。
結論だけ先に言うと、月の日数差とコストメトリクスの選び方の 2 つを押さえれば、大半の誤読は防げます。

罠その1：月の日数差（28日 vs 31日）

一番やりがちなのがこれです。

たとえば RDS や NAT Gateway のような 時間課金（稼働時間に比例） のサービスは、
構成を一切変えていなくても、

• 4 月（30 日）→ 5 月（31 日）：+3.3% 増えて見える
• 1 月（31 日）→ 2 月（28 日）：約 -10% 減って見える

これは単純に「課金対象の時間が増減しただけ」で、実質的なコスト変化ではありません。

実際、コスト比較レポートで「RDS が前月比で最大の増加要因」と出たことがありましたが、
内訳を見ると 増加分のほとんどが日数差（5月が31日・4月が30日） で、構成は変わっていませんでした。

対策：日割りで見る、または日数で補正する

月額をそのまま比較するのではなく…

  日割りコスト = 月額 / その月の日数

で比べると、稼働時間課金分のノイズが消える。

「月額は増えているが、日割りで見るとほぼ横ばい」というのは、コスト分析で頻出のパターンです。
増減を語る前に、まず日数差で説明がつかないかを疑うクセをつけておくと安全です。

罠その2：どのコストメトリクスで見るか

Cost Explorer には複数のコストメトリクスがあり、どれを選ぶかで数字も意味も変わります。

メトリクス	何を表すか	向いている用途
UnblendedCost	実際に課金された額そのまま	請求額の説明、月次の実支払い
AmortizedCost	RI / SP の前払いを期間按分した額	ランニングコストの実態把握
BlendedCost	組織内で平均化した額	基本的に使わなくてよい

ありがちな誤読が、RI / Savings Plans を買っているのに UnblendedCost で月次推移を見てしまうケースです。
前払いした月だけドカンと跳ね、その後の月は安く見える ── これでは「毎月のランニングコストの実態」が掴めません。

「毎月いくらかかっているか」を知りたいなら AmortizedCost、
「今月いくら請求されるか」を知りたいなら UnblendedCost、と用途で使い分けます。

罠その3：Credit / Refund / Tax が混ざる

• Credit（クレジット）：キャンペーンや補填で相殺された額。これが混ざると「急に安くなった」ように見える
• Refund（返金）：返金が乗ると、その月だけマイナス方向に振れる
• Tax（税）：純粋なサービス利用コストを見たいときはノイズになる

「ランニングコストの実態」を比較したいなら、
Credit / Refund を除外し、Tax も外すと、サービスそのものの利用コストが見えます。

比較レポートで固定している前提（例）:
  メトリクス: UnblendedCost（or AmortizedCost）
  除外:       Credit / Refund
  税:         Tax 除外
  通貨:       USD で統一

レポートの冒頭に「どの前提で集計したか」を必ず書いておくと、
後から見た人が誤読しません。自動生成レポートでも、この前提を毎回ヘッダに固定出力させています。

まとめ：比較の前に「前提」をそろえる

AWS コストを前月比で語るときは、増減の数字に飛びつく前に次を確認します。

1. 日数差で説明がつかないか？（時間課金サービスは特に）→ 日割りで見る
2. メトリクスは用途に合っているか？（実態把握=AmortizedCost / 請求額=UnblendedCost）
3. Credit / Refund / Tax が混ざっていないか？ → 除外して比較
4. レポートには集計の前提を明記する

この 4 点をテンプレ化しておくと、「構成は変えてないのに増えた／減った」に振り回されず、
本当に対処すべきコスト変動だけにフォーカスできます。