MENU

AWS Shield入門 DDoS対策の基礎からStandard・Advancedの違い・料金まで現場で使える実践ガイド

「AWSで公開したWebサービスが、気づいたら大量のリクエストで応答不能になっていた」——オンプレ時代にDDoS攻撃の経験がある方なら、クラウドに移行してもこの不安はついて回るはずです。専用アプライアンスやキャリア側のブラックホールルーティングで守っていた環境から、いざAWSに移ると「DDoS対策はどこで有効にするのか」「追加契約は必要か」で手が止まる方が少なくありません。

この記事では、AWS Shieldについて、オンプレ経験者にもわかりやすく解説します。無料で自動有効化されるShield Standardの守備範囲、有償のShield Advancedが必要になるケース、CloudFront・ALB・Route 53との組み合わせ、料金の落とし穴、そして具体的な設定手順までカバーします。

AWS Shield入門 DDoS対策の基礎からStandard・Advancedの違い・料金まで現場で使える実践ガイド

目次

なぜAWS Shieldなのか?オンプレDDoS対策との違い

オンプレのDDoS対策は、境界に専用アプライアンス(ArborやRadwareなど)を設置するか、上流ISPにスクラビングサービスを依頼するのが定番でした。どちらも契約・構築・容量設計に時間とコストがかかり、攻撃帯域がアップリンクを超えた瞬間に回線ごと落ちるリスクを常に抱えていました。

AWS Shieldは、AWSのグローバルエッジネットワーク(400以上のエッジロケーション)そのものが防御層になります。攻撃トラフィックはリージョンのサーバーに到達する前にエッジで吸収・フィルタリングされるため、保護対象のリソース自体が飽和する前に緩和されます。つまり、「アップリンクを太くする」のではなく「AWSのインフラ全体で吸収する」という発想の転換です。

さらに重要なのは、Shield Standardは追加契約なしで全AWSアカウントに自動適用される点です。オンプレのように「契約してから数週間後に開通」という待機時間はありません。

AWS Shield Standardとは:無料で自動有効化されるDDoS防御

AWS Shield Standardは、すべてのAWSアカウントでデフォルトかつ無料で有効になっているDDoS防御サービスです。特別な申込や設定は不要で、AWSのエッジロケーションやリージョン内のインフラに流れ込む一般的なDDoS攻撃を自動で緩和します。

1. 保護される攻撃の種類

Standardが緩和するのは、主にネットワーク層(L3)とトランスポート層(L4)の攻撃です。具体的には以下のような手法が対象になります。

SYNフラッド: TCP接続を大量に開いてリソースを枯渇させる攻撃
UDPリフレクション攻撃: DNS・NTPなどを悪用した増幅攻撃
IPフラグメンテーション攻撃: 不正な断片化パケットによるリソース消費
一般的なボリューム型攻撃: 帯域を飽和させる大量パケット送信

2. 保護対象のリソース

Shield Standardは以下のAWSリソースを自動で守ります。

Amazon CloudFront: CDN経由のトラフィックをエッジで緩和
AWS Global Accelerator: エニーキャストIPを持つエンドポイント
Amazon Route 53: 権威DNSサービス
Elastic Load Balancing(ALB/NLB/CLB): ロードバランサーへの攻撃緩和
Amazon EC2: Elastic IP経由のトラフィックに対して基本防御

3. Standardの限界

Standardは優秀ですが、アプリケーション層(L7)の高度な攻撃、たとえばHTTPフラッドSlowlorisのような「正規に見えるリクエストで殺しに来る攻撃」には単体では不十分です。L7攻撃への対処にはAWS WAFやShield Advancedを組み合わせる必要があります。

AWS Shield Advancedとは:有償プランの強化機能

AWS Shield Advancedは、大規模・高度な攻撃を受ける可能性があるビジネスクリティカルなシステム向けの有償プランです。Standardを大幅に拡張し、可視化・専門家サポート・コスト保護までセットで提供されます。

1. Advancedで追加される主な機能

高度な攻撃検知と緩和: L3〜L7まで網羅した詳細な攻撃検知
Shield Response Team(SRT)の24時間サポート: 攻撃中にAWSのDDoS専門チームが直接対応
リアルタイムの可視化: CloudWatchと連携した攻撃メトリクスとAWS WAFログの詳細分析
コスト保護(Cost Protection): 攻撃起因のスケールアウトで発生した追加料金を返金申請可能
AWS WAFの利用料込み: Advanced契約中はAWS WAFのWebACL・ルール利用料が含まれる
AWS Firewall Managerとの統合: 複数アカウント・リソース横断のポリシー一元管理

2. Advancedが必要になるケース

すべての環境にAdvancedが必要なわけではありません。以下のような条件に1つでも当てはまるなら、検討価値があります。

