特定の国や地域から、同じような HTTP リクエストが大量に飛んでくる。
この状況でいきなり「DDoS だから Shield」と考えると、少し雑です。攻撃が CloudFront、Application Load Balancer、API Gateway まで到達し、HTTP のパス・ヘッダー・送信元国・リクエスト頻度として観測できているなら、まず設計対象になるのは AWS WAF です。
この記事では、指定国からの HTTP フラッドを題材に、AWS WAF の Geo match と Rate-based rule が効く場面、AWS Shield との役割差、導入時に外しやすいポイントを整理します。
まず結論
AWS WAF が得意なのは、L7、つまり HTTP/HTTPS リクエストとして見えている攻撃の制御です。
たとえば、次のようなケースです。
- 特定の国・地域からだけ異常にリクエストが増えている
- 同じ IP または同じ特徴を持つ送信元から短時間に大量アクセスがある
- CloudFront、ALB、API Gateway の前段で HTTP リクエストを評価したい
- パス、メソッド、ヘッダー、クエリ文字列、国情報を条件にして遮断・制限したい
逆に、L3/L4 の大規模なネットワーク攻撃そのものを自前ルールで受け止める道具ではありません。そこは AWS Shield、特に Shield Advanced の領域です。
雑に言うと、こう分けると事故りにくいです。
| 見たいもの | 主に使うサービス | 役割 |
|---|---|---|
| HTTP の中身、国、URI、ヘッダー、頻度 | AWS WAF | L7 リクエストの許可・遮断・レート制限 |
| ネットワーク/トランスポート層の DDoS 保護 | AWS Shield | DDoS 緩和の基盤 |
| CloudFront/ALB/API Gateway への入口 | WAF の関連付け先 | どこでルールを評価するか |
AWS WAF でできること
AWS WAF は Web ACL にルールを定義し、CloudFront、Application Load Balancer、Amazon API Gateway などに関連付けて使います。
指定国からの HTTP フラッドでよく使うのは、主に次の 2 つです。
Geo match
Geo match は、送信元 IP の地理情報を条件にリクエストを評価します。
たとえば「通常は日本国内向けの管理画面なのに、ある国から短時間に大量アクセスが来ている」という場合、対象国をブロックまたは Count にして様子を見る、という使い方ができます。
ただし、Geo match は万能な本人確認ではありません。VPN、プロキシ、クラウド事業者の出口 IP を使われると、国情報だけで綺麗に判定できないことがあります。
そのため本番では、いきなり Block にするより、まず Count で影響範囲を確認するほうが安全です。
Rate-based rule
Rate-based rule は、一定時間内のリクエスト数がしきい値を超えた送信元を制限するルールです。
HTTP フラッド対策としてはこちらのほうが実務で使いやすい場面が多いです。国だけで切るより、「異常に多い送信元を絞る」ほうが誤爆しにくいからです。
例としては、次のような考え方です。
通常時:
/login へのアクセスは 5 分で数十〜数百リクエスト程度
異常時:
同一送信元または同一地域から 5 分で数千リクエスト
対応:
/login を対象に Rate-based rule を設定し、しきい値超過を Block または CAPTCHA にする
実際のしきい値は、普段の CloudWatch メトリクスや WAF ログを見て決めます。勘で 100 や 1000 を置くと、攻撃より先に正規ユーザーを焼くことがあります。やめましょう。
Shield との違い
AWS Shield Standard は、多くの AWS サービスに標準で組み込まれている DDoS 保護です。追加料金なしで基本的なネットワーク/トランスポート層の攻撃を緩和します。
一方、AWS WAF は HTTP リクエストを見て判断します。
この違いを混ぜると、設計が変になります。
- SYN flood や UDP flood のような L3/L4 寄りの攻撃を WAF ルールだけで止めようとする
- 特定 URI への大量 POST のような L7 攻撃を Shield だけに任せる
- CloudFront で受けるべきトラフィックを直接 ALB に当てたままにする
Shield は土台の防御、WAF は Web リクエストの制御、と分けて考えるのが現実的です。
どこに WAF を置くか
AWS WAF は、関連付け先によって効き方が変わります。
| 関連付け先 | 向いているケース | 注意点 |
|---|---|---|
| CloudFront | グローバル配信、静的/動的サイトの入口をまとめたい | オリジン直アクセスを閉じないと抜け道になる |
| ALB | VPC 内のアプリケーション入口を守りたい | CloudFront 経由構成なら二重管理に注意 |
| API Gateway | API 単位で制御したい | 認証・使用量制限との役割分担を決める |
公開サイトであれば、CloudFront + WAF に寄せるほうが入口を整理しやすいです。ALB を直接インターネットに晒したまま、CloudFront 側だけ WAF を入れても、攻撃者が ALB に直アクセスできるなら意味が薄くなります。防御線を貼ったつもりで、横にドア全開。よくある残念構成です。
いきなり Block しない
WAF ルールは強力ですが、最初から Block にすると誤遮断が見えにくくなります。
おすすめの流れは次です。
- WAF ログを有効化する
- Geo match や Rate-based rule を Count で入れる
- 正規トラフィックがどれだけ該当するか確認する
- CloudWatch メトリクスとログでしきい値を調整する
- 問題ない条件から Block、CAPTCHA、Challenge に切り替える
特に B2C サイトや海外利用者がいるサービスでは、国単位の Block は強すぎることがあります。国で切る前に、対象パス、HTTP メソッド、User-Agent、レート条件を組み合わせて、狭く当てるべきです。
まとめ
指定国から HTTP レベルの大量リクエストが来ているなら、まず AWS WAF を検討します。
- Geo match は国・地域ベースの制御に使える
- Rate-based rule は短時間の大量リクエスト���限に向いている
- Shield は DDoS 緩和の土台であり、HTTP 条件の細かい制御は WAF の仕事
- CloudFront、ALB、API Gateway のどこで評価するかを先に決める
- 本番投入時は Count で観測してから Block へ進める
「DDoSっぽいから Shield」ではなく、「HTTP リクエストとして条件を見られるか」を先に確認する。ここを分けるだけで、AWS の入口防御はかなり設計しやすくなります。