AWS Shieldとは？StandardとAdvancedの違い・料金と採用判断を実装者目線で解説

AWS ShieldはDDoS攻撃からAWS上のアプリケーションを守るサービスで、追加料金なしで全アカウントに自動適用されるStandardと、月額3,000USDのAdvancedに分かれます。判断が難しいのは、Advancedを契約しただけではどのリソースも保護されない点、そして請求が月額だけで終わらない点です。保護できるリソースの範囲、有効化の実装手順、データ転送料金とAWS WAF費用の内包範囲、SRTを呼ぶ条件、採用と見送りの線引きを実装者目線で整理します。

まとめ：AWS Shieldの2階層構造と契約前に確認すべき前提

AWS Shieldは2階層です。Standardは全AWS顧客に自動適用され、レイヤー3・4の一般的な攻撃を常時のフローモニタリングで検知して緩和します。有効化操作も課金も発生しません。有料層のAdvancedは月額3,000USDに1年間の契約コミットが付き、データ転送料金が加算されます。

契約前に確認する前提は3つあります。第1に、Advancedは保護対象を自動では選びません。明示指定するかFirewall Managerのポリシー経由で指定したリソースだけが対象で、指定漏れは無防備のまま残ります。第2に、SRT（Shield Response Team）へエスカレーションするにはBusiness以上のサポートプランが要ります。Developerプランのままでは、緊急時に人を呼べない状態で月額を払うことになるでしょう。第3に、標準的なAWS WAF費用が含まれるため、既にWAFを広く運用している組織ほど実質の差額は縮みます。判断の線は組織規模ではなく、停止1時間あたりの機会損失額と保護指定を維持する体制の有無で引いてください。

AWS ShieldがStandardとAdvancedで分かれる保護範囲の実態

無料で既に効いている範囲と、金を払って足す範囲を分けて把握します。ここを混ぜると「Advancedを入れないと無防備」という誤った前提で設計が進みます。

Shield Standardが自動適用されるレイヤー3・4の防御範囲

Standardは、AWSへ流入するトラフィックを常時モニタリングし、シグネチャと異常検知アルゴリズムで攻撃を判定します。緩和の手法は決定的パケットフィルタリングと優先度ベースのトラフィックシェーピングで、SYNフラッド、UDPフラッド、リフレクション攻撃といった頻度の高いレイヤー3・4の攻撃が守備範囲です。攻撃の型そのものはDDoS攻撃とは？仕組み・種類とDoS攻撃との違い、企業が取るべき対策で整理しています。

押さえるべきは、Standardに申し込みも設定も不要という点です。コンソールに有効化ボタンが見当たらないのは仕様であり、設定漏れではありません。

CloudFrontとRoute 53で常時保護が完結する構成の理由

Standardの保護強度は、どのサービスで受けるかによって変わります。CloudFrontとRoute 53を使う場合、既知のインフラ層（レイヤー3・4）攻撃に対する包括的な可用性保護が受けられるとAWSは説明しています。エッジロケーションで攻撃を吸収し、オリジンまで到達させない構造だからです。

この差は設計に直結します。公開エンドポイントをCloudFront配下へ寄せてオリジンを直接叩けない状態にすれば、無料の範囲で吸収できる攻撃の幅が広がります。配信側はAmazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断、DNS側はAmazon Route 53とは？DNS・ドメイン登録・ルーティング設計を先に固めてから、Advancedの要否を判断する順序が無駄になりません。

Shield Advancedが明示指定した資源だけを保護する仕様

Advancedで最も事故が起きやすいのがこの仕様です。公式ドキュメントは「Shield Advancedはリソースを自動的には保護しない」と明記しています。保護が有効になるのは、Shield Advancedで明示的に指定したリソースか、Firewall ManagerのShield Advancedポリシーで指定したリソースだけです。

つまり、契約後にALBを追加した、EIPを付け替えた——といった変更のたびに保護指定が要ります。手作業に頼ると、増えたリソースから静かに保護が抜け落ちていくため、後述するFirewall Managerによる組織レベルの自動適用が実装上の要になります。

Shield Advancedの保護対象リソースと有効化の実装手順

保護できる対象は限定列挙です。守りたいものが一覧に無いなら、その手前に対象となるリソースを置く構成変更が先になります。

Shield Advancedが保護できる6種類のリソースとNLBの制約

対象はCloudFrontディストリビューション、Route 53ホストゾーン、Global Acceleratorの標準アクセラレーター、EC2のElastic IP、Application Load BalancerとClassic Load Balancer、Elastic IP経由のEC2インスタンスです。CloudFrontの継続的デプロイでは、プライマリ配信に紐づくステージング配信も保護されます。

