ハクソク

世界を動かす技術を、日本語で。

サーバーレスの恐怖

260日前原文(serverlesshorrors.com)

概要

ServerlessHorrorsは、 サーバーレスの失敗談 を集めたブログ。 作者のAndrasは Coolify というOSSのPaaSを開発中。 Heroku / Netlify / Vercel の代替として自分でホスト可能。 読者は GitHubのPRで体験談投稿 が可能。 代表的な事例として 高額請求やDDoS被害 が紹介。

ServerlessHorrorsの概要

  • サーバーレス利用時の 恐怖体験談 を掲載するブログ
  • 制作者は Andras、Coolifyプロジェクトの開発者
  • Coolifyは Heroku / Netlify / Vercel のOSS代替サービス
  • 読者による 体験談投稿 はGitHubの Pull Request で受付
  • 新着記事や過去記事の 日付一覧 を掲載

主なサーバーレス失敗事例

  • 2025年5月13日 など新着記事の定期更新
  • BigQuery のパブリックデータセット利用で $22,639.69 の高額請求
    • Google BigQuery、SQLの誤用やコスト見積もりミス
  • Vercel 上のEchoFoxサービスが DDoS攻撃 を受け、 $23,000.42 の請求
    • 帯域使用量急増、56,000件以上のアカウントおよびトライアル発生
  • サーバーレスのコスト管理やセキュリティリスク の実例として紹介

サイトの目的と投稿方法

  • サーバーレス利用者の 注意喚起 と体験共有
  • GitHub経由 で誰でも 体験談を投稿可能
  • サーバーレスの 落とし穴やリスク を広く周知する目的

Coolifyについて

  • オープンソース かつ セルフホスト可能 なPaaSプロジェクト
  • Heroku / Netlify / Vercel のような使い勝手
  • サーバーレスに頼らず 自分で管理・運用 したいユーザー向け

まとめ

  • ServerlessHorrorsは サーバーレスのリスク事例 を集約
  • 高額請求やDDoS など現実的な問題点を共有
  • Coolify のような選択肢も紹介し、利用者のリテラシー向上を目指す

Hackerたちの意見

Vercelのストーリーをちょっと見た感じだと、全ての支払いが無効にされたか、最初からミスだったみたい。こんな請求書を本当に払わなきゃいけないことってあるの？ツイートしないと返金されないのかな？

└

ツイートしないと返金されないの？ これが怖いんだよね。今ってソーシャルメディアが物事を解決する唯一の手段なの？ フォロワーが少ないし、そもそもアカウントも持ってない場合、請求書を我慢しなきゃいけないの？

└

いや、こういうホスティングのエンタープライズコンサルティングでは、通常サポートチームに直接連絡できる担当者がいるよ。ただ、こういうプロジェクトはオラクルのライセンスの丸め誤差を超えるような方法で測定されるから、誰がティア1の扱いを受けるかで市場がセグメント化されちゃうんだよね。

└

サポートエージェントの機嫌に頼るのは良くない戦略だよね。

└

開発者が10万ドルの請求を受けたら、たいていは銀行が最初にそれを拒否すると思うよ。特にクレジットリミットが高くない場合はね。でも、もしこれが法人アカウントに起こったら、どこかでリソースが漏れたらどうなるんだろう？数十億ドルの会社なら、たぶん「運営費用」として片付けて終わりだろうね。

└

私が参加しているコミュニティグループの誰かが、Azureの非営利向けの無料プランで遊んでて、1,200ユーロくらいの損失が出ちゃった。大きな額ではないけど、私たちには大きい。HNのコメントに励まされて、サポートにお願いしてみたんだけど、何度かお願いした後、最終的に請求額を100ユーロ未満に減らしてくれたけど、全額免除はしてくれなかった。だから、SNSで恥をかかせなくても、やっぱり頼んでみる価値はあると思う。^そのプランは約6ヶ月前に変更された。

てっきり「サーバーレス」のホスティングや開発、デバッグの恐怖についてだと思ったら、価格オーバーランの話だった。サイトを適当にスクロールしてたら、大半の投稿は無視しちゃったけど（帯域幅の請求書ってあんまり面白くないし）、これだけは見たよ：https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-c... 自分が持ってないS3バケットに対して認証なしでAPIコールをしてコストを上げる話。これは新しい発見だった。

└

競争相手を潰す方法。好きだな。あと、AWSが嫌いな理由でもある。サプライズ請求から中小企業を守る気ゼロ。Azureもあんまり良くないけど、少なくとももう少し保護策がある。

