7月17日、世界中のAWSユーザーがコンソールを開くと、数百万ドルから数十億ドル、さらには場合によっては数兆ドル規模の請求見積額が表示されていた。通常の利用料金が月5ドル未満のあるアカウントでは、17億ドルの見積額が表示された。あるRedditユーザーは、2,255億7,921万164.83ドルの請求額を示すスクリーンショットを投稿した。 別のダッシュボードには、当月累計の請求額として7.1兆ドルが表示されていたが、これはAmazonの時価総額の2倍を超える金額である。これらの数値は誤りであり、実際の請求書には一切影響がなかった。しかし、この障害は24時間以上続いた。そして、その異常な金額そのものよりも、この問題がどのように発生し展開したかの方が、クラウドのコスト管理について多くのことを示している。
（出典：RedditのAWSスレッド）
AWS Health Dashboardによると、この問題は7月16日午後7時46分（PDT）に発生した。請求額計算システムの設定変更によって、見積請求額の処理パイプラインに単価計算の誤りが持ち込まれたのである。その後に起きたことこそ、実務担当者が注意深く読むべき点である。AWS自身の説明によれば、次のような状況だった。
7月16日午後7時46分（PDT）、当社のアラームがコスト異常を検知しました。しかし、推定請求額の生成プロセスを停止できず、エンジニアリングチームへの通知も行われませんでした。その後、7月17日午前0時19分（PDT）にお客様からのエスカレーションを受けて本件を認識し、直ちに調査を開始しました。
アラームは作動したにもかかわらず、請求額生成パイプラインは動き続け、エンジニアにも通知されなかった。顧客からのエスカレーションがAWSに届いたのは午前0時19分で、自社の検知システムが異常を検知してから4時間半後だった。つまりAWSは、自社の請求システムに問題が発生していることを顧客からの指摘によって把握したことになる。これはAWSで想定外のコスト増加が発生した際に、多くのチームが問題を認識する典型的なパターンそのものだ。ただし今回は、その立場が逆だった。
「単価計算」の不具合という根本原因の背景にある仕組みは、この種の不具合を実際に引き起こした経験のあるエンジニアにとっては見慣れたものだ。Hacker Newsのあるコメント投稿者は、AWSでの実務経験に基づき、請求処理パイプラインが計測データと料金プランをどのように結び付けているかを次のように説明している。
私はAWSでこの種の不具合に対応した経験があります。これは単位に関するミスです。私が担当したケースでは、本来は1GB当たり5セントを請求する設定にするはずでしたが、単位である「GB」が設定から漏れていました。その結果、請求システムが既定でバイト単位を適用しました。データ転送量1バイト当たり5セントで計算されたため、一部のお客様には数時間のうちに数百万ドル規模の請求額が表示されていました。私は午前2時ごろにサポートチームから連絡を受け、午前3時から4時ごろまでには修正と請求額の訂正を完了しました。その後まもなく、お詫びのメールを送付しました。
サービスは価格情報を持たない計測データを出力する。コメント投稿者によると、各請求明細は料金プラン内で単位種別とともに定義されており、その単位種別を誤ると換算処理が正常に機能しなくなる。今回のインシデントとの違いは対応時間にある。前述の事例では、担当者への通知から修正完了までおよそ2時間だった。一方、今回の事例では異常を検知してから4時間半が経過するまで、顧客からのエスカレーションがAWSのエンジニアに届かなかった。
別のコメント投稿者は、この種の障害がなぜテストで見逃されるのかについて、構造的な理由を次のように説明した。
テストは実施されていたはずですが、エンドツーエンドのテストが不足していたのでしょう。テスト1では、新しいシステムが想定どおりに請求データを出力することを確認します。テスト2は請求システム側で実施されます。しかし、両者を組み合わせてテストすることはありません。そのほうが難しく、チームごとに管理系統が異なるためです。私は複数の企業で同じような事例を何度も見てきました。
対応策によって、皮肉な状況はさらに深まった。設定変更をロールバックしても問題を解消できなかったため、AWSは午前8時24分（PDT）に推定請求額の生成を停止した。その結果、実際よりも大幅に膨らんだ請求額がそのまま固定された状態となった。さらに予防措置として、予算アラートとコスト異常検知アラートも無効化した。つまり、この期間中はAWSがコスト管理の安全網として推奨している2つの仕組みが、プラットフォーム全体で利用できない状態となった。SlackへのエスカレーションからSCPの適用、ワークロードの停止まで、これらのアラートに連動した自動対応を設定していたチームは、停止前に誤ったデータによって不要な対応を引き起こされたか、停止後は異常を検知できない状態に置かれた。
Hacker Newsのスレッドは、17億ドルという推定請求額を表示されたアカウント保有者の投稿から始まった。
通常の利用額は5ドル未満です。言うまでもなく、AWSサポートに緊急対応のチケットを作成しました。同じような状況になっている方はいますか。
The Duckbill GroupのチーフクラウドエコノミストであるCorey Quinn氏は、LinkedInへの投稿でこの金額の大きさを次のように表現した。
私はAWSとの契約交渉で総額数百億ドル規模の案件を扱ってきましたが、顧客の請求額が1兆ドルに達した例は一度もありませんでした。それをCost Explorerチームは、一晩のうちに数千のアカウントで実現してしまったのです。 クイン氏はまた、このインシデントがコスト管理チームに与えた運用上の困難についても言及した：
Quinn氏は、このインシデントによってコスト管理チームが直面した運用上のジレンマについても言及した。
昨夜、「ベースライン比で＋55,000,000,000％」という異常検知アラートを受け取り、それが単なる不具合なのか、それともus-east-1で本当に何か新しい事態が発生しているのかを判断しなければならなかったすべてのFinOps担当者に同情します。
一部の顧客にとって、その影響は単なる朝の混乱では済まなかった。OpenValueのソフトウェアアーキテクチャコンサルタントであるPiet van Dongen氏は、表示された金額を信じ、その数字に基づいて実際に行動してしまった経験を次のように語った。
予算超過アラートのメール通知を受け取り、その後Cost Explorerで個人プロジェクトのS3コストが369,188,086.24ドルと表示されているのを確認しました。正直なところ、その数字を10分ほど本物だと思っていました。実際にサポートケースも登録しました。ひとまずすべてのワークロードを停止しており、今後再開するつもりはありません。
ソフトウェアエンジニアリング部門のリーダーであるDaniel Blumenthal氏は、8430億ドルという推定請求額を見て、AWSの顧客が10年にわたり指摘してきた課題との関連を次のように語った。
アカウントがハッキングされたのだと思いました。心臓発作を起こしそうな気分でした。アラートは設定できるのに、アカウントに利用上限を設定できないという事実は非常に恐ろしいと思います。
同じスレッドでは、単なる混乱を超えた、より長期的な懸念も示された。あるコメント投稿者は「AWSが明らかに異常な巨額請求を発生させるようなミスをするのであれば、もっと分かりにくい形でミスをして、多くの人が気付かない程度の少額を上乗せ請求し、そのまま支払われてしまう可能性も否定できない」と指摘した。途方もない金額の誤請求は誰の目にも明らかだ。しかし、もっともらしい金額であれば気付かれない可能性がある。
クラウドコストに関する議論を追っている者にとって、このタイミングは不都合極まりない。InfoQはこの事件の数日前に、同様のパターンを報じていた。実務家たちが、AWSの請求データが実際の支出より約24時間遅れていること、予算管理がどのようにその遅延したデータに基づいて評価されるか、そして実際の事案における検知がAWSではなくクレジットカードから行われたことを記録していたのだ。 今回の請求見積もりに関するインシデントは、その失敗を逆転させたものだ。今回は、データが遅くて正確だったのではなく、速くて間違っていたが、構造的な教訓は同じである。請求テレメトリは独自の障害モードを持つ依存要素であり、自動化されたコスト管理はそれらのすべてを継承している。
AWSは問題を解消し、表示された推定請求額が実際の請求額を反映したものではなかったことを確認した。ただし、同社はHealth Dashboardに掲載した時系列情報を超える詳細な事後検証レポートを公開していない。また、アラーム検知から対応開始までの空白時間、ロールバックの失敗、あるいは予算アラートをプラットフォーム全体で無効化した判断を受け、請求処理パイプラインの保護策を見直すかどうかについても明らかにしていない。異常なコスト発生を他者に警告することを役割とするシステムにおいて、残された疑問は、そのシステム自体に異常が起きたとき、誰がそれを警告するのかという点だ。