AWS講義資料｜設定ミスによる高額請求事故
AWSは「高い」のではなく、
設定ミスで課金メーターが暴走する
AWSでは、EC2のサーバー代だけでなく、通信量・ログ・APIリクエスト・放置リソース・権限ミスによって 短期間で大きな費用が発生することがあります。本資料では、実務で起こりやすい高額請求事故を設定ミスの観点から整理します。
1. 講義の目的
AWSの高額請求事故は、悪意ある攻撃だけでなく、日常的な設定ミス・放置・監視不足でも発生します。
| 項目 | 内容 |
|---|---|
| 対象者 | 情報システム担当、Web制作会社、インフラ担当、クラウド管理者、経営者 |
| 目的 | AWSで高額請求が起きる仕組みを理解する |
| 重点 | 設定ミス、放置、監視不足、権限過大による事故 |
| 到達目標 | 高額請求を未然に防ぐチェックリストを持ち帰る |
2. AWS高額請求の本質
AWSは基本的に従量課金です。つまり、利用した分だけ費用が発生します。 問題は、管理者が「使っている」と認識していない場所でも課金が発生する点です。
危険
通信量
NAT Gateway、AZ間通信、リージョン間通信、インターネット向け転送で費用が膨らみます。
注意
ログ
CloudWatch Logsに大量のDEBUGログや巨大JSONを出すと、ログ取り込み・保存で課金されます。
管理対象
放置リソース
EC2を止めても、EBS、Snapshot、Elastic IP、Load Balancer、NAT Gatewayが残ることがあります。
重要：AWS事故では「サーバーを消したから安心」とは限りません。周辺リソースが残っていないか確認が必要です。
3. 事故パターン一覧
| No | 事故パターン | 主な原因 | 危険度 |
|---|---|---|---|
| 1 | NAT Gateway通信量爆発 | Private Subnetから大量外部通信、VPC Endpoint未使用 | 非常に高い |
| 2 | Lambda無限実行 | S3イベント、EventBridge、再帰処理、リトライ設定ミス | 非常に高い |
| 3 | CloudWatch Logs大量出力 | DEBUGログ、本番ログ過多、保持期間Never Expire | 高い |
| 4 | S3リクエスト課金事故 | 大量PUT/GET、外部からの誤アクセス、アプリのリトライ暴走 | 高い |
| 5 | EC2 / RDS / EBS / Snapshotの消し忘れ | 検証環境、バックアップ、固定IP、ロードバランサー放置 | 中〜高 |
| 6 | Terraform / CloudFormationの設定ミス | リージョン指定ミス、count / for_eachミス、大量作成 | 高い |
| 7 | アクセスキー漏洩 | GitHub公開、.env流出、IAM権限過大 | 非常に高い |
4. 事故事例① NAT Gatewayの通信量爆発
Private Subnet内のサーバーやLambdaが外部APIへ大量通信し、その通信がすべてNAT Gatewayを通ることで高額化します。
Private Subnet内のEC2 / Lambda
↓
外部API・S3・インターネットへ大量通信
↓
NAT Gatewayを経由
↓
NAT Gatewayの時間課金 + データ処理課金 + データ転送料
↓
高額請求
よくある原因
| 原因 | 内容 |
|---|---|
| VPC Endpoint未設定 | S3やDynamoDB向け通信までNAT Gateway経由になる |
| 外部APIへの過剰アクセス | バッチ処理やLambdaが大量通信を発生させる |
| AZ設計ミス | 別AZのNAT Gatewayを通り、追加のデータ転送料が発生する |
| 監視不足 | 通信量の増加に気づけない |
防止策
S3 Gateway Endpointを設定する
DynamoDB Gateway Endpointを設定する
NAT Gatewayの通信量をCloudWatchで監視する
AWS Budgetsでサービス別アラートを設定する
Cost Anomaly Detectionを有効化する
VPC設計時に通信経路を図示する
5. 事故事例② Lambdaの無限実行・再帰実行
Lambdaは自動でスケールするため、イベント設定を誤ると短時間で大量実行されます。
S3にファイルが置かれる
↓
Lambdaが起動
↓
Lambdaが同じS3バケットにファイルを書き込む
↓
またLambdaが起動
↓
無限ループ
↓
Lambda実行回数・CloudWatch Logs・S3リクエストが増加
高額化する課金対象
| 課金対象 | 内容 |
|---|---|
| Lambda実行回数 | 呼び出されるたびに課金対象となる |
| Lambda実行時間 | 処理時間が長いほど費用が増える |
| CloudWatch Logs | 実行ログが大量に出力される |
| S3 API | ファイル作成・読取・一覧取得のリクエストが増える |
| NAT Gateway | 外部通信がある場合、通信量課金も加わる |
防止策
入力バケットと出力バケットを分ける
Lambda Reserved Concurrencyを設定する
失敗時リトライ回数を確認する
Dead Letter Queueを設定する
開発環境の予算アラートを低く設定する
S3イベントの対象prefix / suffixを制限する
6. 事故事例③ CloudWatch Logsの大量出力
CloudWatch Logsは便利ですが、ログを大量に出す設計にすると、ログ取り込み・保存・検索で費用が増えます。
Lambda / ECS / EC2アプリ
↓
DEBUGログを大量出力
↓
CloudWatch Logsに全量保存
↓
ログ取り込みGB課金
↓
保持期間がNever Expire
↓
過去ログも残り続ける
よくある設定ミス
| 設定ミス | 結果 |
|---|---|
| DEBUGログのまま本番化 | 通常の数十倍のログ量になる |
| 巨大JSON全文をログ出力 | 1件あたりのログサイズが大きくなる |
| ログ保持期間がNever Expire | 古いログが消えず、保存費用が積み上がる |
| CloudWatch Logs Insights多用 | 検索・分析量に応じた追加費用が発生する |
防止策
本番環境ではDEBUGログ常時ONを避ける
ログ保持期間を7日・14日・30日などに設定する
個人情報や巨大データをログに出さない
IncomingBytesを監視する
検証環境は短期保持にする
障害時にログが爆増しない設計にする
7. 事故事例④ S3のリクエスト課金事故
S3は保存容量だけでなく、PUT・GET・COPY・LISTなどのリクエストにも課金が発生します。
よくある原因
| 原因 | 内容 |
|---|---|
| ありがちなバケット名 | 外部システムや第三者の誤送信先になりやすい |
| アプリの再試行処理 | 失敗時に大量のPUT / GETを繰り返す |
| ライフサイクル設定ミス | 不要な移行・削除リクエストが増える |
| アクセスログ未設定 | どこからリクエストが来たか分からない |
防止策
バケット名を推測しにくい名前にする
S3 Storage Lensで使用状況を確認する
必要に応じてCloudTrail Data Eventsを有効化する
ライフサイクルルールを定期レビューする
アプリのリトライ回数を制限する
S3単体の予算アラートを設定する
8. 事故事例⑤ 放置リソースによる継続課金
EC2を止めても、関連リソースが残っていると課金が続きます。検証環境・開発環境で特に多い事故です。
検証用にEC2を作成
↓
作業完了
↓
EC2だけ停止
↓
EBS・Snapshot・Elastic IP・Load Balancer・NAT Gatewayが残る
↓
毎月課金
見落としやすいリソース
| リソース | 見落とし内容 |
|---|---|
| EBS | EC2停止後もボリュームは残る |
| Snapshot | バックアップとして残り続ける |
| Elastic IP | 未使用状態で課金対象になる場合がある |
| Load Balancer | EC2を消してもALB / NLBが残る |
| NAT Gateway | 作成したまま放置されやすい |
| RDS | 停止、バックアップ、Snapshotの扱いに注意 |
防止策
Owner / Project / Env / ExpireDateタグを必須にする
検証環境は夜間・休日に自動停止する
月1回、未使用リソースを棚卸しする
IaCで作成・削除を管理する
本番・検証・学習アカウントを分ける
Cost Explorerでサービス別に確認する
9. 最低限入れるべき防御設定
AWSを使い始める前に、最低限以下の設定を入れるべきです。特に予算アラートは構築前に設定します。
| 優先度 | 設定 | 目的 |
|---|---|---|
| 最重要 | root MFA | rootアカウント乗っ取り防止 |
| 最重要 | AWS Budgets | 月額・予測・サービス別の予算超過を通知 |
| 最重要 | Cost Anomaly Detection | 異常なコスト増加を自動検知 |
| 高 | CloudWatch Billing Alarm | 推定請求額が閾値を超えたら通知 |
| 高 | CloudTrail | 誰が何を操作したか記録する |
| 高 | GuardDuty | 不審なAPI操作や侵害兆候を検知 |
| 高 | IAM最小権限 | ミスや漏洩時の被害を抑える |
| 中 | CloudWatch Logs Retention | ログの永久保存を防ぐ |
| 中 | Lambda同時実行制限 | Lambda暴走時の被害を制限する |
| 中 | S3 / DynamoDB VPC Endpoint | NAT Gateway経由の通信を減らす |
鉄則：AWS構築前に「予算アラート」「異常検知」「CloudTrail」「MFA」を設定する。
10. 高額請求に気づいた時の初動対応
1
Cost Explorerで原因を切り分ける
Service、Region、Usage Type、Linked Account、Tagで確認します。
2
暴走しているリソースを止める
LambdaならReserved Concurrencyを0、Auto ScalingならDesiredを0、漏洩キーなら即無効化します。
3
証跡を残す
発生日時、請求額、原因、実施した対応、再発防止策を記録します。
4
AWSサポートへ相談する
スクリーンショット、Cost Explorerの内訳、再発防止策を提示できる状態にします。
原因別の止め方
| 原因 | 初動対応 |
|---|---|
| Lambda暴走 | Reserved Concurrencyを0にする |
| EC2大量起動 | Auto Scaling GroupのDesired Capacityを0にする |
| NAT Gateway課金 | 対象通信を止め、必要に応じてVPC Endpoint化する |
| CloudWatch Logs爆増 | ログレベルを下げる、ログ出力を停止する、保持期間を設定する |
| S3リクエスト爆増 | アプリ停止、バケットポリシー確認、リクエスト元調査 |
| アクセスキー漏洩 | Access Key無効化、IAMローテーション、CloudTrail確認 |
11. 受講者向け確認テスト
Q1. NAT Gatewayで高額請求になる主な理由は？
NAT Gatewayは稼働時間だけでなく、通過したデータ量GB単位でも課金されるためです。
Q2. Lambdaの無限実行を防ぐ代表的な設定は？
Reserved Concurrencyの設定、入力バケットと出力バケットの分離、リトライ設定の見直しです。
Q3. CloudWatch Logsでやってはいけない本番設定は？
DEBUGログを常時出すこと、ログ保持期間をNever Expireのままにすることです。
Q4. AWS高額請求の初動で最初に見るべき画面は？
Billing / Cost Explorerです。Service、Region、Usage Typeで原因を切り分けます。
Q5. 最低限設定すべきコスト防御は？
AWS Budgets、Cost Anomaly Detection、Billing Alarm、CloudTrail、IAM最小権限、root MFAです。
12. 講義の締め
| 鉄則 | 内容 |
|---|---|
| 1. 作る前に予算アラート | 構築後ではなく、構築前にBudgetsを設定する |
| 2. 通信経路を確認 | NAT Gateway、VPC Endpoint、AZ間通信を確認する |
| 3. ログ量を制御 | DEBUGログ常時ONとログ永久保存を避ける |
| 4. Lambdaを止められる設計 | 同時実行数、リトライ、イベント設計を確認する |
| 5. 放置リソースを棚卸し | EC2以外のEBS、Snapshot、NAT、ALBを確認する |
| 6. アクセスキーを公開しない | GitHub、.env、コード直書きに注意する |
| 7. Cost Explorerを定期確認 | 週次でService別・Region別の増加を確認する |
AWS運用で大切なのは、
構築できることだけではない。
止められること、気づけること、説明できること。
構築できることだけではない。
止められること、気づけること、説明できること。
13. 参考リンク
講義資料の補足として、以下のAWS公式ドキュメントを確認すると理解が深まります。