要点: あらゆるDDoSを一つの設定だけで防ぐことはできません。各層が得意な攻撃を担当する必要があります。
この記事の用語: レート制限：一定時間内のリクエスト数を制限する仕組み。配信元サーバー：CDNの背後にあるアプリケーション サーバー。
現場の課題
アプリケーションでのレート制限は、帯域や接続を枯渇させる攻撃には遅すぎます。一方、すべてのルールを一か所へ集めると、正規利用者の誤検知や新たなボトルネックを招きます。
DDoSは攻撃者より防御側に高いコストを払わせる非対称な問題です。CDNは帯域、プロキシは接続、アプリケーションはアイデンティティと業務コストを使い、安い層からトラフィックを落とします。
設計と実装
- CDNとWAFで大規模トラフィックと既知の攻撃パターンを先に除きます。
- Reverse プロキシで接続数、本文サイズ、ヘッダー待ち時間を制限します。
- 認証や重いDBクエリの前に、エンドポイントの処理コストに応じたレート制限を適用します。
実装例
policy['read'] = { rate: 60/min, burst: 30, cost: 1 }
policy['login'] = { rate: 10/min, burst: 5, cost: 3 }
policy['export'] = { rate: 2/min, burst: 1, cost: 20 }
identity = accountId ?? apiKeyId ?? trustedClientIp
bucket = `${routeGroup}:${identity}`
allowed = tokenBucket.consume(bucket, policy[group].cost)
if (!allowed) return 429 with Retry-After本番導入の進め方
新しいルールはカウントのみで開始し、誰がなぜ遮断されるかを確認します。認証済み利用者やキャンペーン トラフィックと照合し、少数の明確な悪用から段階的に強制します。
まとめ
多層防御は処理コストの低い場所から攻撃トラフィックを除き、アプリケーション資源を正規利用者へ残します。