AWSの予想請求額が17億ドルと表示、通常の利用料金は5ドル未満

• 通常の利用料金が 5ドル未満 のAWSアカウントで、今月の予想請求額が 17億ドル と表示された
• 実際の利用量と請求額の差があまりにも大きく、予想請求データが不正確な状況 と見られている
• 投稿者は問題を確認して対応するため、緊急のAWSサポートチケット を作成した
• AWSのサービス状態は AWS Health Dashboard で確認できる
• 同じ現象を経験しているユーザーがいるか確認を求め、その後、関連する Redditの投稿 も追加した

---

異常な予想請求額

• 今月のAWS予想請求額は 17億ドル と表示されたが、そのアカウントの通常の利用料金は 5ドル未満 である
• 投稿者は、このような大きな差は実際の利用量ではなく、不正確な予想請求データに起因するものと見ている

確認と対応

• 問題を確認するため、緊急のAWSサポートチケット を作成した
• サービス状態は AWS Health Dashboard で確認できる
• 他のユーザーにも同じ現象が発生しているか質問し、その後、関連する Redditの投稿 を共有した

[GN⁺]

Hacker Newsのコメント

• AWSで同じ種の障害に対応したことがあるが、原因は単位設定ミスだった。GBあたり約5セントを課金するはずが、料金プランでGBの指定を落としたため、システムが既定単位のバイトとして扱い、バイトあたり5セントになってしまい、数時間のうちに一部顧客に数百万ドル級の請求額が表示された。
  深夜2時ごろにサポートチームから呼び出しを受け、3〜4時までに修正と請求訂正を終え、その直後に謝罪メールも送った。サービスが出力する使用量の値は価格に直接結び付いておらず、各SKUや請求項目は、単位種別・リージョン・単位あたり価格を含む料金プランとして定義されている。アカウントID・リージョン・SKUなどを基準に使用量レコードと料金プランを結合するため、単位種別を誤指定すると変換が壊れて、とんでもない請求額が出る。

  • テストはなかったのか？ 一見ありふれた細部を1つ誤設定しただけで、何十万人もの管理者に深夜の呼び出しと心臓発作を与えかねないということか？
    もちろん「これはありふれた細部なんかじゃない、Michael!」と言うのだろうが: https://www.youtube.com/watch?v=3fGHaVn5rGo
  • AWSの課金システムが今でもデータ受け渡しにCSVファイルを使っているのか気になる。10年以上前にAWSで初めて当番に就いたとき、ある「賢い」エンジニアが運用データの説明フィールドに「このフィールドに、カンマを入れたらどうなるだろう」みたいな実験用レコードを入れて、課金処理を壊した。
    そのレコードが広がり、リージョンが順番に同じように落ちていく様子を見届けることになり、1人が大勢の夕食を台無しにした。テスト用エンドポイントを使えたのに、わざわざ本番環境で試験したわけだ。
  • 冗談で済ませる話ではない。心血管疾患のような基礎疾患を持つ人が突然こんな請求額を見たら、不安・衝撃・無力感によって実際に死亡する可能性すらある。
  • 愚かなデフォルトを選ぶより、常に**大きく失敗する(fail loud)**ようにすべき理由がこれだ。
  • もしかしてgp3 EBSボリュームがリリースされた日に起きた話なのか気になる。

• 予算が18ドルの上限を超えたという警告メールを立て続けに3通受け取り、確認したら費用が7,800万ドルだった。フィッシングかと思って実際のアカウントに直接ログインしたが、それでも7,800万ドルで、精神的ショックは相当だった。

  • 今日中にこの求人票の説明が修正されるか賭けたい: 「Software Development Engineer II, AWS Invoicing」
    https://www.amazon.jobs/de/jobs/10428480/software-developmen...
    生成AI・大規模言語モデル・ナレッジグラフ・エージェント型アーキテクチャでリリース準備、クラウドネイティブサービスのオーケストレーション、継続的検証を自動化するという華やかな職務説明が付いている。
  • 私の請求額は10億ドル超だった。最初はフィッシングだと思って捨てかけたが、あまりに本物らしかったのでAWSに直接ログインし、予想請求額を見て心臓発作を起こしかけた。
    後でサポートページで障害バナーを見つけたが、肝心の「あなたは10億ドルの借りがある」と表示する請求ページに、なぜ案内バナーがなかったのか疑問だ。
  • 私もawstrack.meのURLが非常に怪しく見え、こんな警告を受けたのは初めてだったのでフィッシングだと確信した。リンクは開かずにコンソールへ入ってみたところ、請求額が誤表示される障害は出ていたが、メール警告の話はなく、むしろ攻撃者が障害に紛れて検知を逃れたのではないかと心配になった。
    ログを確認したあと、障害案内が影響範囲を漏れなく書いていなかっただけだと分かり、またコーヒーを飲みに戻った。次からはここから確認すべきだと思う。
  • 古い冗談を言い換えるなら、AWSの請求書が7万8千ドルなら私の問題だが、7,800万ドルならAmazonの問題だ。
  • 企業アカウントには3兆ドル超の請求額が表示されていた。

