サーバーレス恐怖話

(serverlesshorrors.com)

15 ポイント投稿者 GN⁺ 2025-09-08 | 6件のコメント | WhatsAppで共有

さまざまなSaaSやサーバーレスサービスで、予期しない高額請求の事例が頻繁に発生しており、それらを見やすく整理したページ
通常どおり月額サブスクリプション料金を支払っていたユーザーが、DoS攻撃や無秩序なリソース使用によって、わずか1日で数万〜数十万ドルの請求を受けた事例が明らかに
一部のサービスでは支出上限を設定していても超過料金が課されるなど、システム上の限界が浮き彫りに
開発者コミュニティでこうした経験が共有され、常識外れの課金構造と透明性の不足が主要な問題として指摘されている
サーバーレスおよびクラウド環境では、些細なミスや攻撃ひとつで莫大な金銭的損失が発生し得るため、注意の必要性が強調されている

サーバーレスおよびSaaSサービスの過剰請求事例集

#1 Webflowで発生した高額請求

月額69ドルのプランを利用していたところ、理由もなく1か月分の料金として $1,189.42 が請求された

#2 WebGLゲームサイトへのDoS攻撃事例

中規模のWebGLゲーム投稿サイト運営者が、DoS攻撃の発生後、Google Firebaseから1日で $100,000 を超える請求を受けた

#3 Vercel Proと支出上限超過

Vercel Proプランを月額 $20 で利用し、$120 の支出上限を設定していたにもかかわらず、予期しない追加料金が発生

#4 プロジェクト課金と超高額請求

月に $50 を支払っていたプロジェクトで、ある朝 $70,000 に達する請求書を受け取った事例

#5 BigQuery利用と公開データセット課金問題

Playground環境で BigQuery を使っていたところ、$22,000 を超える巨額請求が発生

#6 少ない訪問者数に対する過剰なホスティング料金

月間訪問者 9,000人 にもかかわらず月額 $250 が請求され、1年で $3,000 の支出が必要な状況

#7 Devin(AI)がコードベース変更後に起きた問題

Devinという AI がコード変更作業を行った際、予期しない結果を経験

#8 無料利用後の突然の請求

一度も支払ったことがなかったのに、ある日突然 $530 の請求が発生

#9 ドキュメントサイトおよびその他の小規模プロジェクト課金

単純なドキュメントサイトにほぼ $400 が請求されるなど、利用量の少ないサービスでも高額請求事例が多い

#10 無料ティアの恐怖

$103 程度の請求でも問題と認識される。特に無料ティア利用中の突然の請求書発生は不安要素

#11 Cloudflare、AWSおよびその他の問題

Cloudflare で24時間以内に $120,000 を支払うよう通知され、あわせてサービス停止になった事例がある
AWS S3 で空のプライベートバケットを作成した後でも、予期しない課金が発生
Netlify で $104,500 の未払い請求書を受け取るなど、さまざまなプロバイダーで類似事例が繰り返されている

#12 DoS攻撃とメール送信、データ損失

DoS攻撃中のメール送信で $11,000 を消費し、その後データベースも失われた

#13 Vercelの大量課金とアカウント、トライアル問題

Vercel でスパム攻撃により1日で $23,000 が請求され、56,000件のアカウントとトライアルが有効化された

#14 テスト/デプロイ過程での予期しない請求

テスト目的でVercelなどに機能をデプロイしたところ、予期しない金額が請求された
サイトマップ(sitemap.txt)が数百GB単位の帯域幅を使用し、高額請求が発生

#15 Firebase、Cloud Runのテスト費用

Firebase と Cloud Run のテストをたった2回行っただけで $72,000 を消費し、サービスが破産の危機に直面

結論と示唆

サーバーレスおよびクラウド環境のコスト構造は不透明であるか、攻撃やミスに非常に脆弱である
予期しない請求事例が多数報告されており、サービス運用時の慎重なモニタリングと利用量管理、許容上限の設定が不可欠
自動化やモニタリング機能が不十分な場合、単純なテストや外部攻撃一度で数万ドル規模の予期しない損失が発生し得る
開発者やスタートアップなどSaaS利用者にとって、コスト管理とリスク認識の重要性が高まっている

6件のコメント

ahwjdekf 2025-09-10

