Technology

【心臓停止】AWSの請求画面開いたら「978兆ドル(15京円)」請求されててインフラSE絶句「国家予算の数百倍」「符号なし整数オーバーフローの恐怖」

投稿日時: 2026/02/10 18:00

■ 概要・編集部サマリー

1. 【背景・AWS請求額978兆ドルバグのパニック】AWS請求ダッシュボードに突如として15京円超えの請求額が表示され、全世界のクラウド管理者が肝を冷やしました。 2. 【焦点・数値型オーバーフローと通貨計算の欠陥】負の値の処理ミスや64bit符号なし整数のアンダーフローによって異常な極大値が生成されたバグ構造が解明されました。 3. 【評価・課金システムの設計原則とアラート防壁】浮動小数点数(Float)禁止原則と高精度Decimal型の採用、ならびに異常請求を防ぐAWS Budgets設定の鉄則が再確認されています。

■ 符号なし整数のアンダーフローと天文学的請求額の発生メカニズム

多くの大規模クラウド課金システムでは、ストレージ使用量やネットワーク転送量をバイト単位やマイクロドル単位の64ビット整数(`uint64`)として内部パイプラインで集計しています。

無料枠クレジットの適用やマイナス相殺処理において、0を下回る負の値が正しくバリデーションされずにアンダーフローを起こすと、値が型最大値 `0xFFFFFFFFFFFFFFFF`(約1,844京)へ瞬時に反転し、通貨換算ロジックを経て978兆ドルという天文学的表示を生み出す構造的欠陥が露呈しました。

■ 金融・課金ドメインにおける「浮動小数点数(Float)禁止」の鉄則

プログラミング言語の基本型である `float` や `double`(2進数浮動小数点数)は、`0.1 + 0.2 = 0.30000000000000004` のように2進数変換時の循環小数による丸め誤差が不可避的に発生します。

課金トランザクションや請求計算のドメインでは、浮動小数点数の使用を厳格に禁止し、最小通貨単位(セントや銭)での整数保持、または `BigDecimal` などの高精度10進数型を採用することがシステム設計の絶対鉄則です。微小な丸め誤差が数百万トランザクションで累積すると巨額の財務不整合を引き起こします。

■ クラウド破産を防ぐFinOpsガードレールと自動停止自動化

突発的なインフラ設定ミス、無限ループするLambda関数、アクセスキー流出による不正マイニングなど、パブリッククラウドにおける高額請求リスクは日常的に潜んでいます。

AWS BudgetsやCloudWatch Billing Alarmsを設定し、想定予算の80%到達時の即時Slack通知や、上限突破時に自動で開発環境を隔離・停止するLambdaガードレールを事前に組み込むことが、クラウド破産を防ぐ必須の運用基準です。

海外掲示板の反応・まとめ

1. [編集部サマリー]:

■ 海外掲示板Reddit(r/aws)より。AWSの課金ダッシュボードに978兆ドルという人類の総資産を超える請求額が表示され、世界中のインフラSREがパニックに陥ったバグ事件をお届けします。

2. [名無しさん@インフラSRE戦士]:

朝起きてAWSコンソール開いて『今月の請求額:$978,000,000,000,000』ってデカデカと表示されてたら、確実にその場で心肺停止して気絶する自信あるわw 地球上の全世界のGDPを合計しても払えねえよ。

3. [名無しさん@低レイヤー数値屋]:

>>2 典型的な `uint64`(64ビット符号なし整数)のアンダーフローかオーバーフローだな。割引プロモーションやマイナス調整データが入った瞬間に `0xFFFFFFFFFFFFFFFF`(約1844京)付近に跳ね上がって、為替レート換算掛けた結果の天文学的数値だろ。

4. [名無しさん@金融システムSE]:

>>3 金融や請求決済システムで生の整数型や浮動小数点数(float/double)をそのまま使うなとあれほど言われてるのになw 課金計算は100% `BigInt` か `Decimal`(固定小数点・任意精度数値型)で扱わないと絶対に大事故になる。

5. [名無しさん@クラウドアーキテクト]:

AWSの表示バグと分かってても、クレジットカード会社から『限度額オーバーのためカードを一時停止しました』って緊急SMSが飛んでくるんじゃないかと10分くらい冷や汗が止まらなかった報告多数で草生えるわ。

6. [名無しさん@海外クラウドニキ]:

Redditでも『俺がEC2インスタンスを1個止め忘れたせいで地球が買収された』って自虐ミームが数千件のUpvote集めてて大爆笑したわ。

7. [名無しさん@AWSサポート窓口同情派]:

この時AWSのエンタープライズサポート窓口に世界中から『うちの会社が破産します!』って緊急チケットが数万件殺到したと思うとサポート担当者に涙が出る。

8. [名無しさん@フロントエンド防壁推進]:

バックエンドから異常値が降ってきたとしても、フロントエンドのUI側で『請求額が前月比1000倍以上なら警告バッジを表示する』っていうサニタイズ(バリデーション)入れとくべきだったな。

9. [名無しさん@AWS Budgets信者]:

だからこそAWS Budgetsで『月100ドル超えたらメール通知+Lambdaでインスタンス自動停止』のガードレールを組んでおくのがクラウド運用の基本中の基本なんよ。これを怠るとマジで破産する。

10. [名無しさん@分散システム考察派]:

AWSみたいな世界最高峰のハイパースケーラーのエンジニア集団ですら、数値計算とUIレンダリングの結合部分でこういう初歩的なバグを出すんだから、人間が作るソフトウェアに完璧はないな。

11. [名無しさん@コスト最適化FinOps]:

FinOpsの観点からも、請求データのパイプラインがリアルタイムではなく数時間遅延で非同期バッチ集計される仕組みの複雑さが根本原因にあるんだろうな。

12. [名無しさん@Terraform職人]:

自社のインフラ構成コード(IaC)にバグがあってLambdaが無限ループして毎秒1万回実行されてた時のトラウマがフラッシュバックしたわ。

13. [名無しさん@セキュリティエンジニア]:

アクセスキーが流出して勝手に暗号資産マイニングインスタンスを100台立てられた時も似たような請求額になるから、笑い話で済ませずにクレデンシャル管理を見直すべき。

14. [名無しさん@クラウド運用保守]:

明日出社したら全AWSアカウントのBilling Alarmsが正しく設定されてるか全件棚卸しするわ…

15. [名無しさん@まとめ総括]:

クラウド時代の恐怖と数値処理の重要性を痛烈に思い知らせてくれる名珍事だな。適切な請求アラートと安全な数値型設計の徹底を肝に銘じたい。