• 今回の不具合はあまりに absurd でじきに直るだろうが、2010年代初頭には実際の請求書に潜んでいた不具合を見つけたことがある。一部サーバーのEC2リザーブド割引の計算が誤っており、18タブあるスプレッドシートで詳細な使用量を定期的に分析しても金額が合わず、数か月かけて差分を追跡した。
  原因を突き止めた後も、AWSのシステムが間違っていると納得させるまでにかなり時間がかかり、その間も差額は積み上がり続けた。14か月後に7,000ドルの返金を受け、AWS責任者の承認が必要だったと聞いた。その後はAWS側の計算ミスを見ることはなかった。

  • 7,000ドルのクレジット自体は、当時なら近い立場のプロダクトマネージャーやディレクターでも大きな監督なしに発行できた。問題は14か月という期間で、同じ請求サイクルの修正は簡単だし直前のサイクルも面倒だがよくある一方、前会計年度まで遡って訂正するとなると財務部門を通す必要があり、はるかに苦痛だ。
  • 同僚たちは私がCost Explorerを細かく見すぎだと思っているが、妙なコストを見つけるために使う時間は、たいてい十分に元が取れて余りある。この不具合の追跡に7,000ドル分の時間は使っていないはずだし、その過程でさらに大きなコスト最適化の機会も見つけた可能性が高い。
    金を無駄にしてJeff Bezosのヨットをさらに大きくしてやるのも嫌だ。
  • 「じきに直る」と言うには、もう12時間経っている。人間がエージェントの書いて反映したコードを理解できていないようだ。

• 本来は GB of storage consumed であるべき単位が Bytes of storage consumed と混同され、2^30倍の誤りになったようです
  「計算には疑義があります。フィールド定義を参照しようとしましたが MCP サーバーへの接続に失敗し、検証の代わりに推測しました。私のミスです。ですが増えた売上を見てください！」

  • 顧客に請求する金額を計算しろとして 0.45、1.67、2.50 を渡されたのだから合計は 4.62 ですが、別の数字かもしれません。連結すべきかもしれないし、ピリオドが乗算を意味するなら 0 . 45 . 1 . 67 . 2 . 50 は 3,015,000 になります
    0 を掛けたら 0 になるはずですが、何も請求しないわけにはいかないので 3,015,000千ドル が正解です
  • 「計算には疑義があります」がパロディなのか実際の応答なのか、もはや区別すら難しいです。LLM が絶対に出せないほど愚かな文を書けと言っても、そんな 愚かさの限界 はなさそうです
  • 今日、ローカルエージェントに人間が読めるサイズ単位入りの CSV を渡して GB 区間ごとの行数を数えさせたところ、なぜか MB を GB と解釈して完全に間違えました。振り返ると Excel で直接計算 したほうが速かったはずです
  • 2*30 なら 60 なので 2,830万ドルだけ払えばよいのですが、意図していたのはたぶん 2^30 で、そうすると 1.5 ドルになります
  • 請求システムを バイブコーディング して売上を 9,000% 増やしたのだから、昇進資料としては素晴らしいです

• 朝、請求アラートのメールを見て、AWS キーを誤って漏えいして 4,370億ドル 使われたのかと思いました。幸い私にはそんな金はなく、コーヒーなしでもこれまでにないアドレナリンが噴き出したので、AWS に感謝です

  • AWS に 43万7千ドル借りているなら私の大問題ですが、4,370億ドル 借りているなら AWS の大問題です
  • この件で実際に心筋梗塞を起こしたり亡くなった人がいるかもしれません。Amazon がこういう値をそのままユーザーに表示したのは 無責任な対応 です
  • 寝ようとしていたところで警告を受けたのですが、私が設定した 16ドルの上限 を確実に超える金額でした
  • 乗っ取られたアカウントの件で AWS と 2か月間争いました。それまでの 3年間は月額使用料が約 20ドルだったのに、2万ドルを失い、さらに数万ドルの請求書まで届いたうえ、AWS は私が自力で侵害を止めるまで助けてくれませんでした
    退勤後に徹夜で AWS インフラのスクリプトを書けるようになって侵害を抑え込みましたが、アカウント閉鎖も拒否され、事例を検討するには 共同責任合意書 に署名しろという要求も拒否しました。結局、州司法長官室に連絡すると、そこから AWS に直接メールが送られ、24時間もたたないうちに AWS の管理者から電話があり、アカウントを整理して 2万ドルを返金してくれました。それでもアカウント閉鎖は最後まで拒否され、AWS から完全に抜ける方法がないように思え、最悪のやり方に感じます
  • 私の場合は 5億ドル で、手が震えすぎてパスワードすら入力しにくかったです

