AWSのセキュリティ対策は、ひとつのサービスだけで完結させるよりも、守りたい対象と検知したいリスクに合わせて役割を分けることが重要です。AWS Shield、AWS WAF、Amazon GuardDuty、AWS Security Hubは名前が並べて語られやすいサービスですが、担当する領域はそれぞれ異なります。
大まかには、DDoS対策はAWS Shield、Webリクエストの制御はAWS WAF、AWS環境内の不審な動きの検出はAmazon GuardDuty、検出結果やセキュリティ状態の集約はAWS Security Hubが担います。この記事では、4つのサービスの使い分けと、組み合わせて利用する際のメリット・注意点を整理します。
4つのサービスの役割
まずは、各サービスがどの層のリスクに対応するのかを切り分けます。
| サービス | 主な役割 | 向いている場面 |
|---|---|---|
| AWS Shield | DDoS攻撃からAWSリソースを保護するサービス。標準で利用できるShield Standardと、追加機能を備えたShield Advancedがあります。 | 公開Webサイト、API、ECサイト、金融系サービスなど、DDoSリスクを重視する環境。 |
| AWS WAF | Webアプリケーションファイアウォールとして、HTTP/HTTPSリクエストを監視し、条件に応じて許可・ブロック・カウントします。 | SQLインジェクション、クロスサイトスクリプティング、悪質なボット、特定条件のリクエスト制御に対応したい場合。 |
| Amazon GuardDuty | AWS環境内のログやイベントを継続的に分析し、不審なアクティビティや侵害の兆候を検出します。 | 不正な認証情報の利用、通常と異なるAPI操作、マルウェアやデータ流出の兆候を早期に把握したい場合。 |
| AWS Security Hub | 複数のAWSサービスや対応ツールからの検出結果を集約し、セキュリティ状態やベストプラクティスへの適合状況を確認します。 | 複数アカウント・複数サービスのセキュリティ状況を一元的に管理し、優先順位を付けて対応したい場合。 |
使い分けの考え方
DDoS攻撃に備えるならAWS Shield
インターネットに公開しているサービスでは、DDoS攻撃によって正規ユーザーがアクセスできなくなるリスクがあります。AWS Shieldはこの領域を担当し、ネットワーク層・トランスポート層・アプリケーション層のDDoS対策に使われます。
通常のAWS利用ではShield Standardが自動的に適用されます。より高い可視性、専門的なサポート、追加の保護機能が必要な場合はShield Advancedを検討します。ただし、Advancedは追加料金が発生するため、公開サービスの重要度や停止時の影響を踏まえて判断する必要があります。
Webアプリケーションを守るならAWS WAF
AWS WAFは、アプリケーション層のリクエストを見て制御するためのサービスです。SQLインジェクションやクロスサイトスクリプティングのような典型的なWeb攻撃を防ぎたい場合や、IPアドレス、国、ヘッダー、文字列、レートなどに基づいてリクエストを制御したい場合に役立ちます。
公開Webアプリケーションでは、Shieldだけでは判断できないリクエスト内容の制御が必要になることがあります。その場合、AWS WAFでルールを設計し、まずはカウントで影響を確認してからブロックへ移行すると、誤検知による業務影響を抑えやすくなります。
不審な操作や侵害の兆候を検出するならAmazon GuardDuty
Amazon GuardDutyは、AWSアカウント内の操作や通信の傾向から、通常と異なる活動を検出するためのサービスです。認証情報の悪用、想定外のAPI呼び出し、悪意あるIPアドレスとの通信、マルウェアの疑いなど、攻撃が始まった後の兆候を見つける用途に向いています。
GuardDutyは、境界でブロックするWAFとは役割が異なります。WAFが入口のリクエスト制御を担うのに対し、GuardDutyはAWS環境内で起きている不審な動きを検知し、調査や対応のきっかけを提供します。
検出結果をまとめて運用するならAWS Security Hub
AWS Security Hubは、GuardDutyなどの検出結果やセキュリティチェックの結果を集約し、組織全体のセキュリティ状態を把握しやすくするためのサービスです。複数アカウントや複数リージョンを運用している場合、個別サービスの画面だけで状況を追うと、対応漏れや優先順位の混乱が起こりやすくなります。
Security Hubを使うと、検出結果を標準化された形式で集約し、重要度や対象リソースに基づいて整理できます。運用チームが対応すべき項目を見つけやすくなるため、日常的なセキュリティ管理や監査対応にも役立ちます。
組み合わせて使うメリット
多層防御を作りやすい
4つのサービスを組み合わせると、DDoS、Web攻撃、不審なアカウント操作、セキュリティ状態の集約という異なる層を分担できます。たとえば、ShieldでDDoSに備え、WAFでWebリクエストを制御し、GuardDutyで侵害の兆候を検出し、Security Hubで検出結果を整理する構成です。
単一のサービスで全てを解決しようとするよりも、攻撃の入口、環境内の挙動、対応管理を分けて考えられるため、設計と運用の見通しがよくなります。
検出結果を対応につなげやすい
GuardDutyやWAFで見つかった情報をSecurity Hubに集約すると、個別のアラートを単発で見るだけでなく、リソースや重要度、関連する検出結果を踏まえて判断しやすくなります。緊急度の高い検出結果を優先し、対応の抜け漏れを減らす運用に向いています。
対応の自動化を検討しやすい
検出結果を起点に、通知、チケット作成、関係者へのエスカレーション、必要に応じた自動対応へつなげる設計も可能です。ただし、自動化は誤検知時の影響も大きいため、最初から強い遮断を行うのではなく、通知や記録から始め、十分に検証してから段階的に広げるのが現実的です。
組み合わせる際の注意点
コストはサービスごとに確認する
複数のセキュリティサービスを有効化すると、利用量や保護対象、処理するリクエストや検出結果に応じて費用が増える可能性があります。特にWAFやGuardDuty、Security Hubは、環境規模が大きくなるほど継続的なコスト管理が重要になります。
ルールとアラートの運用が複雑になる
WAFのルール、GuardDutyの検出結果、Security Hubのチェック結果をすべてそのまま受け取ると、アラートが多くなりすぎることがあります。重要度の基準、通知先、対応期限、抑制ルールを決めておかないと、運用チームが本当に重要な検出結果を見落とす原因になります。
サービスごとの責任範囲を明確にする
Shield、WAF、GuardDuty、Security Hubは連携できますが、役割は同じではありません。DDoS対策、Web攻撃対策、脅威検出、統合管理のどこに課題があるのかを整理し、必要なサービスから段階的に導入する方が、設定ミスや過剰な運用負荷を避けやすくなります。
導入時のチェックポイント
- 公開サービスの停止影響が大きい場合は、DDoS対策としてShieldの利用範囲を確認する。
- Webアプリケーションを公開している場合は、AWS WAFで守るリソースとルール方針を決める。
- AWS環境内の不審な操作を検知したい場合は、GuardDutyの有効化範囲と通知方法を設計する。
- 複数サービスの検出結果をまとめて管理したい場合は、Security Hubで集約・優先順位付けを行う。
- コスト、誤検知、対応フローを定期的に見直し、不要な通知や重複対応を減らす。
まとめ
AWS Shield、AWS WAF、Amazon GuardDuty、AWS Security Hubは、いずれもAWS環境のセキュリティを高めるサービスですが、守る対象と目的が異なります。DDoSにはShield、Webリクエスト制御にはWAF、不審な挙動の検出にはGuardDuty、検出結果とセキュリティ状態の統合管理にはSecurity Hubを使う、と整理すると選びやすくなります。
重要なのは、すべてを一度に導入することではなく、自社のリスク、公開しているサービス、運用体制に合わせて段階的に組み合わせることです。役割を切り分けて設計すれば、セキュリティを強化しながら、コストやアラート過多による運用負荷も抑えやすくなります。