サーバーレスの恐怖！無料のはずが青天井請求された話
引用元：https://news.ycombinator.com/item?id=45157110
プログラミング学習中に無料のElastic Beanstalkを使ったんだけど、本人確認でクレカ登録が必要だった。ボット対策だから納得してたのに、ボットスパムでAWSから10万ドルの請求が来たんだ。結局返金してもらったけど、それ以来Amazonが大嫌い。AWSのダッシュボードは超複雑だし、客を混乱させて金を失わせるためとしか思えない。クレカ認証でボットスパム対策できたはずなのに、それをしなかったAmazonを今でも許せないね。
これがクラウドホスティングが怖い理由だよね。AWSやAzure、Google Cloudは“大体”返金してくれるけど、俺は毎週5人しか来ないデモプロジェクトがDDOS攻撃の標的になって、ホスティング会社が“今回は例外”って言って電信送金を要求してきて破産に追い込まれるのはゴメンだよ。そんなリスクは負いたくないね。
Amazonが返金してくれたのに、まだ嫌いなの？俺がAWSをすごく評価してる理由の一つは、こんな巨額請求のトラブルがあっても、返金手続きがすごく簡単だったことだよ。君も経験したようにね。
AWSには課金制限機能があるよ。詳しくは以下のドキュメントを見てみて。https://docs.aws.amazon.com/cost-management/latest/userguide/setting-budgets.html
それは課金制限じゃなくて、ただの予算通知でしょ。本当に役立つのは、アカウント設定時にデフォルトで実質的な制限、例えば5ドルとか50ドルとか500ドルとかを設定できて、それを超えたら全プロジェクトが停止する機能だよ。俺はAWSとGoogle Cloudでいくつかおもちゃプロジェクトを持ってるけど、予算を1ドルとか10ドルに設定して通知を10％、50％、90％で受け取ってる。これは良いけど、本当の制限じゃないんだ。もしプロジェクトが攻撃されて、すぐにメールを見たり対応できなかったりしたら、まだやられる可能性がある。10ドルとか100ドル以上は絶対使いたくないから、その近くになったらすぐに止めてくれって言える方法がないのが信じられない。結論として、これらのサービスは小さな実験プロジェクト向けじゃないってこと。でも、おもちゃプロジェクトを立てる以外にサービスを学ぶ方法がなくて、破滅的な責任にさらされてるんだよね。
俺もAWSで予想より高い請求（500ドルだけど学生には痛い）を食らったことがあるから、料金モデルにイライラする気持ちはわかるよ。でも、ただ課金を止めるってのはうまくいかないと思うんだ。例えば、俺はAMIをアカウントに持ってたけど、月1ドル未満で妥当だった。でも、全ての課金を緊急停止するってなると、そのイメージを削除するしかない（500ドルのノード停止と一緒にね）。イメージ作成に数時間かかったから、それはマジでウザいだろうな。しかも、複数ユーザーがいるビジネスアカウントだったら？従業員一人が利用制限を超えたからって、会社のディスクイメージ全部削除する？ありえないね。クラウドの課金ってのは、本質的に複雑なんだよ。
もしそれが“無料枠”なら、クォータを超えた時にAmazonはアプリを停止すべきだよ。アカウントを有料枠に移行して10万ドルも請求するのは間違ってる。
たぶん、GCPやAWSの規模でリアルタイムの利用限度監視と停止を実装するのは複雑で費用がかかるから、やってないんだと思うよ。デプロイ時に各サービスに制限を組み込むこともできるだろうけど、それはお金を払いたくない客に良い体験を提供するために膨大なコードを書くことになる。良いことだとは言わないけど、俺にはそうとしか思えないね。
「銀行に100ドル借りがあるならお前の問題、10万ドル借りがあるなら銀行の問題」って言うじゃん。サーバーレスだと、俺の小さいデモアプリをAWSで動かすのに1ドルから100ドルかかるって計算で予想できる。でも、突然1000ドルの巨額請求が来て、返金を拒否され、PrimeアカウントもAWSも永久BAN、他のサービスも全部停止されるなんてことが全然ありえるけど、俺にはどうすることもできない。SNSで返金をお願いするなんて計画じゃないし、壊れたシステムの証拠だ。まるで貧しい人が子供の癌治療のためにGoFundMeを始めるような「心温まる」投稿みたいで、酷い話だよ。もっと分別を持とうよ。
VPSプロバイダなら月20ドルで24時間サーバーをオンラインにできる。利用率は1％でほとんどの場合遅かったり、バズったらクラッシュしたりするけど、それが20ドルで買えるものだ。でも、実際のトラフィック分析だと、サーバーレスならピーク時のスケーリング込みで10ドルしかかからないって言う人もいる。そしたら半額で最高じゃん！でも、もしかしたら100ドル、つまり5倍になるかもしれない。事前に知る方法がないんだ。だから、リスクに見合わないんだよ。
そうなんだよ。無料って言われたのに突然10万ドルも請求されたんだって。お金もストレスも半端ない額だよね。Amazonが返金してくれるかどうかは彼らのさじ加減だし、この処理中に自分の将来が破綻しないか不安になるって、マジでヤバいよね。
Amazonの小売アカウントを使ってAWSアカウントを作るなんて、もう何年も前からできないはずだよ。”懇願する”必要なんてないんだ。メールを送れば”はい”って言ってくれるだけだよ。
Amazonにとって費用がかかるかなんて、俺には関係ないことだよ。俺は彼らの顧客なんだから、こんなシステムは不便でしょうがない。率直に言って、従量課金制のサービスはIT業界に限らず、最大利用額の設定が法的に義務付けられるべきだね。
8年間AWSのエコシステムにいて、フォーラムやRedditで返金されなかったって報告は一度も見たことがないよ。もしAWSで予算を超えたら、AWSは何を自動ですべき？S3のオブジェクトを削除？DBやEC2インスタンスを停止？それに、請求データの収集はリアルタイムじゃないんだ。非同期で取り込まれる大量のデータと考えた方がいいよ。
”費用を返金してもらった（どうやって払うんだ？）けど、今でもAmazonが大嫌い”って、ほとんど質問もなく10万ドル返金してもらって、それでもAmazonを嫌うってどういうこと？俺もAWSで何度かミスしちゃったけど、いつも返金してくれたよ。もしAmazonが”予算オーバーしたら全部シャットダウン”を導入したら、”DDoS攻撃でEC2が全部シャットダウンして、データが消えた”みたいなホラーストーリーが山ほど出るだろうね。
それはAmazonにとってじゃなく、顧客にとって費用がかかるだけだよ。もし支出上限を超えて、彼らがあなたのデータを全部消したら、みんな激怒するに決まってる。代わりに、比較的簡単なチケットを出して、間違って使いすぎた理由を説明させるんだ。これは顧客がより楽になるように、AWSが選択したエンジニアリング上のトレードオフなんだよ。
”課金を止める”って考え方は違う。課金を止めるんじゃなくて、設定した上限を超えて料金が溜まっていくサービス提供を止めるんだよ。短期間で支払いを済ませたり、サービスを修正する時間も必要だね。課金は続けてもいいけど、設定した上限を超えて無制限に請求が積み重なるのを止める方法が欲しいんだ。クラウド請求は複雑だって言うけど、もっとシンプルにできるはずだよ。課金を引き起こすものを止めるか、制限するか、上限を設けるオプションが欲しいだけなんだ。
だから俺はプリペイドカードとか、簡単に利用を停止できるカードを使うのが好きだよ。
Amazonが無制限のクレジットを許可するのは無責任だよ。最低でも、厳しい請求上限を設けるべきだね。
インターネットに何かを公開するのは危険だよ。パブリックなエンドポイントを安全に守る準備ができていないなら、最初から作らない方がいい。
彼らはこの件について経済的に現実的だよ。もし君のミスで現実的に10万ドルを回収できないなら、「イエス」って言うってこと。
AWSで9年働いてきたけど、個人でも大企業でも、高額なミスをした時にAWSから返金やクレジットがもらえなかったって話は、聞いたことも読んだこともないよ。Redditのサブレディットでもそんな報告は見たことないね。
カードを凍結しても借金が消えるわけじゃない。取り立てされる可能性はあるよ。
家の電気を契約して隣人が盗用したら、電力会社は数千ドルを請求してくるし、返金には警察の報告書が必要で大変だよ。水道管が壊れて水が漏れても、水道会社は請求するし、修理費用も数万ドル要求される。それで破産しても気にしない。だから、コンピューティングのユーティリティプロバイダーに、なんで違う対応を期待するの？
過剰請求後の返金は、企業にとって税控除になるメリットがあるんだ。彼らにとっては少額でも、積み重なれば大きい。高額な薬の「クーポン」も同じような仕掛けだよ。1,000ドルの薬に90%割引をしたら、900ドルを税控除できるってわけ。
＞複雑なダッシュボードが顧客を混乱させてお金を失わせるためだ、って言うけど、それだと認定資格がある技術はどれも複雑すぎるってことになるの？システムは分散型だから全体像を示すのはミス防止に役立つよ。交通の免許も複雑すぎるから偽の学位ってことになる？
つまり、「料金発生率」に上限が欲しいってこと？例えば、料金は積み立てられるけど、1秒あたりの料金を追跡して、上限を超えそうな場合は新しいサービスを起動させないようにするとか？一時的に高い料金が必要な場合もあるけど、このアイデアは理にかなってるよ。
”裁判長、彼らは無料プランの本人確認のためにクレジットカードを提供しました。そして今、我々は10万ドルを回収したいのです”
＞ただ請求を止めるのはうまくいかない、って言うけど、ごめん、これは完全にデタラメだよ。彼らはデフォルトの上限を1兆ドルに設定して、それを5ドルに下げるオプションを提供できるんだ。そうしない理由はあるけど、よく聞くようなデタラメな主張じゃない。
ユーザーが耐久性や無料枠での設定を明示的に選べるようにするべきだね。デフォルトは「あまり耐久性がない」とかでいいんじゃないかな。
クラウドで遊ぶとき、料金が怖いからいつも自宅IPだけにアクセスを制限してるよ。サンドボックス環境がもっと気軽に作れるようになればいいのにね。A Cloud Guruのトレーニングでは30分限定のAWSインスタンスが生成されてたな。あれは良かった。
もっとコメントを表示（1）
てっきりサーバーレスでの開発やデバッグの苦労話かと思ったら、料金オーバーランの話だったんだね。S3バケットへの許可されていないAPI呼び出しでコストを上げる方法もあるらしいよ。知らなかったな。https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-c…
料金オーバーランの話だったって、ほんとそれ！Lambdaバックエンドのチームにいたけど、サーバーレスの「不透明性」が、深いレイヤーでのバグ（ソケットのハングアップとか）を見つけるのをすごく困難にしたんだ。ローカルでのテスト環境とデプロイ環境も全然違うし。個人的にはGCP Functionsも使うけど、プロの現場ならECS上のコンテナを選ぶかな。
Azureのサービスでも同じような経験があるよ。ブラックボックスすぎてトラブルシューティングなんて不可能。最初は気づかないような予期せぬ挙動も多いし。大事なものについては、もうKubernetesにデプロイする苦労を受け入れたよ。結局、そっちの方が開発者も好むことが多いしね。
最近、顧客がContainer Registryをファイアウォールで保護しようとして、全部ぶっ壊しちゃったんだ。なんとか動くようになったけど、Container RegistryやApp Serviceがどこからデータをプルしてるのか、いまだによくわかってないんだよね。提案された解決策が本当に機能するのかも怪しいし。
まったく、彼らはIPv6を導入したものの、NATしてるんだよ！これじゃあ、このプロトコルの唯一の目的が完全に台無しじゃないか。このひどい「ソフトウェアエンジニアリング」には、もう言葉も出ないよ。
AWS Lambdaと、ちっちゃなマシンを24時間動かしっぱなしにするコストを比較するたびに、結果はいつもマシンを常時オンにする方が有利になるんだよね。Lambdaに適したワークロードもあるけど、REST APIを「スケールする必要があるから」って理由だけでLambdaに突っ込む人が多すぎるのとは全然違うよ。
みんな、主にサービスのローカルモックでテストや開発をしてるの？それとも、開発者やフィーチャーブランチごとに名前空間を分けたアプリのミニコピーをデプロイして、本番に近い環境で作業してるのかな？後者だと常にオンラインじゃないとダメだけどね。
ローカルで動かせないと生産性めっちゃ落ちるよな。開発者がAWSコンソールでLambdaのコード直接いじってるの見たことあるけど、あれ最悪だわ。デプロイのたびに時間無駄にしてる感じ。
Mocksって結局本番と違う動きするんだよな。大抵は小さい開発環境で試すけど、変なバグ出るとサーバーレスがシンプルどころかマジで厄介になる。
ローカルでちゃんとログ見たり、デバッガー付けたり、strace使えたりしない環境なんて悪夢だろ。マジで不安になるわ。
SSTって開発体験が最高なんだよな。実際にサービスをデプロイして、Lambdaの代わりにローカルにリクエストを転送するプロキシを使うんだ。完璧じゃないけど、ローカル変更後の更新が「瞬間」で、これ以上のものはないと思う。
あのブログ記事がバズってすぐ、AWSはS3の仕様を変更したと思うよ。
https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3…
2015年くらいにAWSに同じ問題提起したけど、「お前らの問題だろ」って言われたわ。S3バケット削除したら請求止まるかと思ったら、数週間後にまた請求来たし。結局その後、連絡来なかったけどさ。
S3が始まってから18年間で、どれだけ多くの人がこの問題でこっそり被害を受けたんだろうな。あのバズった記事がようやくAWSに対応を促したって感じだよな。
403エラーの請求先とか、攻撃で適当なバケットにアクセスされたらどうする？って、興味深い見落としだよな。きっと会議室で「誰に請求する？」って揉めたんだろうな。
見落としが、サポートレベルだと「期待される挙動」になるんだよな。「AWSが例外としてS3の請求をキャンセルしてくれた」っていうけど、その言い訳はマジで時空を超越するレベルのクソさだわ。
このひどい臭さにPooperも怒ってるぜ。企業でのテクノロジーってマジでクソだな。CTOとかへのキックバックでもない限り、こんなの納得できる説明ないだろ。
職場でうんこするのと、それを「客への恩返し」として売りつけるのは全然違うゲームだよな。
このレベルではキックバックとか不要だね。みんな6ヶ月の収益と市場シェアで判断されるんだから。
これは「サーバレス機能はあんたの持ち物でしょ！」って正当化された、単なるごまかしの詐欺だよ。
開発者はこのシナリオを想像してなかっただろうし、クレーム受けたサポートも忙しくて開発者に伝えられなかったんだろうな。
プロジェクトマネージャーとしては、会社が損するような修正をDevsに指示したくないってのが本音だろうし！
デタラメだよ。開発者の中に、このシナリオを想像して懸念を表明した奴が一人もいなかったなんて信じられないね。
競合をぶっ潰す方法。素晴らしいね。俺がAWS嫌いな理由もこれ。
AWSはSMB顧客を予期せぬ請求から守る気ゼロ。Azureも大して変わらないけど、まだ多少は保護策があるかな。
俺もだよ。悲惨な話とかクラウドロックイン、月20ドルのVPSとSQLiteで十分なものをLambdaやDynamoDBで無理やり使う羽目になった話なんかを期待してたんだ。
Webflowの話だけど、画像を安いサービスにオフロードできないってのが興味深いね。別のドメインを使えば回避できるかもだけど。
脆弱なOSSツールのメンテナーに発見を報告したら、すぐデフォルト設定は直してくれたけど、既存のデプロイは無理だったって話。
このOSSツールが何だったか誰か知らない？開発者が incompetent に見えるから、可能なら避けたいんだよね。
空のプライベートAWS S3バケットを作ったら、人気OSSツールのバックアップ設定が、そのバケットと同じ名前を使っていたって話。そんな偶然あるの？（本当に知りたい。名前の選び方ってどうなってんの？）
クラウドの誤設定やDDoS攻撃の責任の所在って興味深いよね。原則なくて全部状況次第。
顧客は手軽なツールを求めるけど、未経験だと高額請求に。でも審査すると「門番」って批判されるジレンマ。
もし俺が1万ドルのサプライズ請求を食らったら、どこまで払うべき？誤設定のせい？コードのせい？プロバイダーは関係ない？
AWSでミスを免除してもらったプロバイダーが、俺にはきっちり請求するのって公平？って考えるの楽しいんだよね。
解決策は簡単、予算の上限（バジェットキャップ）を設定すればいいじゃん。
それって簡単かな？上限に達したらAWSがリソース削除してアプリを壊すわけ？Hacker Newsでひどい話になりそうじゃん。
それとも単に503を返すとか？なんでいきなり破壊することになるの？
もっとコメントを表示（2）
支出の上限（スピーディングキャップ）とか、サーキットブレーカーはどう？解決できない問題には思えないけど。
半分正解。リアルタイムで正確な請求は無理だから、上限を超えてる可能性もあるよ。でもAWSには予算（バジェット）と予算アクション（バジェットアクション）があって、IAMロールを編集して高額なアクションを拒否できるんだ。Bedrockコストに悩む顧客にTerraformで設定した経験があるけど、前準備に48〜72時間かかるのが大変だったね。
上限設定しすぎると、うまくいってる中小企業を潰す人になっちゃうね。AWS時代、酷い設計の顧客が「広告通り動いた結果の7〜8桁の損失」をAWSに補填してほしいって言ってたよ。中小企業は自分の過ちの責任を取りたくない以外、何を求めてるか分かってないことが多いね。
サーキットブレーカーは100%正確じゃなくてもいいんだ。Amazonにとって遅延による過剰な運用コストが無視できるくらい、検出が速ければいいだけ。そんなに難しいことじゃないはずだよ。
それはきっと、上限を低く設定しすぎたユーザーのせいじゃないかな。サービスを完全に止めるより、上限に近づいたらレートリミットをかける方が良いかもね。
AWSの全部がWebアプリってわけじゃないよ。
そうかもね。でもそれがサーバーレスじゃなくて物理サーバーを使う大きな理由になるんだよ。
課金上限を超えたら、AWSはどうやってストレージを削除せずに利用を止められるの？
その理屈だと、レート制限なしでアプリ作ったユーザーのせいじゃね？
ストレージを消す必要なんてないじゃん。上限超えたら受け付けなきゃいいだけじゃん。
Amazonは2.5兆ドルの大企業だよ。このスレの例なんて、サーキットブレーカーなしでもAmazonにとっては取るに足らないレベル。AWS全体にその機能を実装するより、ランダムな10万ドルの請求を返金する方がはるかに安上がりだよ。
3日で1000ドル超えて強制シャットダウンか、1万ドル請求か。ビジネスによってダウンタイム価値は違うよね。
だからユーザーが設定できる利用上限が一番。新規アカウントは低上限で、設定まで消せない赤いポップアップを出すとかね。
でもAmazonは利益が減るからやらないんだよ。不注意な客から稼ぐ方が、企業イメージより儲かるって判断したんだろうね。FAANG規模に企業イメージは無価値だし。
検討してないわけないし、みんな懇願してる解決策だよ。実装しないのは純粋な貪欲さと悪意だね。
実際のサーバーも帯域料金とかあるから、完全に解決するわけじゃないんだよね。
こういう議論する人ってみんな、ネット上のサイトは営利目的って思い込んでるけど、実際はほとんどのサイトは利益追求してない非営利なんだよね。そういう場合、絶対サービスを停止してほしいって思うはずだよ。
ストレージの課金は一部時間ベースだよ。EBSは秒単位で課金されるし（最低1分だと思うけど）。顧客が課金上限に達したら、AWSはそのストレージをタダにするか、請求額が増え続けるか、ユーザーデータを破壊するしかないんだ。
ハードキャップが欲しいなら、すでにできるよ。UXのチェックボックスにはないけど、機能としては用意されてる。
障害じゃなくて、帯域幅やリクエスト数の上限を設ければいいんだよ。昔のサーバーみたいに、固定の最大帯域と予測可能な料金があった頃と同じようにね。
請求上限を設定できないのに、高額な請求が発生する可能性があるフリーティアを宣伝するのは誤解を招くよね。
TCPセッションを閉じるとか、UDPの応答を返さないとか、衛星通信機のアカウントの時間を停止するとか、そういうのはどう？上限対策の具体的な方法を提案してるのかな。
良い解決策はいくつかあるはずだよ。AWSが提供してる他のソリューションは、トレードオフや曖昧な要件の中で選ばれたものだよね。これは技術的に不可能なんじゃなくて、AWS側のインセンティブがずれてるんだよ。もしそれで儲かるなら、とっくに提供してるはずだし、製品の欠陥は単なる技術的な問題じゃないんだ。
そうだね、それがまさに期待される挙動だよ。しきい値に近づいたらアラートを出すこともできるしね。俺から見ればすごく簡単だよ。
ストレージの予算オーバーは想像できるけど、このページの“恐怖”はほとんどがComputeかAccessが原因だね。マシンは削除されてもEBSボリュームは残るとか、S3バケットはロックアウトされてもデータは安全とか、そういう設定にすればいいのに。
彼らは返金も拒否するよね。顧客が不満でも、それが利益になるからさ。もし予算上限を設けることで彼らにすごく利益が出るなら、とっくにやってるはずだよ！彼らがこのゲームに興味がないのは明らかだね。
UDPに言及してるのは興味深いね。俺は今、UDPを扱うサービスにハードリミットを追加してるんだ。簡単じゃないけど可能だよ。AWSに文句を言う人には同情しないけど、自分のサービスには追加する価値があると思ったんだ。俺のマーケットはExperimenterやEarly Stage Project向けだから、AWS（巨大ユーザーからの収益が主）とは違うけどね。だから、AWSが“Buyer Beware”のスタンスなのもわかるよ。
「簡単なの？上限に達したらAWSがコスト発生元のリソースを削除してアプリをぶっ壊すの？」って聞くと、「難しいから上限がない」って言ってるように聞こえるね。「ハードキャップが欲しいなら、もうできるよ…機能はある」って言ってたけど、どんなテクニックを考えてるの？
昔からそうだったように、リクエストを受け付けなければいいだけじゃないの？
AWS上のものは、APIが何であってもリクエストを拒否できるんだよ。