大企業の社内DW向けの開発をしていたことがあり、AWSへ既存のオンプレミスデータを移行する作業だった。しかし、数か月にわたる開発とテストを終えても、結局は頓挫した。毎月の請求額が想像以上に高くなりそうだという理由で。大企業ですらクラウド支出は簡単ではない

regentag 2025-09-08

私もAWSを勉強する目的でアカウントを作ったところ、少額ですが料金を請求されたことがありました。
アカウントが突破されて、誰かが私のアカウントでインスタンスを作成して動かしていたんです……。すぐに停止させたので少額で済みましたが。
管理に時間を割けないので、結局アカウントを削除することで対応しました。

ifmkl 2025-09-08

クラウドを始める前に、最近よく出ているn100、n150クラスでミニサーバー環境を構築して、テストや運用の経験をある程度積んでみることを勧めたいですね。

crawler 2025-09-08

どんなに小さなプロジェクトでも、ひとたびプラットフォームに載せると、脆弱性があった場合に金銭的損失につながるのは本当に怖いことだと思います。

自分のコンテンツの前段に Cloudflare を置いていたのに、ハッカーがキャッシュされていないオブジェクトを見つけて 1億回以上叩いてきた。こちらが防いだら、今度はオリジンのバケットアドレスまで直接突き止めて攻撃してきた。

こういう場合でも費用を返金してくれるのか気になります。

GN⁺ 2025-09-08

Hacker Newsの意見