└

あのブログ記事がバイラルになった後、すぐに変更されたと思うよ：https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3...

└

「サーバーレス」のホスティングや開発、デバッグの恐怖についての話だと思ったけど、実際は価格オーバーランの話だったね。それには同意するよ。大規模なAWS Lambdaのバックエンドを引き継いだチームに雇われたんだけど、基盤となるプラットフォームの不透明さ（これがサーバーレスの価値提案なんだけど！）が、厳しい状況になったときにすごく痛い思いをさせるんだ。システムのそのレイヤーに近いところでバグを見つけると特にね（うちの場合、シークレット拡張に接続しようとしたときの間欠的なソケットのハングアップがあった）。それに、ローカルのテスト環境がデプロイされた環境とほとんど似てないから… 家ではGoogle Cloud Functionsでちょっとしたおもちゃのようなものを動かしてるけど、ちゃんと動いてるよ（スケール・トゥ・ゼロは無料枠で隠れるのに便利だし）。でも、プロの環境でHTTPサーバーやキューコンシューマーをECSのコンテナに入れる方がいいと思わないシナリオは想像できないな。

└

同じく、LambdaやDynamoを使わざるを得ない悲惨な話や、クラウドロックインの話を期待してたんだ。$20/月のVPSで簡単に動くものなのにね。

自分のものの前にCloudflareを置いてた。ハッカーがキャッシュされてないオブジェクトを見つけて、100M回以上ヒットした。それを止めたら、今度はオリジンバケットを見つけて直接ヒットしてきた。無知をお許しを、でもこれは誰にでも起こりうることじゃないの？キャッシュされてないオブジェクトって、ポート22を弱いパスワードで開けっぱなしにするほど深刻なことじゃないよね（そうなの？）。それに、S3のリソース（画像とか）は公開されてるから、誰でも好きなだけアクセスできるんじゃないの？

└

いや、S3オブジェクトは常にプライベートであるべきだし、少なくともCloudFrontのプロキシを前に置くべきだよ。画像みたいなものは、常にキャッシュを経由してアクセスされるべきだね。

└

いや、バケットはプライベートにしておくべきだよ。セキュリティルールを設定して、CDNプロバイダーだけがアクセスできるようにするのが大事なんだ。そうすることで、CDNを使うことが強制されるからね。

└

この話は「OWASPのトップ10脆弱性をコードに残しておくのはハッカーの考え方」って感じだね。アクセスコントロールを設定するのはそんなに難しくないのに、他の部分でも手を抜いてるんじゃないかな。この人が担当してることは全く信用できないよ。

「サーバーレス」って、サーバーがあるシステムのためのオーウェル的な名前だよね！

└

それは本当だね！

└

「クラウドなんてない、ただ他人のコンピュータがあるだけ」

うん、僕もコストがあちこちから跳ね上がったから、Google Cloudにホスティングしてた自分のウェブサイトを放置したよ。基本的にコストを制限するための機能がないから、バグがどれだけの金額になるか分からないのに、リラックスして眠れなかったんだ… 実際はぐっすり寝てたけど、ポイントは分かってくれるよね。OPのウェブサイトにあるように、支出管理には予算通知があって、それを使えばAPIコールか何かでプロジェクト全体の請求を無効にできるんだ。正確には覚えてないけど、それがすべてだよ。でも、やっぱりその機能がないみたいだね。

使った分だけ支払う製品をオープンなインターネットに置くのは、いつも狂ってると思ってた。特にスケーリングが有効な場合はね。せめて、流出を制御するためにレート制限された製品を前に置いてほしいな。（それに、そのレート制限された製品自体が使った分だけ支払うものかどうかも確認してね…GCP、君のことだよ）

ブートキャンプでプログラミングを学んでた時に、クレジットカードが必要な無料のElastic Beanstalkインスタンスを立ち上げたんだ。身分証明のためにクレジットカードが必要なのは理解できるけど、ボットがクレジットカードをスパムすることはできないからね（そうじゃないと金融詐欺になって、ほぼ確実に重罪になるし）。そしたら、サーバーがボットスパムにやられて、アマゾンから10万ドル請求された。請求書を返金してもらったけど（どうやって払うつもりだったんだ？）、今でもアマゾンが大嫌いだし、もしクラウドコンピューティングを使うことになったら、絶対に他の会社を使う理由はこれだよ。あの恐ろしく複雑なクリック式ダッシュボード（でも認証が取れるよ！あまりにも複雑だから、偽の学位を作ったんだ！）は、顧客を混乱させてお金を失わせるためのものだと思ってる。クレジットカードを認証に使ってボットスパムと戦う良い企業市民になるチャンスを逃したことを今でも恨んでる。でも、スーパーに行くと、クレジットカードをスワイプしたり、挿入したり、チップを使ったり、手のひらで読み取ったり（これ、今や本当にあることなんだ）してクッキーを買うことができるのにね。金融技術を何か有用なことに使うのではなくて。