注意が必要なのはNLBです。直接指定するのではなく、関連付けたElastic IP経由で保護します。EIPを持たない内部NLBでは指定できないため、NLBを前段に置く設計では先にEIPの割り当て方針を決めてください。ALBは直接指定できます。

Route 53ヘルスチェック連携で検知の精度を上げる設定手順

Advancedにはヘルスベース検知があります。Route 53のヘルスチェックを保護対象に関連付けると、Shieldは健全性を検知判断の材料に加えるため、応答性と精度が上がる仕組みです。トラフィック量だけを見る検知より、正常なスパイクと攻撃の区別がつきやすくなります。

手順は、Route 53でヘルスチェックを作成し、Shield Advancedの保護設定から関連付けるだけです。作業量は小さい一方で、後述するプロアクティブ関与を機能させる前提にもなるため、契約直後の初期設定でまとめて済ませてください。

自動アプリケーション層DDoS緩和が消費するWCUと有効化の前提

レイヤー7の攻撃に対しては、自動アプリケーション層DDoS緩和を有効にできます。有効化すると、Shield Advancedが保護パック（web ACL）に自身の管理するルールグループを追加し、そのルールグループは150WCUを消費します。消費分はweb ACLのWCU使用量に算入されるため、既にルールを積んでいる環境では上限との兼ね合いを事前に確認してください。

前提として、対象リソースにAWS WAFのweb ACLが関連付けられている必要があります。Shield Advancedだけを契約してもレイヤー7の自動緩和は動きません。またこのルールグループが生成するWAFメトリクスは、AWSマネージドルールと同じく閲覧できない扱いのため、挙動を追うなら自前のルールとログ側に観測経路を用意します。

月額3,000USDと転送量課金で決まるShield Advancedの費用

以下はAWS Shield料金ページの米国リージョン表記に基づく2026年7月時点の値です。リージョンによって単価は異なります。

Shield Advancedの1年コミットと組織単位課金という契約条件

Advancedのサブスクリプションは月額3,000USDで、1年間の契約コミットが条件です。月単位で入って抜ける使い方はできません。課金の単位はアカウントではなく請求ファミリーで、Organizations配下では支払いアカウントへ請求され、同一の一括請求ファミリー内なら複数アカウントを登録しても1契約分でカバーされます。

この構造のため、アカウントを細かく分けている組織ほど1アカウントあたりの負担は下がります。逆に単一アカウントで小規模なサービスを1本だけ動かす環境では、月額がそのまま重くのしかかります。試算の初手は請求ファミリーにぶら下がる本番エンドポイントを数えることです。

データ転送料金の単価差と標準WAF費用が含まれる範囲の線引き

月額とは別に、保護対象を経由したデータ転送料金が加算されます。単価はCloudFrontが1GBあたり0.025USD、ELB・EC2・Global Acceleratorが1GBあたり0.050USDです。転送量の多いサービスをELB直下で公開しているなら、CloudFrontを前段に挟むだけで単価が半額側に寄ります。

費用面の見落としが多いのはAWS WAF側です。Advancedのサブスクリプションは、保護対象リソースの標準的なWAF利用料——保護パック（web ACL）単位、ルール単位、100万リクエストあたりの検査基本料金——を、1,500WCUかつ既定のボディサイズまでカバーします。Layer 7 Anti-DDoSのマネージドルールグループも含まれ、暦月あたり500億リクエストまでが範囲内です。詳しくはWAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方と併読すると、二重に払う箇所が見えます。

DDoSコスト保護でスケーリング課金の返還を申請する手順と条件

Advancedには、攻撃に起因して膨らんだ課金を守るDDoSコスト保護が付きます。対象はEC2、Elastic Load Balancing、CloudFront、Global Accelerator、Route 53のスケーリング課金です。攻撃で保護対象がスケールした場合、通常のAWSサポート窓口からクレジットを申請する流れになります。

自動で相殺される仕組みではない点に注意してください。申請時には攻撃の発生時刻と対象リソース、増分の内訳を示すため、Shieldのイベント履歴とCloudWatchメトリクス、請求データを突き合わせられる状態を平時から作っておきます。なお料金ページには、コスト保護を含むAdvancedの特典が1年コミットの履行を前提とする旨が記載されています。

AWS WAFとの役割分担とCloudFront前提の構成の考え方

ShieldとWAFは代替関係ではありません。守る層が違うため、どちらか片方で足りるという整理にはなりません。

L3・L4はShield、L7はWAFという責務の切り分け方

Shieldが得意なのは、帯域とパケットで殴ってくるレイヤー3・4の攻撃です。SYNフラッドやリフレクション攻撃はアプリに届く前に落とすしかなく、AWSのネットワーク側でしか処理できません。対してSQLインジェクションやログイン試行の連打は、中身を見るWAFの領域です。

