AWS Shield完全ガイド：DDoS対策を「標準保護＋高度保護＋運用プロセス」で設計する（GCP Cloud Armor／Azure DDoS Protection比較）

はじめに：DDoS対策は“契約”ではなく“設計”で効きます

AWS Shield（以下、Shield）は、AWS上のリソースに対するDDoS攻撃（分散型サービス妨害）から守るための保護サービスです。公式ドキュメントでは、Shieldが既知・ゼロデイを含む幅広いDDoS攻撃ベクトルに対する保護を提供し、Shield StandardはAWS利用時に自動提供され追加料金がかからないこと、より高い保護としてShield Advancedをサブスクライブできることが明記されています。

ここで押さえたいのは、DDoS対策は「入れて安心」ではなく、どの入口を守るか／攻撃時に誰が何をするか／コストをどこまで許容するかを決めて初めて“効く仕組み”になる、という点です。Shieldは“ネットワーク・トランスポート層中心のDDoS保護”として機能し、WAFのようなアプリ層のルールとは役割が異なります（今回はWAFは除外依頼の対象なので、あくまでShieldの設計に集中します）。

比較として、GCPはCloud ArmorがDDoSとアプリ攻撃への防御を提供し、Standardでもボリューム型・プロトコル型DDoSへの常時保護があることが公式に説明されています。
AzureはAzure DDoS Protectionが常時監視、リアルタイム調整、緩和分析などを提供し、検知時に自動的に軽減することが公式に整理されています。

1. AWS Shieldとは：StandardとAdvancedの2段構えで“守りの深さ”を選ぶ

1-1. Shield Standard：デフォルトで付いている基本防御

Shield Standardは、AWSを利用しているだけで自動的に提供され、追加料金がかからないことが公式に明記されています。
まずこの前提が重要で、「AWSを使っている時点で、最低限のDDoS防御は土台としてある」という意味です。逆に言えば、Shield Standardだけで十分かどうかは、事業の重要度・停止許容時間・攻撃リスクの想定で決まります。

1-2. Shield Advanced：高い保護と運用支援を前提にする上位プラン

同じ公式ページで、より高いレベルの保護のためにShield Advancedへサブスクライブできることが示されています。
Advancedの導入判断は、「攻撃を受けるかもしれないから」ではなく、**攻撃を受けたときに“どこまで事業影響を抑えたいか”**と、運用（対応体制）をどこまで整えるかで決めるのが現実的です。

2. 何から守る？DDoS攻撃の“層”を理解して入口を決める

Shieldのドキュメントでは、検知する攻撃クラスとしてネットワークボリューム攻撃（レイヤー3）などが挙げられています。
ここから分かることは、Shieldは主にインフラ層（L3/L4）寄りのDDoSを中心に扱うということです。

実務で重要なのは、「入口」を整理することです。入口はだいたい次のように分類できます。

• グローバル入口（CDNやグローバル配信）
• リージョン入口（ロードバランサー、公開IP）
• 直接公開（特定の公開IPでサービス提供）

Shieldを“どこに効かせるか”は、これら入口のどこでトラフィックを受け止める設計かで決まります。入口の数が増えるほど守る場所も増え、運用も複雑になります。まずは入口の数を減らす（集約する）発想が、DDoS対策では非常に効きます。

3. Shield Advancedの料金：月額固定＋データ転送系の従量が中心

Shield Advancedの料金ページ（日本語）では、月額料金として3,000 USDが例示され、加えて“Shield Advanced データ転送（アウト）”の従量料金が発生し得ることが、具体例つきで説明されています。たとえばALBでリージョン外データ転送が1,000GBある場合、月額3,000 USDに加えてGB単価の費用が上乗せされる例が示されています。

この料金構造から、設計の勘どころは次の2つに集約できます。

• Advancedは“固定費”を払って守りを厚くするモデル（守る価値がある入口に絞る判断が重要）
• データ転送が大きいワークロードでは従量が効く可能性がある（転送設計もコストに影響）

つまり、Advancedは「高い/安い」ではなく、**“そのサービスが止まったときの損失”と“固定費＋従量費の許容”**の比較で意思決定するのが筋です。

4. 実務設計：Shieldを“効かせる”ための3つの視点

4-1. 視点1：守る対象の優先順位（全部を守らない勇気）

DDoS対策は、全リソースを同じレベルで守ろうとするとコストと運用が破綻します。おすすめは、次の順で優先度をつけることです。

• 売上・信頼に直結する入口（決済、ログイン、購買など）
• 事業継続に必要な入口（管理画面、基幹APIなど）
• それ以外（障害時に止まっても致命傷になりにくいもの）

「どこが落ちると本当に困るか」を先に決めると、Shield Advanced導入の判断も、運用体制の設計もぶれにくくなります。

4-2. 視点2：攻撃時の運用（誰が何を見るか）

Shieldは“攻撃を自動的に軽減する”世界ですが、運用で重要なのは「状況の把握」と「関係者への連絡」です。攻撃中に必要なのは、

• 今起きているのはDDoSなのか、バズなのか、障害なのか
• 入口は生きているか、レイテンシはどうか
• 影響範囲はどこまでか
  といった切り分けです。DDoS対策は技術より“体制”が重要になりやすいので、オンコールと連絡経路を最初から決めておくと、実際の攻撃時に強いです。