└

だから、プリペイドカードや簡単に凍結できるカードの方が好きなんだ。

└

アマゾンから10万ドル請求された。LOOOOOOOOOOL 会社を通じてAWSの入門コースを受けたんだけど、画面の向こうの人がやってることをひたすらコピーするだけの1時間が本当に苦痛だった。うまくリンクしてるかのフィードバックもなく、遅延も信じられないくらいだった。最後に、VOILA！全然動かないし、「先生」も理由がわからなかった。マジでクソだわ。クラウド/サーバーレスは、システム管理ツールを設計したけど、システム管理者もデザイナーもみんなバカだったらどうなるかって感じ。アメリカ：「聞いてるよ」 クラウド/サーバーレスに対する嫌悪感は、LABViewに対する嫌悪感と同じくらい深いと思う。実際、LABViewをネットワーキングに再利用した方が、Azureがやったことよりも良い結果が出ると思う。

└

あの恐ろしく複雑なクリック式ダッシュボード（でも認証が取れるよ！あまりにも複雑だから、偽の学位を作ったんだ！）は、顧客を混乱させてお金を失わせるためのものだと思ってる。そういう論理なら、認証が取れる技術は全部複雑すぎるってことになる？今のほとんどのシステムは分散型で、設計された通りに機能する全体像を提示することは、単純なミスを防ぐのに役立つことがあるよ。交通も認証（ライセンス）が必要だし、これも偽の学位だよね。だって、あまりにも複雑にしてるから。

└

ワークショップのクラスを受けたんだけど、トラックソーのセットアップを教えられたんだ。でも、ちゃんと使い方や自分を守る方法は教えてくれなかった。結局、指を失っちゃったよ。スタンレーの工具が本当に嫌いで、もしまたトラックソーを使うことがあったら、他のメーカーのを使うつもり。

└

これがクラウドホスティングが怖い理由の一例だよ。そう、アマゾンや、たぶんAzureやGoogleのクラウドも「通常は」返金してくれるけど、週に5人しか訪れないデモプロジェクトが突然理由もなくDDoSの標的になって、ホスティング会社が「これは通常じゃない」と判断したら、破産に追い込まれるのは嫌だよ。だから、送金してくれって言われるのは勘弁してほしい。

└

欲に原因を求めてるけど、実際はただ気にしてないだけだと思うよ。小さな顧客にはあんまり関心がないんだ。

本当のサーバーレスの恐怖は、たまに起こる大きな請求書のミスじゃなくて、月々のじわじわとした増加なんだ。リソースを立ち上げてそのまま放置するのは簡単すぎる。たった数ドルだし、ね？小さなベンチャー企業で「クラウドファースト」の仕事をしてたけど、うちのAWSの請求書はノコギリ波みたいだった。毎月、請求書が千ドルくらいずつ増えていって、20,000ドルに達するとCOOが気づいて、みんなで協力して請求書を10,000ドル以下に抑えるまでがんばるんだ。これを何度も繰り返して、数年のうちにサーバーレスホラー.comの例よりも多くのお金を無駄にしたと思う。数千ドルずつ無駄にして、一気に大きな額じゃなくて。

└

これがオンプレミスで起こらないと思ってるの？ もう使われてないアプリケーションを動かしてるサーバーとか？ たぶんVMだろうけど、そのコストもゼロじゃないしね。

数年前に、Google Cloudで再帰的なクラウドファンクションを試したら、4,000ドルの請求が来たんだ。これは間違いだって言ったら、彼らはそのデビットを忘れたみたいで、ただ「もうやらないで」って言われた。

私たちはワークロードのためにベアメタルを構築してるんだ… クラウドが安いって言われても、実際はそうじゃないから気にしない。最近、10ギガビットのファイバーを扱える decent な小規模ビジネス用のファイアウォールが600ドルで手に入るからね。だから、会社のためにベイエリアやNYCから中西部の町に引っ越したことを本当に嬉しく思ってる。地下室もあるし、ビジネスを成長させるために家でいろいろできるしね。