Advancedの自動アプリケーション層緩和も、実体はWAFのルールグループとして動きます。レイヤー7を守る主体はあくまでWAFで、Shield Advancedはそこへ攻撃時の自動ルール生成を足す位置づけです。WAFを入れずにAdvancedだけ契約するという判断は、この順序を踏まえると消えます。

Global AcceleratorとCloudFrontで攻撃面を絞る設計

実装で効くのは、攻撃を受け得る面そのものを減らす構成です。HTTPやHTTPSはCloudFrontの背後に置き、オリジン側のセキュリティグループをCloudFrontのマネージドプレフィックスリストに限定します。TCPやUDPを直接扱うワークロードはGlobal Accelerator経由にすると、エッジで攻撃を受け止められます。保護指定すべきリソース数も減るため、契約前に済ませておきたい作業です。

Cloud ArmorやCloudflareと比べたときの選定の観点

他社のDDoS防御と比較する場面もあります。Google CloudのCloud Armorとは？Google CloudのWAF／DDoS防御の仕組み・料金・実装判断はロードバランサー前段でWAFとDDoS防御を兼ね、CloudflareはCDNとDNSを含めた前段で受けます。

判断の観点は3つです。トラフィックの入口が既にどのベンダーにあるか、レイヤー7の防御ルールをどこで一元管理するか、支払いを二重にしないか。CDNを他社で運用しながらAWS側でもAdvancedを契約すると、同じ攻撃に対して2つの防御層へ払う構図になります。入口を持つベンダー側へ寄せるのが原則です。

Shield Advancedを採用すべき条件と見送るべき3つの状況

ここからは判断の話です。月額3,000USDは、可用性の要件と体制が揃っている環境でだけ意味を持つ支出になります。

月額3,000USDが妥当になる可用性要件と機会損失額の目安

採用の条件は「停止が金額になるか」で見ます。年間コストは月額3,000USDの12か月分に転送量を足した規模です。1時間の停止で数百万円の売上機会を失う、SLAの違約金が発生する、金融や公共のように可用性が契約要件になっている——こうした条件が1つでも当てはまるなら、コスト保護と24時間365日のSRTアクセスを含めた総額で見合います。

もう1つの採用条件は、実際に攻撃を受けた履歴です。レイヤー7のリクエストフラッドで自動スケールが暴走し請求が跳ねた経験があるなら、コスト保護が効く分だけ実質負担が下がります。攻撃を一度も観測していない環境で予防的に契約するより、まずStandardで受け止められる構成へ寄せるほうが費用対効果は高く出ます。

Shield Standardのままで足りる構成と代替手段の組み立て方

Standardのままで足りる典型は、公開エンドポイントが全てCloudFrontとRoute 53の配下にあり、オリジンが直接叩けない構成です。この形ならインフラ層の攻撃はエッジで吸収され、残る脅威はレイヤー7に寄ります。

その残りは、Advancedを待たずにWAF側で組めます。レートベースのルールでIP単位のリクエスト数を制限し、Bot Controlで自動化されたトラフィックを弾く。Auto Scalingの上限値を現実的な水準で止めておけば、攻撃時の請求暴走もある程度は抑えられます。ここまで組んだうえで足りない部分だけをAdvancedで埋める順序が費用面では合理的です。

Shield Advancedを見送るべき3つの条件と事前の確認事項

見送るべき条件は3つに絞れます。第1に、AWSサポートがDeveloperプラン以下の場合。SRTへのエスカレーションにはBusinessまたはEnterpriseが必要で、そこを満たさないままではAdvancedの目玉である人的支援を使えません。サポートプランの費用も含めて再計算してください。

第2に、保護指定を維持する運用が回らない場合です。登録漏れが常態化するなら、支払っている割に守れていない状態が続きます。第3に、1年以内に構成の大きな移行を予定している場合。1年コミットが条件のため、途中でアーキテクチャを変えても契約は残ります。判断の前に露出面を棚卸しすると精度が上がるので、自社で洗い出しきれない場合は脆弱性診断・セキュリティ診断で外部から見える攻撃面を先に確定させ、そのうえで保護対象を決めてください。

Shield Advanced導入後の監視・通知設計とSRT連絡の段取り

契約は入口で、価値が出るのは攻撃を受けた30分間の動き方です。ここを設計しないと、通知に気づいたときには既に終わっていたという結果になります。

CloudWatchメトリクスとイベント通知で異常を掴む設定

Shield Advancedは名前空間 AWS/DDoSProtection にメトリクスを発行します。中心となるのはDDoSDetectedで、対象のARNで攻撃イベントが進行中かを示し、イベント中は0以外の値を取る指標です。ほかにDDoSAttackBitsPerSecond、DDoSAttackPacketsPerSecond（レイヤー3・4向け）、DDoSAttackRequestsPerSecond（レイヤー7向け）があります。