・金融・ECなどダウンタイムが直接売上損失につながる業種
・過去にL7 DDoSを受けた実績がある、あるいは業界的に標的になりやすい
・DDoS起因のオートスケーリング追加料金をコスト保護で回収したい
・攻撃発生時に24時間対応可能な社内体制がなく、SRTに任せたい

3. StandardとAdvancedの比較

項目 Shield Standard Shield Advanced
料金 無料(自動適用) 月額$3,000 + データ転送料(2026年4月時点)
対象レイヤ L3/L4中心 L3/L4/L7
攻撃時サポート なし SRTによる24時間対応
コスト保護 なし あり(申請ベース)
AWS WAF利用料 別途課金 含まれる
可視化 限定的 CloudWatchで詳細メトリクス

他のAWSセキュリティサービスとの組み合わせ

AWS ShieldはDDoS対策に特化したサービスです。単体で全てのWeb攻撃を防ぐものではなく、他のサービスと組み合わせて多層防御を構成するのが現場の定石です。

1. AWS WAFとの連携

AWS WAFはアプリケーション層のリクエストをルールベースでフィルタする機能です。SQLインジェクションやクロスサイトスクリプティング、地域ブロック、レートベースルールなどをカスタマイズして設定できます。Shield Standard + WAFは中小規模サービスの現実的な最小構成、Shield Advanced + WAFは高可用が求められる商用サービスの標準構成です。

2. CloudFrontとの組み合わせ

CloudFrontを前段に置くと、攻撃トラフィックの大半をエッジロケーションで吸収でき、オリジン(ALBやEC2)に到達する前に遮断されます。L7攻撃対策としては「CloudFront → WAF → ALB」という構成が王道です。

3. Route 53 Resolver DNS Firewall

DNSレベルでの不正ドメインアクセス防止を担当します。Shieldが帯域攻撃を、DNS Firewallが名前解決経由の脅威を担当する役割分担になります。

4. 多層防御の推奨構成

インフラエンジニアが現場で組む標準的な多層防御は以下のようになります。

# 外部 → エッジ → アプリの多層防御 # L3/L4 : Shield Standard(自動) # 帯域保護: Shield Advanced(オプション) # L7防御 : AWS WAF(WebACL + レートベースルール) # エッジ : CloudFront(キャッシュ+地理ブロック) # ALB : アクセスログをCloudWatch Logsへ # DNS : Route 53 + DNS Firewall

料金の仕組み(コスト感覚)

Shieldのコストで最も混乱しやすいのがAdvancedの料金体系です。執筆時点(2026年4月時点)の主な料金を整理します。

1. Shield Standardの料金

Standardは完全無料です。AWSを使っている限り自動で適用され、追加の請求は発生しません。

2. Shield Advancedの料金

月額固定料金: $3,000/月(1年契約、組織全体で1契約)
データ転送料金: CloudFront/ALB/EC2などから外部へ出るトラフィックに追加従量課金
最低契約期間: 12か月

組織全体で1契約なので、同一のAWS Organizationsに属するアカウント群なら共有可能です。データ転送料金はAdvancedが保護するリソース種別によって異なり、たとえばCloudFront経由トラフィックが最も安く、EC2/EIP経由が最も高くなります。

3. コスト保護(Cost Protection)の仕組み

Advancedの大きな価値のひとつが、DDoS攻撃に起因するAutoScaling・CloudFront・Route 53・ELBのスケール費用を事後申請で返金できるコスト保護です。攻撃による想定外の請求からビジネスを守る保険として機能します。

4. コスト判断の目安

月額$3,000(年間約$36,000)は小さくない金額です。以下のような判断軸で考えると整理しやすくなります。

売上がDDoSで数時間停止した場合の損失が月額料金を超えるか
社内で24時間対応可能なセキュリティ要員を確保するコストと比較して安いか
SLA契約で可用性をコミットしている取引先があるか

実際の設定手順

Shield Standardは何もしなくても有効ですが、Advancedは明示的な有効化とリソース登録が必要です。AWSコンソールでの基本フローを整理します。

1. Shield Advancedのサブスクリプション

AWSマネジメントコンソールで「AWS Shield」ダッシュボードを開き、「Shield Advancedにサブスクライブ」を選択します。1年契約の確認画面でサブスクリプション条件に同意すると有効化されます。AWS Organizations管理者は全メンバーアカウントを一度に保護設定できます。

2. 保護対象リソースの追加

ダッシュボードの「Protected resources」から、保護したいリソースを選んで追加します。CLIで追加する場合の例は以下のとおりです。

# AWS CLI: CloudFrontディストリビューションを保護対象に追加 aws shield create-protection \ --name "prod-cloudfront-protection" \ --resource-arn arn:aws:cloudfront::123456789012:distribution/EXXXXXXXXXXXXX # 保護対象の一覧表示 aws shield list-protections