自分がブートキャンプでプログラミングを学んでいたとき、elastic beanstalk のインスタンスを無料で作ってみた。本人確認のためにクレジットカードが必要だったが、当時はそれが問題になるとは思わなかった。ところがその後、自分のサーバーがボットによるスパム攻撃を受け、Amazonから10万ドルを請求された。最終的には返金されたが、その日以来Amazonが嫌いになり、クラウドコンピューティングを使うにしても別のサービスを使おうと決めた。複雑なダッシュボードや、顧客を混乱させて金を失わせるような仕組みが気に入らなかった。クレジットカードは認証手段としてだけ使い、ボットを防げば十分だったはずで、そこが残念。食料品店でクレジットカードを使って簡単にクッキーを買えることと比べると、金融技術は本当に役立つ形で使えたはずなのに、そうしなかったと思う
- これがクラウドホスティングが怖い理由の1つ。AmazonだけでなくAzureやGoogle Cloudも「たいていは」返金してくれる。でも、もし週5人しか来ない自分のデモプロジェクトが突然DDoSを受け、ホスティング会社が今回は「たいてい」ではないと言って振込を求めてきたら、破産の危機に陥りかねない
- 今まさに2万5,000ドルの料金が請求されている。以前、SQSのデータプレーン監査を有効にして、実際にはリアルタイム監査イベントフィードを接続していた。その結果、純粋な監査イベントごとに無限ループのように記録イベントが発生した。10年近く1日平均2ドルだったアカウントが、ある日突然1日3,000ドルかかるようになったのに、AWSからは何の警告も介入もなかった
- Amazonが10万ドルを返金してくれたのに、なぜ嫌うのか気になる。自分の場合、AWSでは完全に自分のミスで高額請求が出ても、いつも返金してくれた。もし「予算を超えたら全部停止する」ポリシーがあったら、「DDoSを受けてAWSがEC2を全部止めて、自分が一時ストレージに書いたデータまで消えた」という別の悲劇もたくさん起きていたはず
- 「これは1行の if 文で、アカウント上限を超えたらインスタンスを止めてサービスを静的ドライブにダンプすれば済む、とても簡単な話だ。彼らがやりたくないだけだ—顧客相手に利益を最大化するため規模を利用したいのだ。クラウドコンピュートでみんなを困らせてきた連中が、今度はAIコストでも市場獲得を追い風に経済的利益を取ろうとしている。最近エッジコンピュートが簡単になったのは、暗号資産のせいで人々がハードドライブに過剰投資したからだ。結局、市場はバブルと悪い行動に動機を与え、信頼を築く代わりに力で市場を乱用する者がのさばりやすい構造になっている。『君はただこれを理解してないだけだよ！（あ、ちなみに市場が壊れる前にもう少し金を払ってね）』みたいな狡猾な態度を取る賢い悪党たちが、業界最大の厄介者だ。タクシー会社だって目的地に行かないからといって1,000ドル請求したりはしない。サーバーに if 文を入れられないなんて話が成り立つのか疑問だ。Amazonはタクシー会社よりひどいのかという話になるが、たぶんその通りかもしれない。これがまさに『Waymo』が始まったきっかけだ（冗談かもしれない）
ホスティング/開発/デバッグにおけるサーバーレスの苦痛の話かと思ったら、料金爆発の話だった。帯域幅コストがそこまで切実ではなかったので、たいていの記事は流し読みしてきたが、これは少し面白かった—空のS3バケットがAWSの請求を爆発させうるケースでは、他人のS3に認証なしでAPI呼び出しをするだけで相手に課金を押し付けられるという話。自分には新しい内容だった
- この現象についてブログ記事が話題になった直後に対策が取られたと思う: Amazon S3、一部のエラーコードについて課金を停止
- サーバーレス環境の本当の問題点の1つは、プラットフォーム自体がブラックボックスのように不透明なことだと思う（それがサーバーレスの価値提案でもあるが）。自分たちは大規模なLambdaバックエンドを引き継いだが、シークレット拡張機能との接続時に起きる断続的なソケット切断など、プラットフォーム内部の問題が起きると追跡が本当に大変だった。ローカルのテスト環境が実際のデプロイ環境とあまりにも違うので、さらに苦しい。Google Cloud Functionsを自宅のおもちゃとして動かす分にはうまくいくが、本物のプロジェクトなら、いっそHTTPサーバーやキューコンシューマーをECSのようなコンテナに直接載せたい
- 「空のプライベートS3バケットを自分の好きなリージョンに作ったとしよう。たまたま有名なオープンソースツールの1つが、S3にバックアップを保存するのがデフォルト設定で、そこに自分の作ったバケットと同じ名前をプレースホルダーとして使っていた」という話だが、こういうことが実際どれくらい起きるのか気になる—名前衝突がどれほど頻繁なのかはよく分からない
- 競合を排除するのにこんな方法が使えるのではと思ってしまう。だからAWSはあまり好きではない。小規模顧客を不意打ちの高額請求から守ろうという努力がまったくない。Azureも大差ないが、少なくとも多少の保護策はある
- 自分も、サーバーレス、Lambda、DynamoDBにすべてを縛り付けて、実際には20ドルのVPSでsqliteを回せば済むものを大げさに使わせるようなクラウドロックインの話を期待していたが、そうではなくて残念だった
サーバーレスで本当につらいのは、1回の事故で大きな請求が来ることではなく、毎月少しずつ膨らむ料金だ。リソースを簡単に作れて、そのまま放置できる。1〜2か月ごとに数千ドルずつ増え続け、COOが気づくと全社員総出の緊急対応で料金を1万ドル未満に減らす。また繰り返す。何年も積み重なると、一度に大金を失うより大きな無駄になる
- これが事実上AWSのビジネスモデルだ。いわゆる「Planet Fitness」モデルと呼んだことはあるか？登録や課金はものすごく簡単なのに、解約はものすごく面倒にしてある
- 組織がこういう高額請求の時期からまったく学んでいないように見える。料金が増え続けた原因や、事前に防げる方法はなかったのか気になる
- こういう問題はオンプレミスでも時々起きる。使われていないアプリを動かし続けるサーバー（たいていはVM）が残る。もちろんVMのコストもゼロではない
責任の所在が不明確なことが多い。顧客は、ハードウェアインフラをクリック1つでデプロイできる魔法のようで摩擦のないツールを求める。経験のないユーザーが設定を誤って莫大な料金が発生しても、クラウド側がそのまま請求すれば評判が悪くなるし、事前にユーザーを選別して制限すればスタートアップに挑戦する小規模開発者にも門戸を閉ざすことになる。こういう場合、突然1万ドルの料金が発生したら、誰がどこまで払うべきなのか、ミスで生じたコストをどこまで負担すべきなのか、哲学的にいつも気になる。自分のコードが10倍非効率にリソースを使ってしまっても、「設定ミスならお前の責任」で済ませるべきなのか、それとも自分が使っているクラウドがAWSのような大手なのか小さなスタートアップのAPIサービスなのか、その違いまで顧客が気にしなくてはならないのか悩む
- 予算超過/サーキットブレーカー（支出上限）のような仕組みを置けばどうだろう？解決不能な問題には見えない
- 答えは実は簡単で—予算上限を設けることだ
- だからこそ、実際のサーバーの代わりにサーバーレスではない本物のサーバーを使う理由にもなる
Hetznerでは、16TBx2 HDD、1TBx2 SSD、64GB RAM、20TBの無料トラフィックを月70ドルで使える。一方、AWSのmicroインスタンスで1TBのトラフィックを使ったら150ドル払った（記憶が正しければ）。こんなことをする必要はない
「自分のコンテンツの前段に cloudflare を置いていたが、ハッカーがキャッシュされていないオブジェクトを見つけて1億回以上叩いた。自分が止めたら、今度はオリジンバケットのアドレスまで直接突き止めて攻撃してきた」という話について、こういうことは誰にでも起こりうるのではないかと思う。キャッシュされていないオブジェクトが漏れたことが、ポート22を弱いパスワードで開けておくのと同じくらい深刻なミスなのかも分からないし、S3リソース（特に画像）は誰でも何度でもアクセスできるようにするのが普通ではないのか？
- まったく違う。S3バケットは必ずプライベートにして、CDNからしかアクセスできないようセキュリティルールを設定すべきだ。そうすれば必ずCDNを通るようにできる
- OWASP Top 10の脆弱性を放置して自慢しているようなものだ。アクセス制御の設定は思うほど難しくないのに、基本的な部分でこういうミスをするなら、他の部分でも雑に済ませている可能性が高い。こういう人が責任を持つシステムは信用できない
- 基本中の基本は、S3オブジェクトをプライベートにし、少なくとも cloudfront プロキシを前段に置くことだ。画像のようなものは必ずキャッシュを通すべき
サーバーレスと呼ぶには、実際には依然としてクラウドインフラ上でサーバーを動かしている構造だ。根本的には今もクライアント・サーバーモデルに従ってソフトウェアを書いており、ユーザーが使うにはどこかでサーバーが動いていなければならない。自分の考える本当の「サーバーレス」とは、ユーザーがソフトウェアを一度ダウンロードしたら、その後はインターネットなしでも使える形だ。あるいはサーバーにデータを送るとしても、開発者が指定した特定の場所だけに依存せず機能するものがサーバーレスだと思う
- 「サーバーレス」という用語は本質的に、「負荷に応じてリソース（サーバー）が自動で増減する管理システム」を意味していて、そこが本質だ。負荷が増えればサーバーが増え、減れば減る。こうした環境に効率よく合うようコード全体の構造を変えられるときにだけ、「サーバーレス」は真価を発揮する。つまり、本当にそれが必要なときだけ使うべきアーキテクチャだ
- 一般にはそれは「ローカル」ソフトウェアと呼ぶ。「サーバーレス」という名前はあまり良くないが、実際には特定のバックエンドのデプロイ構造の話だ。バックエンド自体がないアプリのことではない
- 「サーバーレス」は、いわば「社員のいない会社」のようなものだ。実際にはサービスを提供する人はいるが、全員が契約社員として働いているだけ
- 「サーバー」とは普通、特定のOSと複数層のソフトウェア（監視ツールを含む）が載っていて、ユーザーがビジネスロジックにアクセスできるようにする単一マシンのことだ。自分でサーバーを使うなら、OS選定、支援ソフトウェアのインストールと更新、障害時の復旧など、すべてを気にしなければならない。サーバーレスは「Function as a Service」モデルなので、ビジネスロジック（自分のコード）だけ気にすればよい。サーバーにOSを入れる必要もなく、HTTPサーバーなどの基本ソフトウェアも気にしなくていい。更新や保守も不要。コードをアップロードすれば呼び出し時に実行される。サーバー運用のストレスから完全に解放される概念だ。だから「サーバーレス」という名前なのだ—実際にはサーバーはあるが、自分で運用する必要がないから
「サーバーレス」という言葉は、実際にサーバーがないという意味ではなく、サーバーを直接管理したり、自分のコードがどのサーバーで実行されるかを気にしなくてよい、という意味だ。「コードを渡すから毎時間実行しておいて。どこで動かすかは自分は気にしない」という感じ
- この言葉に違和感を覚えるかもしれないが、言語的に見ればオーウェル的な問題ではない。『1984』での「ニュースピーク」は表現の多様性を失わせる方向だったが、「サーバーレス」はむしろ新しいカテゴリを指すために作られた新語だ。もちろんサーバーの存在自体をぼかす用語ではあるが、正確にオーウェル的と呼ぶのは当たらないという意見だ。「servelet」のように「軽いサーバー」という言い方もあり得るかもしれない
- 「クラウドなんて存在しない、ただの他人のコンピュータだ」という自虐的な表現もよく使われる
- 「サーバーレス」は結局、昔の「共有ホスティング」に「1万%の利益率」と「リクエストごとの課金制」を乗せたテックブロ版にすぎない、という感じがする
- 「ノーコード」システムだって実際にはコードで動いている。PaaSだろうが何だろうが、結局サーバーがあることに腹を立てるのは言いがかりだ
AWSのサーバーレスを使ったことがあるが、ローカルテストは事実上不可能で、serverless run のためにはAWS IAM roleを必ず使わなければならず、アカウント全体に広範な権限が開いた状態だった。結局、実質的には毎回本番環境でテストしているのと大差ない大きな問題が生じる
- 自分も数年間サーバーレスのプロジェクトをやったが、ローカルでほとんど何も動かせない点が本当に大きなコストだった。デバッグ時間も悲惨なほど長くかかった。代替をうたうツールも実プロジェクトではほとんど役に立たない
- ~/.aws/credentials ファイルを適切に設定しておけば、AWSセキュリティキーでローカルテストができる。makefileでLambdaデプロイを自動化し、各LambdaごとにカスタムIAM roleを作って、セキュリティ要件をJSONファイルで管理している。AWSの本当の強みは、すべてを同じAPIで扱えることだ。programmatically にあらゆるものを作成・管理できる
- 1. スタックにまとめて開発者用の別アカウントにデプロイ（無料のステージング環境） 2) 公式サポートのDockerランタイムでローカルテスト 3) 普段どおりユニットテストを書く 4) localstack のようなツールでマシン上にステージング環境をそのままエミュレート—これだけ選択肢があるのに、そこまでひどい体験になる理由が分からない
- 事実からかけ離れた主張だ
「サーバーレス」は、いずれにせよサーバーベースのシステムを取り繕う、オーウェル的なネーミングだと思う
こういう会社が1TBの帯域幅に550ドルも取るなんて信じられない。10Gb/s保証ポート付きでサーバーを借りても、TBあたり3ドルを超えたらぼったくりだと思う。サーバーレスがどうやってこのコスト差150倍を正当化するのか疑問だ。こんな価格を受け入れる人がそんなにいるのだろうか？単に10ドルのVPSやGitHub Pagesに載せるだけでも、読書Wikiや技術文書、ブログ程度なら何の問題もなく、適切にセットアップすれば同時接続1万人だって余裕だ