AWSが推奨する起点は、保護リソースごとにDDoSDetectedが0以外になったら通知するアラームです。値が0以外でも必ず攻撃とは限らず、リクエストフラッドは健全性やリクエスト量を組み合わせた複合条件で鳴らす構成が推奨されています。報告は攻撃中が毎分、平時は1日1回のため、平時のデータが薄い前提でしきい値を決めます。なおCloudFrontとRoute 53のメトリクスはus-east-1に報告される点にも注意してください。

SRTへの事前アクセス許可とプロアクティブ関与を使う設定手順

SRTは、攻撃の前後と最中に支援を受けられる24時間365日の窓口です。依頼できるのはBusinessまたはEnterpriseのサポートプラン契約者に限られます。加えて、攻撃当日にSRTがWAFのルールを触れるようにするには、事前にIAMロールでアクセスを許可する設定が要ります。

プロアクティブ関与を使うなら、前述のヘルスチェック関連付けが前提です。健全性が損なわれた状態を起点にAWS側から接触してもらう仕組みのため、未設定だと機能しません。契約初日にSRTのアクセス許可、ヘルスチェック関連付け、連絡先の登録をまとめて済ませておくのが実務的です。

Firewall Managerで組織全体へ保護を展開する運用設計

保護指定の漏れを構造的に潰す手段がFirewall Managerです。Shield Advancedポリシーを作ると組織内の対象リソースへ保護を自動適用でき、新規リソースも条件に合致すれば取り込まれます。手作業の登録に依存しない形へ移せば、契約と実際の保護範囲のずれは解消されます。

あわせて、保護状況の可視化先も決めておきます。検出結果を横断で集約するならAWS Security Hubとは？CSPMとの違い・料金と導入判断が受け皿になります。Shieldを入れた後の実運用、つまり攻撃検知から緩和までの手順や体制づくりはAWS Shieldを利用した効果的なDDoS攻撃対策で扱っているため、本記事で構成と費用を固めたら、そちらへ引き継ぐと運用設計まで途切れません。

AWS Shieldの料金・保護範囲と運用に関するよくある質問

AWS Shield Standardを有効化する設定はどこにありますか？

設定は存在しません。Standardは全AWS顧客へ追加料金なしで自動適用されており、申し込みも有効化操作も不要です。コンソールで有効化を求められる項目はAdvancedの契約に関するものです。

Shield Advancedは1アカウントだけ契約すれば足りますか？

同一のAWS Organizations一括請求ファミリー内であれば、複数アカウントを登録しても1つのサブスクリプション料金でカバーされ、請求は支払いアカウントに対して行われます。ただし料金がカバーされることと保護が有効になることは別で、各アカウントのリソースを明示的に保護指定する作業は残ります。

Advancedを契約するとAWS WAFの料金は無料になりますか？

保護対象リソースの標準的なWAF利用料は含まれます。対象は保護パック（web ACL）単位、ルール単位、Webリクエスト検査の基本料金で、1,500WCUまでかつ既定のボディサイズまでという条件が付きます。Bot Control、CAPTCHAアクション、1,500WCU超のweb ACL、既定を超えるボディ検査、保護指定していないリソースのWAF利用料は対象外です。

攻撃で膨らんだ請求は返ってきますか？

DDoSコスト保護の対象になるのはEC2、Elastic Load Balancing、CloudFront、Global Accelerator、Route 53のスケーリング課金です。自動で相殺されるのではなく、通常のAWSサポート窓口からクレジットを申請します。裏付けとして攻撃時刻と増分を説明できるよう、イベント履歴とメトリクスを保全してください。

AWS Shield network security directorはもう使えますか？

2025年6月に発表された機能で、2026年7月時点でもパブリックプレビュー段階です。アカウント内のリソースを検出し、トポロジーと設定をAWSのベストプラクティスや脅威情報と突き合わせて低からクリティカルの深刻度で評価します。改善手順はAmazon Q Developerの自然言語照会で確認できます。プレビュー中は利用料の請求がないものの、GA時に価格が変わる旨を公式が明記しているため、本番の前提に組み込むのは時期尚早でしょう。

関連記事

• AWS Shieldを利用した効果的なDDoS攻撃対策：導入後の攻撃対策運用と体制づくり。
• DDoS攻撃とは？仕組み・種類とDoS攻撃との違い、企業が取るべき対策：守る対象となる攻撃の型。
• WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方：レイヤー7を担う防御層。
• Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断：攻撃面を絞る前段の設計。
• Cloud Armorとは？Google CloudのWAF／DDoS防御の仕組み・料金・実装判断：他クラウドの対応サービス。