AWS の請求が急に増えたとき — 最もよくある原因 10 個
請求書を開いたら先月の 2 倍でした。トラフィックが 2 倍になったわけでもなく、インスタンスを増やした覚えもありません。この記事はその状況で犯人を探す手順と、実務で最も頻繁に当たる原因 10 個を整理します。請求まわりの基礎(請求アラート、Cost Explorer、無料利用枠)は AWS 基礎 #3 で扱ったので、ここでは「急に跳ねたケース」のシナリオに集中します。金額の例は us-east-1 基準で、リージョンごとに異なります。
まず犯人を絞り込む手順 #
原因のリストを眺める前に、どのサービスで増えたかは 30 秒で絞り込めます。
- Cost Explorer で期間を「直近 3 か月、日次」にして、Service でグルーピングして見ます。どのサービスがいつから跳ねたのか、グラフですぐ分かります。
- サービスが分かったら、同じ画面で Usage Type のグルーピングに切り替えます。同じ EC2 でも、インスタンス時間なのか、EBS なのか、データ転送なのかがここで分かれます。
- リソース単位まで掘り下げるにはタグが必要です。タグ付けができていないなら、今回の一件を機にコスト配分タグを整えておくことをおすすめします。
この手順で絞り込んだら、以下の 10 個から該当する項目を探します。
1. NAT Gateway のデータ処理 #
不動の 1 位です。NAT Gateway は時間料金(約 $0.045)に加えて、通過するデータ 1GB ごとの処理料金(約 $0.045/GB)を取ります。プライベートサブネットのワークロードが S3 や ECR のような AWS サービスと大量にやり取りするトラフィックが NAT を経由していると、コンテナイメージのプルやデータパイプラインが増えた分だけ、料金がそのまま増えます。
- 確認: Usage Type で
NatGateway-Bytesが跳ねていないかを見ます。 - 対処: S3・DynamoDB はゲートウェイ型 VPC エンドポイント(無料)で、ECR などそれ以外はインターフェイス型エンドポイントで、NAT を迂回する経路を作ります。ゲートウェイエンドポイント一つで月数百ドルが浮く事例は珍しくありません。
2. CloudWatch Logs の取り込み #
ログは保存より取り込み(ingestion)が高いのです(約 $0.50/GB)。デプロイでデバッグログを有効にしたまま忘れていたり、エラーが繰り返されてスタックトレースを吐き続けていたりすると、ログ取り込みの料金がコンピューティングの料金を超えることもあります。
- 確認: Usage Type の
DataProcessing-Bytes(ログ取り込み)、ロググループごとのIncomingBytes指標を見ます。 - 対処: ログレベルの調整と、繰り返されるエラーの修正が先です。保持期間が「無期限」のロググループも一緒に整理します(デフォルトが無期限です)。
3. EBS スナップショットと AMI の蓄積 #
バックアップの自動化が作ったスナップショットが、削除ポリシーなしに積み上がるケースです。スナップショットは増分なので一つひとつは小さく見えますが、数百個たまると元のボリュームより大きくなります。AMI 作成時に付いてきたスナップショットは、AMI の登録解除では自動削除されません。
- 確認: Usage Type の
EBS:SnapshotUsageの推移を見ます。 - 対処: Data Lifecycle Manager や AWS Backup で保持数・期間を決めます。孤児スナップショット(元のボリュームが消えたもの)から掃除します。
4. 止まっているリソースの残存課金 #
EC2 を停止(stop)しても、付いていた EBS ボリュームと割り当てられたパブリック IPv4 アドレスは課金され続けます。特にパブリック IPv4 は 2024 年から、使用の有無にかかわらずアドレスあたり約 $0.005/時間(月約 $3.6)が課金されるので、未接続の Elastic IP が数十個転がっていると、それだけで月数百ドルになります。
- 確認: Usage Type の
PublicIPv4:InUseAddress・IdleAddress、未使用ボリューム(available状態)を見ます。 - 対処: 未接続 EIP の解放、孤児ボリュームのスナップショット後の削除、長く停止状態が続くインスタンスは AMI に焼いて終了します。
5. データ転送 — リージョン間、AZ 間、インターネット向け #
インターネットへ出るトラフィック(約 $0.09/GB)だけ覚えていがちですが、リージョン間レプリケーションと AZ 間トラフィック(双方向それぞれ $0.01/GB 前後)も積み上がります。マルチ AZ 構成でアプリケーションとデータベースが AZ をまたいで通信している場合や、リージョン間レプリケーションを有効にした場合が典型です。
- 確認: Usage Type で
DataTransfer-Regional-Bytes(AZ 間・リージョン内)、DataTransfer-Out-Bytesを見ます。 - 対処: 同じ AZ への配置(ただし可用性とのトレードオフを確認)、CloudFront によるアウトバウンドの吸収、リージョン間レプリケーションの範囲の見直しです。
6. Lambda の暴走と再帰呼び出し #
Lambda が S3 バケットに書き込み、その書き込みイベントが同じ Lambda を呼ぶ再帰構造が事故の古典です。スロットリングのない再試行の嵐(SQS のリドライブ、イベントの再処理)も、同じように請求額を膨らませます。
- 確認: Lambda の
Invocations指標の時系列で、特定の関数の爆発を見ます。 - 対処: イベントフィルタで再帰のループを遮断し(AWS の再帰検出が一部を自動停止します)、DLQ と最大再試行を設定し、同時実行数に上限を置きます。
7. S3 のリクエスト料金とバージョンの蓄積 #
S3 は保存容量だけでなくリクエスト回数にも課金されます(PUT と LIST は GET より高いのです)。小さいファイル数百万個を繰り返しリストするバッチや、バージョニングを有効にしたままライフサイクルルールなしに上書きを繰り返すバケットが典型です。旧バージョンは画面に見えないだけで、すべて課金対象です。
- 確認: Usage Type の
Requests-Tier1/2、S3 Storage Lens でバージョン別の容量を見ます。 - 対処: ライフサイクルルールで旧バージョンを失効させ、小さいオブジェクトをまとめ、LIST 呼び出しを最小化します。
8. 開発環境の 24 時間稼働と過剰プロビジョニング #
夜間・週末も動く開発・ステージングのインスタンス、「とりあえず大きめに」取った RDS が、ベースラインをじわじわ押し上げます。急な跳ね上がりより「少しずつ上がる」パターンで現れ、新しい環境を作った月には階段状の増加として現れます。
- 確認: タグ(環境別)でのグルーピング、Compute Optimizer のダウンサイジング推奨を見ます。
- 対処: 開発環境のスケジュール停止(Instance Scheduler)、推奨に基づくダウンサイジングです。
9. RI・Savings Plans の期限切れ #
使用量はそのままなのに料金だけ跳ねたなら、最初に疑う項目です。リザーブドインスタンスや Savings Plans が期限切れになると、同じ使用量がオンデマンド単価で請求されるので、何も変えていないのに 30〜40% 上がります。
- 確認: Billing コンソールの RI/SP カバレッジレポートで、期限日とカバレッジの低下を見ます。
- 対処: 期限アラートを事前に設定し、更新または使用パターンに合った再コミットをします。料金モデルの構造は SAA Domain 4-1 で扱いました。
10. CloudWatch 指標・API 呼び出し — モニタリングツールのポーリング #
外部のモニタリングツール(あるいは自作のダッシュボード)が GetMetricData を高頻度でポーリングすると、CloudWatch API の料金が目立つ項目に上がってきます。カスタム指標(指標あたり月約 $0.30)をカーディナリティ高く(インスタンス別、顧客別)作った場合も同じです。
- 確認: Usage Type の
CW:GMD-Metrics(GetMetricData)、CW:MetricMonitorUsage(カスタム指標)を見ます。 - 対処: ポーリング周期の緩和、必要な指標だけの収集、カーディナリティの縮小です。
再発防止 — 次の急増は請求書の前に知る #
原因を突き止めたら、同じことを請求書で知ることにならないように三つを有効にしておきます。
- AWS Budgets — 月次予算と予測超過のアラートを設定します。最低限のセーフティネットです。
- Cost Anomaly Detection — サービスごとの普段のパターンから外れるとアラートをくれます。無料で、この記事の事例の大半を数日以内に捕まえてくれます。
- コスト配分タグと定期レビュー — タグのないコストは追跡できません。月 1 回の Cost Explorer レビューをチームのルーティンにします。
モニタリングダッシュボードの構成まで含めた運用の流れは AWS 実践 #6 で扱いました。
まとめ #
- 犯人探しは Cost Explorer で Service → Usage Type の順のグルーピングから始めます。勘ではなくグラフが答えます。
- 急増の常連は NAT Gateway の処理量、CloudWatch Logs の取り込み、スナップショットの蓄積、データ転送、Lambda の暴走です。
- 使用量がそのままなのに上がったなら、RI・Savings Plans の期限切れから確認します。
- パブリック IPv4 や停止インスタンスの EBS のように「使わなくても出ていく」項目は、リストにして定期的に掃除します。
- Budgets と Cost Anomaly Detection を有効にしておけば、次の急増は請求書ではなくアラートで先に気づけます。