4-3. 視点3：復旧後の学習（設計を改善する）

攻撃が収まった後、よくある落とし穴は「とりあえず収束したので忘れる」ことです。実務では、復旧後に次を必ず振り返るだけでも、次回の耐性が上がります。

• 入口の集約はできていたか（無駄な公開点はなかったか）
• 想定外に苦しかったのはどこか（連絡、判断、ログ、メトリクス）
• 固定費/従量費に対して価値があったか（意思決定の見直し）

5. ありがちな失敗と回避策

5-1. 入口が散らばっていて守り切れない

公開IPが複数あり、ロードバランサーやCDNの入口が統一されていないと、DDoS対策は急に難しくなります。まずは入口を一本化し、守る場所を絞ることが基本です。

5-2. “Advanced＝万能”と誤解する

Shield Advancedは強力ですが、アプリ層の問題（不適切なAPI設計、重い検索、ログイン乱用など）まで全部を解決するものではありません。守りの層を誤解すると、運用の焦点がずれます。

5-3. コストが“固定費”として継続することを忘れる

Advancedは月額の固定費が中心です。予算の説明責任がある組織では、導入理由（事業影響・顧客要件・停止許容時間）を文書化し、定期的に見直す前提で導入すると揉めにくいです。

6. GCP Cloud Armorとの比較：Standardでも“常時DDoS保護”が明確

Cloud Armorは、DDoSとアプリ攻撃への防御を提供するネットワークセキュリティサービスとして説明されています。
さらに公式のEnterprise overviewでは、Cloud Armor Standardに「ボリューム型およびプロトコルベースのDDoS攻撃に対する常時保護（自動インライン緩和、遅延影響なし）」が含まれることが明記されています。

ここから得られる比較のポイントは、

• AWSはShield Standardが“自動で付く基礎防御”、Advancedで追加の保護と運用強化を選ぶ
• GCPはCloud Armor Standardの中に“常時DDoS保護”が明確に含まれると整理されている
  という、サービスの見せ方の違いです。

ただし現場の本質は同じで、どの入口をどう守るか、そして運用でどう扱うかが勝負です。クラウドが違っても、入口集約と運用プロセスの設計は共通して効きます。

7. Azure DDoS Protectionとの比較：常時監視と自動チューニングが前面に出る

Azure DDoS Protectionの概要では、常時オンのトラフィック監視、アダプティブ（適応的）リアルタイムチューニング、DDoS軽減分析が得られ、検出されると即座に自動軽減する、と説明されています。
また、保護されたリソースのパブリックIPごとに自動チューニングの軽減ポリシーが適用されること、攻撃分析や緩和フローログのストリーミングに言及があることも特徴的です。

AWS Shieldとの比較では、

• AWS：Standardが自動提供、必要に応じてAdvancedで保護レベルを上げる
• Azure：DDoS Protectionとして常時監視・自動調整・分析の性格が強調される
  という“語り口”の違いが出ます。

マルチクラウドで共通化するなら、次の軸で比較するとぶれにくいです。

• 自動緩和の範囲（どの入口・どの層まで）
• 運用時の可視化（攻撃中/攻撃後に何が見えるか）
• 価格モデル（固定費＋従量か、従量中心か、入口単位か）
• 体制（攻撃時の対応フローと責任範囲）

8. 今日から使える“導入チェックリスト”

最後に、Shieldを導入・強化するときに、最初の1〜2週間で決めると後が楽になる項目をまとめます。

1. 入口（保護対象）の棚卸し

• 公開点はどこか、統一できるか

2. 優先順位

• 落ちたら困る入口を3つ挙げる

3. Shield Advancedの要否

• 固定費を払ってでも守る価値があるか（事業影響で説明できるか）

4. 攻撃時の運用フロー

• 誰が判断し、誰に連絡し、どこを確認するか

5. 復旧後の振り返り項目

• 入口の集約、可視化、コスト、対応体制の改善点

これだけでも、DDoS対策が“ふわっとした不安”から“設計と運用の課題”に変わり、チームで扱いやすくなります。

まとめ：Shieldは「標準の土台＋必要な強化＋運用プロセス」で完成します

AWS Shieldは、既知・ゼロデイを含む広範なDDoS攻撃ベクトルへの保護を提供し、StandardはAWS利用時に自動提供・追加料金なし、Advancedでより高い保護を選べることが公式に示されています。
Shield Advancedは月額固定費（例：3,000 USD）を中心に、場合によってデータ転送の従量が加わる料金例が明確に示されており、導入判断を事業影響とコストの比較で行いやすい構造です。

GCPはCloud Armor Standardで“常時DDoS保護”が明記され、AzureはDDoS Protectionで常時監視・自動チューニング・分析を強調しています。
ただ、どのクラウドでも本質は同じで、入口の集約、優先順位付け、攻撃時の運用フロー、復旧後の改善が揃って初めて、DDoS対策は現実的に強くなります。

参考リンク（公式中心）

• AWS Shield と Shield Advanced の概要（公式ドキュメント）
• AWS Shield 料金（日本語）
• GCP Cloud Armor Enterprise overview（Standardに常時DDoS保護を含む）
• GCP Cloud Armor 製品概要
• Azure DDoS Protection 概要（日本語）
• Azure DDoS Protection Overview（英語）