「Amazon GuardDutyを入れているし、AWS WAFもマネージドルールを適用しているから大丈夫だろう」 セキュリティを考える際、ついそのように思いたくなるかもしれません。しかし、一歩踏み込んで実運用を想定してみると、DDoS対策は単一のサービスで完結するものではなく、複数のサービスを組み合わせて初めて機能するものだと分かります。

いざ大規模な攻撃を受けた際、サービスを継続させるだけでなく、「経済的DDoS」からリソースを守るために、私たちはどのように設計を考えるべきなのかを整理してみました。

1. その対策で、サービスとインフラコストの両方を守れますか？

現場でよくあるDDoS対策の課題は、大きく分けて2つあります。

  • 「WAFがあれば安心」という誤解： AWS WAFはアプリ層（L7）の番人ですが、その手前のインフラ層（L3/L4）で洪水のようなパケットが届いた場合、WAFが処理する前に回線やリソースが枯渇してしまう恐れがあります。
  • 「サービスが落ちなければ成功」という盲点： Auto Scalingが頑張って耐えてくれた結果、翌朝の請求額を見て驚くことになります。これは「経済的DDoS」と呼ばれ、運用面では大きな課題となります。

私たちが目指すべきなのは、単に攻撃を遮断することではなく、**「正規ユーザーのアクセスを維持しながら、コスト被害を最小限に抑えること」**ではないでしょうか。

2. 「点」ではなく「面」で守る。しなやかな多層防御

DDoS対策の鉄則は、サービスを組み合わせて「防衛線」を何重にも張ることにあります。

  • インフラ層（L3/L4）： AWSのバックボーン側で、VPCに到達する前に不要なトラフィックを吸収します。
  • アプリ層（L7）： AWS Shield AdvancedとAWS WAFを連動させ、正常な通信を装った悪意あるリクエストを動的に判別します。
  • 可用性の確保： 攻撃を止めるだけでなく、一時的な負荷を「いなす」ための体力を備えます。

この「多層防御（Layered Defense）」の考え方を整理することが、安定したサービス運用の鍵となります。

3. レイヤー別・役割分担のポイント

では、実際にAWSでどのように構成を組むべきか、検証を通じて見えてきたポイントを深掘りします。

① Amazon CloudFront：オリジン防衛線としての役割

Amazon CloudFrontは単なるコンテンツ配信の高速化ツールではなく、オリジンの保護においても重要な役割を担います。

  • エッジロケーションでの吸収： 世界中に分散されたエッジロケーションでトラフィックを引き受け、オリジン（ALB/EC2）を直接露出させないようにします。
  • 構成上の注意点： ALBの前段にCloudFrontを置く場合、AWS Shield Advancedの「L7自動緩和機能」はCloudFront側で有効化することが推奨されています。 これは、ALB側で有効化した場合、CDN経由により送信元IPなどの属性が正しく識別しにくくなり、緩和の精度が落ちる可能性があるためです。エッジロケーションで攻撃を緩和するためにも、CloudFrontでの適用が定石です。

② AWS Shield Standard vs AWS Shield Advanced

「結局、どっちがいいの？」という方のために、重要な違いをまとめました。

比較項目 Shield Standard (標準) Shield Advanced (拡張)
位置づけ AWS基盤全体の防御 顧客専用のDDoS防御強化
料金 無料（全ユーザーに自動適用） 有料（月額 3,000 USD（組織単位）+ 使用量）
防御レイヤー L3 / L4 (インフラ層) L3 / L4 / L7 (アプリ層)
L7自動緩和機能 なし あり (WAFと連携し自動緩和)
可視化 最低限のメトリクス 詳細な攻撃分析・可視化
専門家支援 なし あり (SRTによる24/365支援)
付帯特典 なし 保護対象リソースの標準 AWS WAF 利用料および Firewall ManagerのShield Advanced保護ポリシーが無料

また、Shield Advanced 最大のメリットは、AIとWAFが連携する「L7自動緩和機能」です。

AWS Shield Advanced 最大のメリットは、AIとWAFが連携する「L7自動緩和機能」です。平常時の通信を学習し、異常検知時に「その瞬間の攻撃を止めるルール」を自動生成します。

※注意点： 適切なベースラインの構築には、一定の期間が必要です。また、Shield Advancedはサブスクリプション契約（継続的な利用コミットメント）が前提となる場合があるため、導入の際は最新のAWS料金ページやサービス規約を確認し、慎重な計画を立ててください。

③ AWS WAF：アプリ層（L7）の「意味」を解釈する

AWS WAFは「形は正しいが、意図が不自然なリクエスト」を判別します。

  • 具体的な対策： 1つのIPアドレスからのリクエスト数を制限する「レート制限ルール」の活用が有効です。AWS Shield Advancedの自動緩和機能も、このWAFの仕組みを利用して、攻撃時のみ動的にブロックルールを生成・適用します。

④ Auto Scaling：可用性の維持とコスト管理

攻撃を「いなす」ためにAuto Scalingでリソースを拡張すると、システムは守れても「インフラコストの急増」という別の問題が発生します。ここで重要になるのが、Shield Advancedの**「コスト保護（Cost Protection）」とのセット運用**です。

  • コスト保護（Cost Protection）： 攻撃によって膨らんだインフラ費用（DDoS攻撃に起因する対象リソースのデータ転送量のスパイクや、スケーリング費用など）は、AWS Shield Advancedの「コスト保護」によってサービスクレジットの還元を受けられる仕組みがあります。
  • 実運用の注意： この補償は自動で適用されるものではなく、スパイク発生後にAWSサポートへ連絡し、通常のトラフィック増ではなく「DDoS攻撃によるコスト増である」という切り分けと申請を行う必要があります。この点はインシデント運用手順に含めておくべきポイントです。

⑤ AWS WAF料金の相殺（AWS Shield Advancedのメリット）

AWS Shield Advancedを契約すると、「AWS Shield Advancedで保護しているリソース」に関連付けられたAWS WAFの基本料金（Web ACLやルールの月額料金、標準的なリクエスト料金など）が追加費用なしでカバーされます。

※補足： 保護対象外のリソースや、Bot Control等の高度な機能、サードパーティ製のマネージドルールなどは対象外となる点には注意が必要です。

4. AWS Organizations で実現する一元的な統制

マルチアカウント環境では、各チームに個別の対策を委ねると設定のばらつきが生じやすいため、組織的な管理を検討します。

  • AWS Firewall Managerによる中央管理： セキュリティ管理アカウントから、組織全体にAWS WAFやAWS Shieldの設定を一括で適用します。
  • 専門チーム（SRT）との連携体制： 重大なイベントに備え、AWSのDDoS専門チームである**SRT（Shield Response Team）**に調査を依頼できる体制を整えておくことも重要です。

※注意点：SRTの支援を受けるには、AWS Shield Advancedの契約に加え、AWSサポートの「ビジネス」または「エンタープライズ」プランへの加入が必須条件となります。

※ポリシー名の補足：チーム名はSRT（Shield Response Team）に変更されましたが、アクセス許可設定に必要なIAMのAWS管理ポリシー名は、後方互換性のため引き続き「AWSShieldDRTAccessPolicy」が使用されます。

まとめ：検知して終わりにしないために

DDoS対策の本質は「攻撃をゼロにすること」ではなく、「正規ユーザーが、何事もなかったかのようにサービスを利用し続けられること」にあります。

もし不安な点があれば、まずは既存のAWS WAFのレート制限ルールの見直しや、Amazon CloudWatchのメトリクスから自社の平常時のベースラインを把握するといった、足元の確認から一歩踏み出して見ることをお勧めいたします。