3. CloudWatchアラームでの通知設定

DDoSDetected メトリクスにアラームを設定すると、攻撃検知時に即座に通知を受けられます。

# AWS CLI: DDoS検知アラームの作成 aws cloudwatch put-metric-alarm \ --alarm-name "Shield-DDoS-Detected" \ --metric-name DDoSDetected \ --namespace AWS/DDoSProtection \ --statistic Maximum \ --period 60 \ --threshold 1 \ --comparison-operator GreaterThanOrEqualToThreshold \ --evaluation-periods 1 \ --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:shield-alert

4. WAFルールの連携

Advancedを有効にすると、WebACLで使える「レートベースルール」や「ジオマッチルール」が即座にShieldの検知情報と連動します。東京リージョン(ap-northeast-1)のALBに対してWAFを関連付け、5分間で1,000リクエストを超えるIPをブロックする、といった運用が基本形です。

応用・実務Tips

ここから先は、現場で使える実務的なポイントです。

1. 攻撃を受ける前にプロアクティブエンゲージメントを有効化する

Advancedにはプロアクティブエンゲージメント機能があり、AWSのSRTが攻撃検知時に自動で連絡を取り、対応に入ってくれます。契約するなら必ず有効化し、連絡先を最新の状態に保ちます。

2. AWS Firewall Managerで組織全体を統制する

アカウントが増えると、個別にShield・WAFを設定するのは管理負荷が上がります。AWS Firewall Managerを使うと、組織ポリシーとして「すべてのCloudFrontディストリビューションにShield Advancedを自動適用」といった統一ルールを強制できます。

3. テスト環境でのログ分析ルーチンを確立する

平時からWAFログ・CloudWatchメトリクスを眺める習慣をつけておくと、いざ攻撃時に「何が普段と違うのか」が瞬時に判断できます。CloudWatch LogsからAthenaでクエリを回すパイプラインを用意しておくのが実務では有効です。

4. セキュリティ全体設計は姉妹サイトも参照

クラウド以前のネットワーク・サーバー側のセキュリティ設計については、姉妹サイトSecurityMaster.JPで詳しく解説しています。Linuxサーバーの強化設定はLinuxMaster.JPも合わせて参考にしてください。

よくあるトラブルと対処法

1. Shield Advancedを契約したのに攻撃で料金が跳ねた

コスト保護は自動返金ではなく、申請ベースであることを知っておく必要があります。攻撃検知後、AWS Supportからケースを起票し、CloudWatchメトリクスと請求の変動を証拠として提出します。SRTと連携していればスムーズに進みます。

2. EC2に直接Elastic IPを付けたが守られているか不安

Elastic IP経由のEC2は、Shield StandardのL3/L4防御の対象です。ただし、L7攻撃や複雑な攻撃への耐性は低いため、可能な限りALBやCloudFront配下に配置することが推奨されます。直接公開のEC2はDDoS以外の攻撃面も増やす構成なので再検討したいところです。

3. WAFが誤検知してアクセスが遮断された

レートベースルールの閾値が厳しすぎると、正規ユーザーの連続クリックでもブロックされます。CloudWatchでブロック理由(RuleId)を確認し、カウントモードで検証してから強制モードに昇格する二段階運用が事故を防ぎます。

4. Shieldダッシュボードに攻撃履歴が表示されない

Shield Advancedが有効な場合のみ詳細な攻撃履歴が蓄積されます。Standardでは簡易的な情報のみで、過去の攻撃を時系列で追跡する用途にはAdvancedが必要です。

本記事のまとめ

AWS Shieldは、オンプレでは大きな投資を要したDDoS対策を、AWSのエッジネットワークを使って標準機能として提供する設計思想のサービスです。重要なポイントを整理します。

Shield StandardはすべてのAWSアカウントで無料・自動適用、L3/L4のDDoSを緩和
Shield Advancedは月額$3,000の有償プランで、L7防御・SRT・コスト保護を追加
CloudFront + WAF + Shieldの多層防御がクラウド時代の標準構成
・AdvancedはDDoSが売上・SLAに直結する業種で選ぶ、判断軸は損失額×確率
・料金は固定料金+データ転送料、コスト保護は申請ベースで回収する運用が必要

オンプレ経験のあるエンジニアにとって、Shieldは「専用アプライアンス×上流ISP契約」から解放されるサービスです。Standardだけでも多くの攻撃は緩和されますが、ビジネスクリティカルなシステムではAdvancedと WAFを組み合わせた多層防御を設計に組み込んでおきましょう。

DDoS対策からクラウド設計全体を、体系的に学びたい方へ

クラウド実務に役立つ「Cloud Security」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次