AWS を学習用に触っていて、請求額が思っていたより増えている。請求書の合計を眺めても、どのサービスが、どこで、何のせいで増えたのかは分かりません。慌てて何かを消す前に、見る順番を決めておけば、原因は絞れます。この記事では、費用を絞り込む順番と、増える前に気づく仕組みの置き方を説明します。料金の考え方そのものは、先に AWS の料金の考え方で確かめておくと読みやすくなります。
この記事の結論
- まず Cost Explorer で期間を決め、サービス別に並べて、増えた箇所を1つに絞ります。
- 次にリージョン・使用タイプ・タグなど別の軸で分け、止め忘れや消し忘れのリソースを探します。
- 原因が見つかったら止める・消す。操作の手順は公式ドキュメントに従います。
- Budgets は決めた金額に近づくと知らせ、Cost Anomaly Detection は過去の傾向と違う動きを知らせます。役割が違います。
- どちらもデータの反映に遅れがあるため、通知が来る前に費用が増えることがあります。毎日見る習慣と組み合わせます。
請求が増えたとき最初に何を見るか｜合計ではなく「期間とサービス別」
請求の合計は、結果でしかありません。合計が増えたと分かっても、増えた理由は書かれていないからです。最初にやるのは、いつから増えたのかを決めることと、その期間の費用をサービス別に並べることです。
たとえば電気代が上がったとき、請求書の合計を見ても原因は分かりません。部屋ごと、時間帯ごとの使用量を見て、はじめて「つけっぱなしの機器がある」と分かります。AWS でも同じで、サービス別に並べると、多くの場合は1つか2つのサービスが突出して見えます。そこから先を深掘りします。
調べる順番は4段です。期間 → サービス → リージョン／使用タイプ → リソース。広い軸から狭い軸へ絞っていくので、いきなりリソースの一覧を端から確認するより早く着きます。
NARROW DOWN調べる順番
費用の原因は期間 → サービス → 地域と使用タイプ → リソースの順に絞る
-
期間
いつから増えたかを決める
-
サービス
サービス別に並べて1つに絞る
-
リージョン／使用タイプ
どこで何に課金されたか
-
リソース
止め忘れ・消し忘れを探す
CHECK 1ここまでの確認
請求額が想定より増えたとき、最初に絞り込む軸として適切なのはどれか?
答えと解説
答え: 2. 期間を決めて、サービス別に費用を並べる
合計だけでは、どこで増えたのかが分かりません。まず期間を決め、サービス別に並べて増えた箇所を1つに絞ります。読み直すのは「請求が増えたとき最初に何を見るか」の章です。
Cost Explorer とは何か｜費用を軸で切り分けて見る道具
AWS Cost Explorer は、費用と使用状況を可視化して分析するための道具です。公式ドキュメントによると、過去 13 か月分の表示と、先の費用の予測ができ、データは少なくとも 24 時間ごとに更新されます。
ここで大事なのは「軸を変えて見られる」ことです。同じ費用を、サービス別、リージョン別、使用タイプ別、タグ別といった切り口で組み替えて眺められます。請求書が「合計と明細」だとすれば、Cost Explorer は「明細を好きな軸で集計し直せる表」です。
注意したいのは役割の違いです。Cost Explorer は費用を見て分析する道具で、費用が増えそうなときに自分から知らせてくれる道具ではありません。知らせる側は、後の章で扱う Budgets などが担います。
CHECK 2ここまでの確認
費用を期間・サービス・リージョンなどの軸で切り分けて見る道具はどれか?
答えと解説
答え: 1. Cost Explorer
軸を変えて費用を可視化・分析するのが Cost Explorer です。Budgets は決めた金額に近づいたことを知らせる側です。読み直すのは「Cost Explorer とは何か」の章です。
どう絞り込むか｜サービス → リージョン → 使用タイプ → タグの順
期間とサービスで増えた箇所を1つに決めたら、同じサービスの中でさらに軸を替えます。
| 軸 | 何が分かるか | よくある気づき |
|---|---|---|
| サービス | どのサービスの費用が増えたか | 想定していなかったサービスが上位にいる |
| リージョン | どの地域で使っているか | 普段使わない地域に何かが残っている |
| 使用タイプ | そのサービスの何に対する費用か | 転送量や稼働時間など、課金の対象が分かる |
| タグ | どのプロジェクトや担当の費用か | タグを付けていれば、持ち主に近づける |
使用タイプは見慣れないかもしれません。同じサービスでも「動かしている時間」「保存している量」「外へ出したデータ量」のように、課金される対象が分かれています。どの対象が増えたのかが分かると、止めるべきものの見当が付きます。
タグで分けるには、事前にリソースへタグを付け、費用の集計に使えるよう有効化しておく必要があります。タグの設計そのものはこの記事の範囲外です。付いていなければ、サービスとリージョンと使用タイプまでで絞ります。
原因の典型はどこにあるか｜止め忘れ・消し忘れ・想定外のリージョン
絞り込んだ先で見つかるものには、型があります。
- 止め忘れ: 検証で起動したまま、使っていない間も動き続けている。
- 消し忘れ: 使い終わったあとも、保存したデータや付随するリソースが残っている。
- 想定外のリージョン: 普段と違う地域で試して、そのまま忘れている。
- 使い方の変化: 試験勉強の中でデータを大量に動かした、処理を繰り返し実行したなど、使い方そのものが変わった。
学習用のアカウントでは、特に前の3つが多くなります。リージョンの軸で見る価値はここにあります。サービスが分かっても、どの地域に残っているのかが分からなければ、消す対象にたどり着けないからです。
見つけたら止める、消す。具体的な操作は画面やサービスによって異なり、改定もあるため、この記事では書きません。公式ドキュメントで該当サービスの手順を確認してください。無料利用枠の範囲を超えると課金される点も、あわせて意識しておくと原因を見つけやすくなります。枠の現在の条件は公式ページで確認してください。
AWS Budgets と異常検出は何が違うのか｜しきい値と「いつもと違う」
増えてから調べるより、増える前に気づけるほうが被害は小さくなります。そのための仕組みが2つあります。
AWS Budgets は、決めた金額や使用量に対して、実績または予測が近づいたときに知らせる道具です。通知先にはメールや SNS を選べます。「月にこの金額を超えたら困る」という自分の線を引いておく使い方です。さらに、予算に達したときに IAM ポリシーや SCP を適用する予算アクションもあります。ただし、本記事の範囲では「通知だけでなく、制限をかける使い方もある」と知っておけば十分です。
AWS Cost Anomaly Detection（異常検出）は、機械学習で通常の傾向と違う支出を見つけ、原因をサービス・アカウント・リージョン・使用タイプなどで示します。金額の線を自分で決めなくても、「いつもと違う」ことに気づけるのが強みです。
TWO ALERTS通知の役割
Budgets は自分の線、異常検出はいつもとの差で知らせる
Budgets
決めた金額・使用量
- 実績や予測が線に近づくと通知
- 通知先はメールや SNS
- 月の上限を守りたいときに
Cost Anomaly Detection
過去の傾向との差
- 機械学習で通常と違う支出を検出
- サービス・リージョンなどで原因を示す
- 想定外の急な動きに気づく
| Budgets | Cost Anomaly Detection | |
|---|---|---|
| 知らせる基準 | 自分で決めた金額・使用量 | 過去の傾向との差 |
| 向いている場面 | 月の上限を守りたい | 想定外の急な動きに気づきたい |
| 弱いところ | 線の内側での急増は気づきにくい | 少しずつ増える場合の線引きは自分で持てない |
どちらか一方ではなく、両方を置くのが基本です。Budgets は「自分の線」、異常検出は「いつもとの差」を担当します。
CHECK 3ここまでの確認
「いつもの傾向と違う支出」を機械学習で見つけて知らせるのはどれか?
答えと解説
答え: 2. Cost Anomaly Detection
金額のしきい値を決めて知らせるのが Budgets、過去の傾向との差で知らせるのが Cost Anomaly Detection です。役割が違うので両方置けます。読み直すのは「Budgets と異常検出は何が違うのか」の章です。
通知の遅れをどう扱うか｜反映の遅延を前提にした見る頻度の決め方
最後に、通知は即時ではないという点です。公式ドキュメントによると、Budgets は更新が 1 日に最大 3 回で、通知までに遅れがあります。異常検出は、検出までに最大 24 時間かかることがあります。Cost Explorer のデータも、更新は少なくとも 24 時間ごとです。
つまり、費用が発生してから、請求データに反映され、検出や通知に至るまでには時間差があります。通知が届いた時点では、費用はすでに増えていて、いまも増え続けているかもしれません。
DELAY通知までの遅れ
使ってから通知が届くまでには時間差がある
-
使う
リソースが動く
-
反映
請求データに載る
-
検出・通知
更新や検出に遅れ
-
止める
自分で確認して閉じる
この遅れを前提にすると、次のように運用を組めます。
- 通知の金額は、本当に困る金額よりも低めに置く。遅れの間に増える分の余裕になります。
- 検証が終わったら、その日のうちに止める・消す。通知に頼らず、自分で閉じる習慣を持つ。
- 検証をしている間は、Cost Explorer で毎日一度、サービス別を開く。
仕組みは早く気づくための補助で、止める判断は人がします。通知が来たら、この記事の4段（期間 → サービス → リージョン／使用タイプ → リソース）で絞り、止める・消すところまで進めます。
CHECK 4ここまでの確認
通知が届いた時点で、費用はどうなっている可能性があるか?
答えと解説
答え: 2. すでに増えていて、いまも増え続けているかもしれない
使った費用が請求データに反映され、そこから検出・通知されるまでに遅れがあります。通知は「少し前の状態」を知らせていると考えます。読み直すのは「通知の遅れをどう扱うか」の章です。
まとめ
請求が増えたときは、合計ではなく期間とサービス別から入り、リージョン・使用タイプ・タグで絞って、止め忘れや消し忘れのリソースを探します。気づく仕組みは、金額の線を守る Budgets と、いつもとの差を見つける Cost Anomaly Detection の2本を置き、どちらも反映の遅れがあることを前提に、毎日見る習慣と組み合わせます。
原因が分かったあとに、長期でどう費用を抑える設計にするかは、次の コスト設計の記事で扱います。
Cloudory 執筆者（AWS 認定 全冠）
調べる順番を先に決めておくと、請求が増えた日でも落ち着いて動けます。まず期間とサービス別、次に別の軸、の2手だけ覚えておいてください。
参照ソース
- AWS Cost Management ユーザーガイド: Cost Explorer とは — Cost Explorer の役割、過去 13 か月の表示と予測、データ更新の頻度、API の課金の根拠
- AWS Cost Management ユーザーガイド: Budgets でコストを管理する — Budgets の種類、実績と予測での通知、通知先、更新頻度と通知の遅れの根拠
- AWS Cost Management ユーザーガイド: Cost Anomaly Detection — 異常検出の仕組み、原因の示し方、検出までの時間の根拠