• アカウント担当者に予算事情を説明し、また余裕が出るまで毎月 数十億ドルずつ誠意をもって返済 していけるか寛大に見てもらうよう頼めばよいのです

  • 弱みを見せてはいけません。真正面から対処して、限度額の大きいクレジットカード を発行してもらうべきです

• 銀行に 100ドル借りていれば私の問題ですが、17億ドル借りていれば銀行の問題 です

  • 妻が前職で中堅企業のイベントを担当していたとき、イベント後の法人 Amex 残高は普通 30万ドルを超えていました。産休中に代行担当者が請求書を払っておらず、復帰したときには未払いが 50万ドル超 になっていて、Amex からのメールや留守電が山ほど溜まっていました
    メッセージは最初は丁寧でしたが、徐々に切迫していき、それでも一度も脅迫的・敵対的にはなりませんでした
  • このジョークが成り立つのは、実際に AWS に 17億ドルのコストを発生させた場合だけです。理由もなく請求書だけ発行したのなら、依然として ユーザーの問題 です
  • では、銀行に 1兆7千億ドル 借りていたらどうなるのかが次の問いです
  • Elon Musk なら当てはまらないかもしれません

• AWS は、Anthropic が使用量 0 の人に 1,600万ドル 請求したのを見て、数百万ドルで止まる理由はないと思ったようです
  https://www.techtimes.com/articles/320266/20260712/anthropic...

  • AI 請求監査スタートアップ Vaudit が企業顧客 60社の請求書 3,400万ドル分を調べ、約 170万ドルの過剰請求、つまり約 5% の誤り率を見つけたのなら、かなり深刻です

• 最近 Whole Foods で支払うとき、Chase Amazon Prime カード がもう自動で安定して認識されず、割引が自動適用されないことに気づきました。何年も問題なく動いていたやり方のまま支払って、定価を払っている顧客がどれだけいるのか気になります
  店のカスタマーサービス担当によると、この 1年ほどの間に変わったとのことで、手のひら決済機能をなくしたことによる意図しない副作用ではないかと推測していました。直接関係する話ではありませんが、Amazon がほかに何をまともに計算できていないのか考えてしまいます

  • そろそろ 集団訴訟 か、何千件もの少額訴訟を起こす番です。仲裁条項があっても、それを処理する負担は莫大なので、誰かが正しい判断をして自動返金してくれることを願います
  • 以前は単純で安定していたシステムで、こうした小さな問題が無数に起きています。すべてがバイブコーディングのせいではないでしょうが、そのうちどれだけが バイブコーディングの結果 なのか気になります

• あるときは、2万ドルの請求額が銀行口座から実際に引き落とされたことがあり、解決して返金を受けるまでに数か月と州司法長官室の介入が必要だった。その後はAWS製品を一切使わず、小さな作業もAzureへ移した
  AWSの請求問題は何年も続いており、乗っ取られたアカウントで暗号資産のマイニングサーバーが数か月間稼働し、学生に6万ドルが請求されたのにAWSが検知も遮断もできなかった事例もオンラインで簡単に見つけられる

  • AWSは事実上公共サービス事業者に近いため、請求を不注意に扱っていると、結局はそれに見合う規制を受けることになる
  • 従量課金サービスでは常に利用上限付きカードを使うべき
  • 乗っ取られたアカウントの検知が100%正確である必要はないと思う。人が直接見れば明白でも、すべてのアカウントの利用量を人間が事前に確認することはできない
  • サービス提供者を利用するうえで第一の教訓は、自動決済を絶対に有効化しないこと。利便性や割引よりも、事業者が自律的に口座の金をすべて引き出してしまうリスクのほうがはるかに大きい
  • しばらくホームラボの一部をAWSに置いていた。私は学生にクラウドを教える教室の教育者で、講師が実習用環境を作るよう勧めたので、私も無料枠のEC2にLAMPスタックのMediaWikiをインストールした。初期構成はそれほど難しくなかったが、2つの理由で二度と使わなくなった
    第一に、今日でもインターネットに公開された普通のLinuxシステムを十分に保護するのは不可能か、過度に労働集約的だった。fail2banを導入し、多くのポートを閉じても、スパム攻撃はアプリケーション層から入ってきた。第二に、請求サイクルごとにクラウド支出上限を強制することが実際には不可能だった。たいていは無料枠内に収まっていても、設定を1つ誤ったり、リソースが暴走したりすると異議を申し立てにくい高額請求が発生し、とりわけ外部ユーザーがVPCリソースや外向きトラフィックを消費するなど、自分では制御できない要因でも起こりえた。そこでアカウントを閉じ、自前設備の代わりにクラウドを強制的に使わされながら費用を制御できない企業に深く共感するようになった