「またDDoSで落ちてるんだけど？仕事（or ゲーム）にならないんだが？」
ここ数ヶ月、そんな愚痴をタイムラインで見かける頻度、明らかに増えていませんか。
しかも落ちているのが、聞いたこともないサービスじゃない。
Steam、PSN、Riot、Minecraft、xCloud…「守りが固いはず」のメジャーどころが、軒並み巻き込まれている。
その裏にいるのが「Aisuru（アイスル）ボットネット」。史上最大規模31.4 TbpsクラスのDDoSを叩き込んだ張本人です。
この記事は、ニュースのおさらいではなく、インフラ屋・SRE・アプリ開発者として「Aisuru時代に何を変えるべきか」を、かなり主観強めで書きます。
一言で言うと、「Aisuru = ポストMirai時代のラスボス」
一言でまとめると、Aisuruは 「クラウド＆API時代版 Mirai」 です。
- Mirai（2016）：
- 初めて「IoTナメてたらインターネットごと落ちるぞ」と見せつけたボットネット
-
DNSプロバイダ（Dyn）を吹き飛ばし、半分ネットが不安定になったあの事件
-
Aisuru（2025〜）：
- 同じくIoT（ルータ、CCTV、NAS、さらにはAndroid TV）を大量にゾンビ化
- ただし狙いは「昔ながらのWebサイト」ではなく
CDN＋WAFで武装したクラウド・API・ゲーム基盤そのもの
しかも規模感が頭おかしいレベルで、Cloudflareレポートではピーク31.4 Tbps / 2億 rps。
正直、「Tier-1事業者のDDoSマーケ資料に載ってる数字」が、リアルに飛んでくる世界線に入ったと考えた方がいいです。
何が本当に新しいのか？「技術」より「前提」が死んだ
Aisuruについては「史上最大」とか数字のインパクトに目が行きがちですが、
エンジニアとして一番重要なのは 『前提が破壊された』 ことだと思っています。
「このくらいあれば十分」だったキャパの死
昔の設計レビューで、こんな会話ありませんでしたか？
「帯域は○○Gbps確保してます」
「そんな来ないでしょw」
正直、これまではそれで大体なんとかなってました。
でも、Aisuruクラスのボットネットが「DDoS-as-a-Service（レンタル）」として数万円〜数十万円で借りられる世界になると、
- 以前なら「国家レベルの攻撃」が
- クレカ1枚＋Telegramアカウントで発注できる
わけです。
つまり「うち程度の規模なら狙われても耐えられるでしょ」という発想は、
完全に過去のものになりました。
攻撃対象が「Webサイト」から「API＋クラウド請求書」へ
正直ここが一番イヤなところです。
Aisuruは：
- CDN/WAF越しのAPIエンドポイントや
- マイクロサービスの入口（Gateway）
- 自動スケールするクラウドサービス
を、明確に狙っています。
単に落とすだけでなく、
- L7で「もっとインスタンス増やせ！」とクラウドに命令し続け
- オートスケール→クラウド請求爆増→課金DDoS（Bill Shock Attack）
まで視野に入っている。
これはもはやネットワークの問題ではなく CFO案件 です。
「DDoS対策入れると高いから、あとで…」と言って後ろ倒しにしてきたツケが、
“攻撃された瞬間に数百万〜数千万円の請求” という形で返ってくる未来が、現実味を帯びてきています。
「WAF/CDN入れてるから安心」が通じない
Aisuruは：
- L3/L4のUDP/TCPフラッド
- 反射・増幅（DNS/NTP/SSDPなど）
- さらにL7のHTTP(S)リクエストフラッド（APIっぽいパターン）
を同時にぶつけてくるマルチベクター型です。
しかも、守る側のリアクション（レートリミット / Geoブロック / WAFルール）を見ながら、
攻撃パターンをリアルタイムに変えてくる。
結果として、
- CDNレベルでは「正当なトラフィック」に見える
- WAFレベルでは「レート内のAPIリクエスト」に見える
- でも、アプリの中ではDBが火を吹いている
という、「誰のせいとも言いづらいが、全員の設計ミス」が露呈するパターンになりがちです。
なぜこんなにキツいのか：防御側の「構造的負けパターン」
正直、Aisuru自体のテクニックは「まったく新しいプロトコル攻撃」ではありません。
なのにここまで多くの大手が揺さぶられている理由は、防御側に構造的な負け筋が積み上がっているからです。
パターン1：DDoSを「ネットワーク担当の仕事」に押し付けてきた
多くの組織で、DDoSは今もこう扱われています：
- 「ネットワークチーム or 情シスの担当範囲」
- アプリ開発は「WAFでなんとかしてもらう前提」
でもAisuruが狙っているのはL7のビジネスロジックの重いAPIです。
- 1リクエストあたり重い検索API
- 複数外部サービスに同期Callする集約API
- キャッシュ効かない、ユーザー別・テナント別計算
こういう“プロダクト側の都合で重くなったAPI” が、
L7 DDoSの一番の標的になっています。
ネットワークチームからすると、
「TCP/UDPトラフィックはさばけてる。残りはアプリが死んでるだけ」
で、もうどうしようもない。
DDoSはアプリ設計の問題でもある、という認識に変えない限り、
Aisuru世代の攻撃にはいつまでも後手に回ります。
パターン2：オートスケール＝万能薬 だと信じ過ぎた
クラウド時代の「ありがち設計」：
- API Gateway / ALBの前にWAF
- 背後はマイクロサービス＋オートスケール
- 「スパイク来てもスケールするから大丈夫っしょ」
ぶっちゃけ、これ、Aisuruから見たら最高のおもちゃです。
- L7でそれなりに正当っぽいリクエストを山ほど送る
- WAFは怪しさを検出しきれず通す
- オートスケールが発火し、インスタンスが増え続ける
- 最終的に、クラウド請求＆DB負荷で自爆
つまり、「スケーラブルにした設計」が、
『攻撃力の増幅装置』にされている。
スケールすること自体が悪ではないですが、
- スケールさせていい上限
- 「これは攻撃だ」と判断した時のサーキットブレーカー
をアプリ側で持っていないと、
Aisuru時代にはスケール＝自傷行為になりかねません。
パターン3：ユーザー向けの情報開示＆ステータスが弱すぎる
コミュニティ側の反応を見ると、
- 403 Forbiddenやタイムアウトだけ出る
- 公式はダンマリ or 遅い一文コメント
- Redditでユーザーが勝手に「Aisuruっぽい」と推測
という、ちょっと見ていてツラい状況が多いです。
正直、「DDoSを完全に防げ」よりも先に
「攻撃されていることをストレートに伝えろ」の方が、
ユーザー視点ではよほど大事です。
- ステータスページで「現在、大規模DDoS攻撃を受けており、緩和対応中です」と明記する
- 技術的に言えない部分はぼかしてもいいが、「原因不明」とだけ書くのはやめる
- 攻撃が落ち着いたあとに、技術ポストモーテムを出す
これだけでも、
無駄なヘイトや陰謀論はかなり減るはずです。
「Aisuru vs 防御側」勝負の本質：ベンダー比較というより、設計の土台
多くの人が気にするポイントはここだと思います。
「じゃあCloudflareに丸投げしておけば勝てるの？」
「AWS Shield Advanced入れたら安心？」
正直なところ、ベンダー選びは重要だけど決定打ではない、というのが自分の見解です。
DDoSベンダー同士の「力関係」はこう見ている
-
Akamai / Cloudflare / AWS Shield / Google Cloud Armor / Fastly / Imperva …
→ いずれも単発の“最大級攻撃”を捌ける能力は、それなりに証明されてきた -
Aisuruのようなボットネットは、
→ それを何度も・マルチベクターで・サービス横断でぶつけてくる
重要なのは「どのベンダーが強いか」ではなく、
- マルチレイヤーで防御を重ねているか
- ISPレベルのフィルタリング
- クラウドDDoS（Shield/Armor等）
- CDN/WAF
-
アプリレベルのレート制限・サーキットブレーカー
-
アプリの中身が防御戦略に協力しているか
- 「このエンドポイントは絶対に外部公開しない」
- 「この操作は1ユーザーあたり○回/分まで」
-
「高コスト系APIはバックプレッシャー前提」
-
運用とプレイブックがあるか
- DDoS開始から5分以内に取れるアクションが決まっているか
- 「一時的に機能を間引く」「特定リージョンを遮断する」判断ができるか
Aisuruは、技術的に「Miraiの上位互換」かもしれませんが、
防御側の真の分かれ目は 『設計と運用の成熟度』 だと感じています。
ただ、懸念点もあります…防御コストとUXの破壊
ここまで読むと、
「よし、金かけて守りを固めよう💪」と思うかもしれません。
でも、そこにも現実的な懸念があります。
懸念1：防御コストが普通にバカ高い
Aisuru級を想定すると：
- DDoS高機能プラン（Shield Advanced / Cloud Armor Enterprise / Cloudflare高額プラン）
- 帯域・PoPの過剰プロビジョニング
- マルチクラウド or マルチリージョン冗長
- セキュリティ/SRE専任チーム
…と、「大手以外どうすんの？」という世界になります。
結果として、
- 大企業：なんとか捻出して守りを固める
- 中小・スタートアップ：そもそもフルスタック防御は不可能
という「セキュリティ格差」が、さらに広がる懸念があります。
しかも皮肉なことに、
Aisuruは中小を相手にしてもビジネスが成り立つ（DDoS-for-hireだから）ので、
「大きいところだけ狙われるわけでもない」という点が厄介です。
懸念2：セキュリティ強化がユーザー体験を直撃する
- 厳しめのレートリミット
- 頻繁なCAPTCHA
- 一部地域からのアクセス制限
- ログインや課金系の二段階認証必須化
こうした対策は、Aisuru的な攻撃を考えると「やらざるを得ない」面があります。
でも当然、UXは下がる。
「本当に守るべきサービス」と「とりあえず便利ならOKなサービス」の線引きを、
ビジネス側と一緒にちゃんとやらないと、
- セキュリティ担当「これは危ないから絞りたい」
- プロダクト側「コンバージョン落ちるから嫌だ」
という摩擦が、今後さらに激しくなると思います。
じゃあ、プロダクションで何を変えるべきか？（自分の結論）
「Aisuru時代だから、これ入れとけばOK」という魔法のSaaSは存在しません。
ただ、設計と運用の前提を変えることは、今すぐにでもできます。
自分なら、プロダクションサービス向けに最低限こうします：
「DDoS = アプリ設計問題」という前提に変える
- すべての外部公開APIを棚卸しして、
- 1リクエストあたりのコスト（CPU/DB/外部API）
- キャッシュ可否
- レートリミット値
を明文化する - 高コストAPIには必ず：
- レート制限
- キューイング or バックプレッシャー
- 「混んでいるときは諦める」パス
を用意する
「オートスケールの上限」と「止めるボタン」を作る
- オートスケールは無限に増やさない
- サービスごとに上限インスタンス数を決めておく
- 一定閾値を超えたら：
- メンテナンスモード（静的ページ or Queueページ）に切り替える
- 特定機能だけをOFFにする「フラグ」を事前に用意しておく
「落ちない」よりも、
「品位を保った落ち方をする」設計の方が、もはや現実的です。
DDoSプレイブックを「紙ではなく反射神経レベル」にする
- 「攻撃っぽい」兆候を検知したら：
- 誰が
- 何分以内に
- どのスイッチを切り替えるか
を具体的なRunbookとして持ち、
定期的にGame Dayで回す。
Aisuru級は、数分〜数十分単位で勝負が決まるので、
「会議してから決める」スタイルでは間に合いません。
最後のまとめ：Aisuruは“事件”ではなく“時代の開始合図”
正直に言うと、Aisuruそのものにはあまり興味がありません。
Miraiと同じで、この名前もいつかは忘れられるでしょう。
ただし、
- 31.4 TbpsクラスのDDoSが「レンタル」で飛ばせる
- APIやクラウド請求が攻撃対象に含まれる
- 大手も普通に数時間レベルで揺さぶられる
この3点は、もう後戻りしない「新しいベースライン」です。
プロダクションでどうするか？
「まだ様子見」ではなく、「前提をアップデートする時期に来た」と考えています。
- DDoSをネットワーク担当だけの問題にしない
- アプリ設計、SRE、セキュリティ、経営が同じテーブルで話す
- 「きれいに落ちる」ことも含めてシステムをデザインする
Aisuruのニュースを「また大手がやられたか」で終わらせるか、
自分たちの設計と運用を見直すトリガーにするか。
ここでの判断が、数年後の「自分のところが見出しになるかどうか」を分ける、
そんな局面に来ていると感じています。
コメント