benjamin 2025-09-08

今、初めて開発に飛び込む人たちがAIを使って何かを作るとき、VercelやSupabaseのようなものでサービスを運用している人が大半なのではないでしょうか?

しかし、サービスが大きくなり始めたときに彼らに支払うことになる価格は、あまりきちんと計算していないように思います。
それはそのときに考えよう、という気持ちで。

VercelやSupabaseの創業者は「そうそう、そのときに考えればいいよ!」と満面の笑みで相づちを打ってくれそうですね。

もちろん、そのときに考えても構いません。素早く抜け出せる実力があるなら。
しかし、コンピューターサイエンスに対する知識なしでは簡単ではないでしょう。
ようやく稼ぎ始めたお金を、彼らにすべて差し出す格好になりかねません。

実際、これが今起きていることです。
つまり……コンピューターサイエンスをまったく知らずに飛び込む初心者たちの金を吸い上げる大きなビジネスが開かれつつあります。

コンピューターサイエンスを深く掘り下げ続けるべき理由がここにあります。
ある人はようやく収益が出始めたサービスに月100万ウォンを使い、ある人はまったくお金を払わずにサービスを運営します。
運用コストを削減することも実力です。ものすごい競争優位ではないでしょうか?
AIでコーディングしながら何かを作って楽しさを感じるのは良いことですが、もっと深いところへ入っていこうと努力しないなら、結局は差を生み出すことはできません。

https://jeho.page/essay/2025/09/08/sucker-developer.html