AWS公式ベストプラクティスで学ぶ、DDoSに強い設計と運用の実践ポイント
近年、手口が高度化・多様化しているDDoS攻撃に対しては、AWS環境においても対策が不可欠です。AWSでは、DDoS攻撃に対する防御機能が標準で提供されていますが、どのサービスをどのように組み合わせて対策すべきかを整理できていないケースも少なくありません。
攻撃によってサービス停止が発生した場合、ECサイトでの購入や予約システム、問い合わせフォームなどを利用できなくなり、直接的な売上機会の損失につながるおそれがあります。さらに、DDoS攻撃によってアクセスが急増すると、Auto Scalingが想定外に動作し、インスタンス数やリソース使用量が増大することで、AWSの利用コストが想定以上に膨らむケースもあります。特に少人数でAWS運用を兼務している組織では、状況を即座に把握・制御できず、被害の長期化やコスト増大を招くリスクが高まるため注意が必要です。
本記事では、AWSにおけるDDoS対策の全体像を整理したうえで、AWSが担う責任範囲と自社で備えるべき対策を切り分け、現実的な運用設計の考え方についても解説します。
目次
1. AWSにおけるDDoS攻撃の基礎知識
DDoS攻撃の基本概念を整理したうえで、AWS環境においてなぜ対策が重要となるのかを解説します。
DDoS攻撃とは何か
DDoS攻撃（Distributed Denial of Service攻撃）とは、複数の端末やサーバーから大量の通信を送り付けることで、対象システムのリソースを枯渇させ、サービスを停止または遅延させる攻撃です。攻撃者はマルウェアに感染させたボットなどを利用し、短時間に膨大なリクエストを発生させます。DDoS攻撃の代表的な種類は以下のとおりです。
- ボリューム型攻撃：大量の通信によりネットワーク帯域を枯渇させる
- プロトコル攻撃：接続処理を大量に発生させ、サーバーの処理能力を枯渇させる
- アプリケーションレイヤー攻撃：Webアプリケーションに負荷をかけ、応答不能にする
近年では、クラウドサービスの利用拡大により、インターネット上に公開されるリソースが増加したことに伴い、DDoS攻撃の対象は大企業だけでなく、中小〜中堅企業にも及ぶケースが増えています。
AWS環境でDDoS対策が重要になる理由
AWSでは責任共有モデルという考え方のもと、AWSと利用者の責任範囲が定められており、その範囲は利用するサービスによって異なります。インフラレベルの防御はAWSが担う一方で、OSやミドルウェア、アプリケーション設定、WAFルール設計などの上位レイヤーは利用者側の責任です。
そのため、適切な設計や設定を行わなければ、攻撃の標的となった際にサービス停止や可用性の低下を招きかねません。特に、要員が限られる組織では、対応の遅延が被害拡大に直結するリスクがあります。AWSが担う範囲と自社で対応すべき範囲を正しく理解し、自社環境に適した対策を設計することが重要です。
2. AWSが提供するDDoS対策の仕組みと役割
AWSには、DDoS攻撃を軽減するための複数のサービスが用意されています。
AWS Shieldによるインフラレベルの防御
AWS Shieldには「Standard」と「Advanced」の2種類があり、いずれもDDoS対策を目的としていますが、守備範囲と利用者が担う役割は異なります。
Shield Standardは、すべてのAWSユーザーに無償で提供されており、L3（ネットワーク）／L4（トランスポート）層を中心とした大規模DDoS攻撃に対して、AWSのインフラ側で自動的な検知・緩和が行われます。
一方、Shield Advancedは有償サービスであり、より高度な可視化と運用支援が提供されます。具体的には、攻撃状況の詳細な可視化、Shield Response Team（SRT）による専門支援に加え、DDoS攻撃に起因するスケーリングで発生したコスト増加について、一定条件のもとで補償を受けられる仕組みも含まれています。
AWS WAFによるアプリケーションレイヤー対策
AWS WAFは、アプリケーションレイヤーのセキュリティ制御を担うサービスであり、レート制限などの機能を活用することで、DDoS攻撃の緩和にも有効です。HTTP／HTTPSリクエストの内容や頻度をもとにルールを設定でき、特定のURLへの過剰なアクセスや異常なリクエストを制御できる点が特徴です。
関連記事：AWS WAFとは？機能やメリット、料金体系、運用上の注意点を解説
配信・名前解決・負荷分散によるDDoS耐性
上記に加え、配信・名前解決・負荷分散といった基本的なマネージドサービスを活用することで、高いDDoS耐性を実現できます。
大量のトラフィックを一点に集中させるのではなく、AWSのグローバルインフラに分散させる設計とすることが、DDoS攻撃に対する耐性向上につながります。
| Amazon CloudFront | CDNサービスであり、世界中のエッジロケーションでコンテンツを配信する。大量のリクエストが発生した場合でも、エッジでトラフィックを分散・吸収することで、オリジンサーバーへの直接的な負荷を軽減できる。 |
| Amazon Route 53 | 高可用性と耐障害性を備えたDNSサービスであり、大量クエリへの耐性を確保しやすい。DDoS攻撃によりDNSが停止すると、アプリケーションが正常でもサービスは利用できなくなるため、信頼性の高いDNS基盤の採用はDDoS対策の基本要素となる。 |
| Application Load Balancer（ALB） | アプリケーションレイヤーで動作するロードバランサーであり、複数のバックエンドにトラフィックを分散する。特定サーバーに負荷が集中する状況を防ぎ、障害時には自動的に正常なサーバーへ振り分ける。 |
関連記事：AWSのロードバランサーとは？種類や用途、料金体系を詳しく解説
3. AWSでDDoS対策を設計する際の基本方針
AWSでのDDoS対策は、可用性やコスト、運用負荷を含めた全体設計として考える必要があります。そのための基本的な設計方針について解説します。
完全に防ぐのではなく、影響を最小化することを目的とする
まず、攻撃の完全な防御を前提としない姿勢が重要です。DDoS攻撃は手法や規模が多様化しており、すべての攻撃を事前に排除することは現実的ではありません。特に、インターネットに公開されたAWS環境では、一定の攻撃トラフィックが到達することを前提とし、サービス停止などの事業影響をいかに最小化するかを目的とします。
CloudFrontによるトラフィック吸収や、ALBによる負荷分散、AWS WAFによるリクエスト制御などを組み合わせ、攻撃を受けてもサービスを継続できる体制を構築することが重要です。
コストとのバランスを考慮し、可用性を維持できる構成を設計する
AWSでは、高度なDDoS対策を実装しようとすれば、それに応じてコストも増加します。そのため、事業規模やシステムの重要度に応じた判断が必要です。どの程度の停止が事業上許容されるのかを想定したうえで、十分な対策レベルを見極めることが、AWSにおける現実的なDDoS対策設計につながります。
例えば、AWS Shield Advancedは強力な支援体制を提供する一方で、月額費用が発生します。すべてのシステムに適用するのではなく、売上に直結するシステムや停止許容時間が短いサービスに限定して導入するなど、メリハリのある設計が求められます。CloudFrontやALBといったAWSの主要なマネージドサービスを活用するだけでも、一定のDDoS耐性を確保することは可能です。
技術的な対策に加えて、運用上の対策（監視・初動対応）を行う
DDoS対策は、技術的な設定だけで完結するものではありません。攻撃を完全に防げない以上、攻撃を検知し、迅速に対応するための運用設計が不可欠です。
Amazon CloudWatchによる監視体制の構築や、AWS WAFログの可視化、Amazon GuardDutyによる不審な通信の検知などを通じて、通常時とは異なるトラフィックを早い段階で検知できる体制を整える必要があります。
また、攻撃を検知した際に「誰が何を行うのか」という初動対応ルールを事前に定めておくことも重要です。WAFルールの一時的な強化、アクセス制限の実施、関係部署への連絡といった対応をあらかじめ決めておかなければ、緊急時に被害が拡大するおそれがあります。
関連記事：Amazon GuardDutyとは？脅威検知の仕組みや機能、メリットを解説
自社で対応すべき範囲と、外部支援を活用すべき範囲を整理する
自社だけで対策を完結させようとするのではなく、外部の専門支援を適切に活用することも重要です。MSSPなどの運用支援サービスを活用すれば、自社だけでは対応が難しい高度な分析やインシデント対応についても、セキュリティに特化した豊富な知見や実績をもとに支援を受けることが可能です。
一方で、自社のアプリケーションに合わせたルール設計や、事業影響を踏まえた判断は、利用者側でしか行えません。どこまでを外部支援に任せ、どこを自社で担うのかをあらかじめ整理しておくことで、無理のない運用体制を構築できます。
関連記事：MSSPとMSPの違いとは？役割・メリット・選び方をわかりやすく解説
AWSのセキュリティに関する基本的な考え方や全体像については、以下の記事で解説しています。
関連記事：AWS環境に必要なセキュリティ対策とは？考え方から具体的なサービスまで
4. AWSにおけるDDoS対策のベストプラクティス
AWSでは、DDoS攻撃を前提としたベストプラクティスが公開されています。ここでは、AWSの公開情報をもとに、DDoS対策の優先順位や具体的な運用方法について解説します。
エッジ層でのトラフィック分散と自動緩和（BP1 / BP2 / BP3）
CloudFront、AWS Global Accelerator、Route 53の組み合わせが推奨されています。これらを前段に配置することで、アプリケーションへの入口を制御し、攻撃対象範囲を限定できます。
CloudFrontによるトラフィック分散とキャッシュの活用により、オリジンサーバーへの直接的な到達を抑制可能です。また、Global Acceleratorの利用は、トラフィックを最適なリージョンへ分散させ、単一拠点への負荷集中を防ぐ役割を果たします。Route 53の採用は、大量のDNSクエリが発生した際でも安定した名前解決を維持するのに有効です。さらに、CloudFrontにAWS WAFを組み合わせることで、アプリケーション層に対する異常なリクエストや大量アクセスを制御し、多層的な防御を実現できます。
ネットワーク分離（BP4 / BP5）
DDoS対策の基本は、攻撃を受ける可能性のある範囲そのものを極力小さくし、外部から到達できる入口を限定することです。BP4およびBP5では、アプリケーションの公開経路やネットワーク構成の統制が重要とされています。
CloudFrontやALBを経由しないアクセスを遮断し、セキュリティグループやネットワークACL、VPC設計によって通信経路を限定することで、想定外のトラフィックが内部リソースへ到達するのを防ぎます。これにより、DDoS攻撃の影響を受ける入口を管理可能な範囲に集約可能です。
関連記事：AWSのセキュリティグループとは？ネットワークACLとの違いや設定方法、注意点を解説
負荷分散とスケールによる耐性強化（BP6 / BP7）
DDoS攻撃時には、通常時を大きく上回るトラフィックが発生するため、単一のリソースで処理しようとすると、容易に限界を超えてしまいます。
そのため、ALBやAuto Scalingを組み合わせ、特定のインスタンスへの負荷集中を回避して、一時的なトラフィック増加に対しても処理能力を向上させる設計が求められます。さらに、ALBにAWS WAFをアタッチすれば、異常なリクエストや過剰なアクセスを事前に遮断でき、不要なトラフィックによるスケールアウトやリソース消費を抑制することが可能です。
可視性・検知・継続改善
DDoS攻撃は常に同じ形で発生するわけではなく、トラフィック傾向や攻撃手法も変化します。そのため、可視化と検知の仕組みを整備し、継続的に改善していくことが不可欠です。
CloudWatchによるメトリクス監視や、AWS WAFのログ分析を通じて通常時との差分を把握し、攻撃を早い段階で検知できる体制を整える必要があります。また、インシデント発生後には対応内容や影響範囲を振り返り、ルールや構成を見直すことが重要です。
DDoS対策は一度設定して終わりではなく、運用と改善を繰り返すプロセスです。この視点を持つことが、AWS環境において実効性のあるDDoS対策を実現するための重要なポイントです。
まとめ
AWSのDDoS対策では、AWS ShieldやCloudFrontなどにより一定の防御が標準提供されていますが、それだけですべての攻撃を防げるわけではありません。特にアプリケーション層を狙った攻撃や、継続的な小規模攻撃は見逃されやすく、設計や運用次第ではサービス停止やコスト増大を招くおそれがあります。
DDoS対策の効果を維持するためには、AWSが担う範囲と自社で対応すべき範囲を理解したうえで、必要なサービスを組み合わせ、監視やインシデント対応を含めた継続的な運用体制を整えることが重要です。
ハートビーツ の「SecureOps+」は、24時間365日の監視から初動判断、対応支援までを一体で提供するマネージドサービスです。AWS環境のDDoS対策や運用体制に不安がある場合は、ハートビーツへご相談ください。
AWSセキュリティ運用を24/365で統合支援する「SecureOps＋」を提供開始
