--- title: "AWS Shieldとは？StandardとAdvancedの違い・料金と採用判断を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15892/" published: 2026-07-30 updated: 2026-09-18 categories: ["セキュリティ"] publisher: "株式会社一創" --- # AWS Shieldとは？StandardとAdvancedの違い・料金と採用判断を実装者目線で解説 AWS ShieldはDDoS攻撃からAWS上のアプリケーションを守るサービスで、追加料金なしで全アカウントに自動適用されるStandardと、月額3,000USDのAdvancedに分かれます。判断が難しいのは、Advancedを契約しただけではどのリソースも保護されない点、請求が月額だけで終わらない点、そして2026年3月26日にレイヤー7の既定手段がAnti-DDoS AMRへ移った点です。保護できるリソースの範囲、AWS CLIでの有効化手順、データ転送料金とAWS WAF費用の内包範囲、SRTを呼ぶ条件、採用と見送りの線引きを実装者目線で整理します。 ## まとめ：AWS Shieldの2階層構造と契約前に確認すべき前提 AWS Shieldは2階層です。Standardは全AWS顧客に自動適用され、レイヤー3・4の一般的な攻撃を常時のフローモニタリングで検知して緩和します。有効化操作も課金も発生しません。有料層のAdvancedは月額3,000USDに1年間の契約コミットが付き、データ転送料金が加算されます。 契約前に確認する前提は4つあります。第1に、Advancedは保護対象を自動では選びません。明示指定するかFirewall Managerのポリシー経由で指定したリソースだけが対象で、指定漏れは無防備のまま残ります。第2に、SRT（Shield Response Team）へエスカレーションするにはBusiness以上のサポートプランが要ります。Developerプランのままでは、緊急時に人を呼べない状態で月額を払うことになるでしょう。第3に、標準的なAWS WAF費用が含まれるため、既にWAFを広く運用している組織ほど実質の差額は縮みます。第4に、HTTPリクエストフラッドへの既定の打ち手が2026年3月26日にAnti-DDoS マネージドルールグループへ移り、Advancedを契約しなくてもAWS WAF単体でレイヤー7の自動緩和が組めるようになりました。判断の線は組織規模ではなく、停止1時間あたりの機会損失額と保護指定を維持する体制の有無で引いてください。 ## AWS ShieldがStandardとAdvancedで分かれる保護範囲の実態 無料で既に効いている範囲と、金を払って足す範囲を分けて把握します。ここを混ぜると「Advancedを入れないと無防備」という誤った前提で設計が進みます。 ### Shield Standardが自動適用されるレイヤー3・4の防御範囲 Standardは、AWSへ流入するトラフィックを常時モニタリングし、シグネチャと異常検知アルゴリズムで攻撃を判定します。緩和の手法は決定的パケットフィルタリングと優先度ベースのトラフィックシェーピングで、SYNフラッド、UDPフラッド、リフレクション攻撃といった頻度の高いレイヤー3・4の攻撃が守備範囲です。攻撃の型そのものは[DDoS攻撃とは？仕組み・種類とDoS攻撃との違い、企業が取るべき対策](https://www.issoh.co.jp/column/details/13260/)で整理しています。 押さえるべきは、Standardに申し込みも設定も不要という点です。コンソールに有効化ボタンが見当たらないのは仕様であり、設定漏れではありません。[AWS Shield料金ページ](https://aws.amazon.com/shield/pricing/)にも、Standardは追加料金なしで全顧客へ提供されると明記されています。 ### CloudFrontとRoute 53で常時保護が完結する構成の理由 Standardの保護強度は、どのサービスで受けるかによって変わります。CloudFrontとRoute 53を使う場合、既知のインフラ層（レイヤー3・4）攻撃に対する包括的な可用性保護が受けられるとAWSは説明しています。エッジロケーションで攻撃を吸収し、オリジンまで到達させない構造だからです。 この差は設計に直結します。公開エンドポイントをCloudFront配下へ寄せてオリジンを直接叩けない状態にすれば、無料の範囲で吸収できる攻撃の幅が広がります。配信側は[Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断](https://www.issoh.co.jp/tech/details/15431/)、DNS側は[Amazon Route 53とは？DNS・ドメイン登録・ルーティング設計](https://www.issoh.co.jp/tech/details/15471/)を先に固めてから、Advancedの要否を判断する順序が無駄になりません。 ### Shield Advancedが明示指定した資源だけを保護する仕様 Advancedで最も事故が起きやすいのがこの仕様です。公式ドキュメントの[保護対象リソース一覧](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary-protected-resources.html)は「Shield Advancedはリソースを自動的には保護しない」と冒頭の注記で明言しています。保護が有効になるのは、Shield Advancedで明示的に指定したリソースか、Firewall ManagerのShield Advancedポリシーで指定したリソースだけです。 つまり、契約後にALBを追加した、EIPを付け替えた、といった変更のたびに保護指定が要ります。手作業に頼ると、増えたリソースから静かに保護が抜け落ちていくため、後述するFirewall Managerによる組織レベルの自動適用が実装上の要になります。 ### IPv6非対応とGateway Load Balancerなど保護できない構成 対象外の線引きも設計前に把握してください。[リソース種別ごとの保護一覧](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-protections-by-resource-type.html)には、Shield AdvancedがIPv4をサポートしIPv6はサポートしないと書かれています。デュアルスタック構成でIPv6側の受け口を持つなら、そこはAdvancedの守備範囲に入りません。 リソース側にも除外があります。Global Acceleratorのカスタムルーティングアクセラレーター、Gateway Load Balancerは保護できません。NAT Gatewayは送信方向のトラフィックを扱う仕組みで、受信方向のDDoSを守るShield Advancedの対象外です。送信方向の制御が要るならAWS Network Firewallを別途組む、という切り分けになります。 ## Shield Advancedの保護対象リソースと有効化の実装手順 保護できる対象は限定列挙です。守りたいものが一覧に無いなら、その手前に対象となるリソースを置く構成変更が先になります。 ### Shield Advancedが保護できる6種類のリソースとNLBの制約 対象はCloudFrontディストリビューション、Route 53ホストゾーン、Global Acceleratorの標準アクセラレーター、EC2のElastic IP、Application Load BalancerとClassic Load Balancer、Elastic IP経由のEC2インスタンスです。CloudFrontの継続的デプロイでは、プライマリ配信に紐づくステージング配信も保護されます。 | リソース | 保護の指定方法 | | ------------------ | ------------- | | CloudFront配信 | 配信を直接指定 | | Route 53ホストゾーン | ホストゾーンを指定 | | Global Accelerator | 標準アクセラレーターのみ | | ALB・CLB | ロードバランサーを指定 | | NLB・EC2 | Elastic IPを指定 | 注意が必要なのはNLBです。直接指定するのではなく、関連付けたElastic IP経由で保護します。EIPを持たない内部NLBでは指定できないため、NLBを前段に置く設計では先にEIPの割り当て方針を決めてください。ALBは直接指定できます。 ### AWS CLIでの保護登録とRoute 53ヘルスチェックの紐づけ手順 コンソールでも登録できますが、保護対象が増える環境ではCLIで型を作っておくほうが漏れません。[aws shield create-protection](https://docs.aws.amazon.com/cli/latest/reference/shield/create-protection.html)は`--name`と`--resource-arn`の2つが必須で、戻り値の`ProtectionId`を後続のヘルスチェック紐づけに使います。 ``` # 保護対象を登録する（CloudFront配信の例） aws shield create-protection \ --name "prod-cloudfront" \ --resource-arn arn:aws:cloudfront::123456789012:distribution/E198WC25FXOWY8 # 戻り値の ProtectionId に Route 53 ヘルスチェックを紐づける aws shield associate-health-check \ --protection-id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --health-check-arn arn:aws:route53:::healthcheck/11111111-2222-3333-4444-555555555555 # 契約状態（開始・終了日時と自動更新）を確認する aws shield describe-subscription \ --query "Subscription.[StartTime,EndTime,AutoRenew]" ``` ヘルスチェックを関連付けると、Shieldは健全性を検知判断の材料に加えます。公式ドキュメントの[ヘルスベース検知](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-health-checks.html)によると、レイヤー3・4ではより小さい攻撃への緩和と早い適用が可能になり、レイヤー7では健全性が損なわれている間はより小さな偏差でアラートが上がります。関連付けられるのはRoute 53ホストゾーン以外の全種別で、関連付け時点でヘルスチェックが正常を返していることが必要な条件です。 ### 自動アプリケーション層DDoS緩和が消費するWCUと前提条件 レイヤー7の攻撃に対しては、自動アプリケーション層DDoS緩和を有効にできます。有効化すると、Shield Advancedが保護パック（web ACL）に自身の管理するルールグループを追加し、そのルールグループは150WCUを消費します。消費分はweb ACLのWCU使用量に算入されるため、既にルールを積んでいる環境では上限との兼ね合いを先に確認してください。 前提は3つあります。対象リソースにAWS WAFのweb ACLが関連付けられていること、そのweb ACLがWAFの最新版（v2）で作られていること、そしてトラフィックのベースライン確立に24時間から30日かかることです。契約直後は自動緩和が本領を出せない期間があると見込んで、初動はレートベースルールで受けます。CloudFront経由のALBでは自動緩和の効きが落ちるため、CloudFront側で有効にするのが公式の推奨です。 ### リソース種別ごとの1,000件上限と保護漏れを潰す棚卸し手順 保護件数は無制限ではなく、上限付きです。1つのAWSアカウントで、リソース種別ごとに最大1,000件まで監視・保護できます。Elastic IPを1,000件、CloudFront配信を1,000件、ALBを1,000件というように種別単位で数える方式で、足りない場合はService Quotasから引き上げを申請します。 実務で効くのは上限そのものより、上限に近づいたときの副作用です。Firewall Manager経由で保護を配る構成では、1,000件を超えるとDDoS攻撃の通知が届かなくなる場合があるとAWSが明記しています。通知経路をSNSだけに頼らず、`DDoSDetected`メトリクスのCloudWatchアラームを併走させる理由がここにあります。 ## 月額3,000USDと転送量課金で決まるShield Advancedの費用 以下はAWS Shield料金ページの米国リージョン表記に基づく2026年9月時点の値です。リージョンによって単価は異なります。 ### Shield Advancedの1年コミットと組織単位課金という契約条件 Advancedのサブスクリプションは月額3,000USDで、1年間の契約コミットが条件です。月単位で入って抜ける使い方はできません。課金の単位はアカウントではなく請求ファミリーで、[Shield Advancedの概要](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html)には、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億リクエストまでが範囲内で、超過分は[AWS WAF料金](https://aws.amazon.com/waf/pricing/)と併せてShield料金表の単価で課金されます。Bot Control、CAPTCHAアクション、1,500WCU超のweb ACL、既定を超えるボディ検査、保護指定していないリソースのWAF利用料は対象外です。詳しくは[WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方](https://www.issoh.co.jp/tech/details/13275/)と併読すると、二重に払う箇所が見えます。 ### DDoSコスト保護でスケーリング課金の返還を申請する手順と条件 Advancedには、攻撃に起因して膨らんだ課金を守るDDoSコスト保護が付きます。対象はEC2、Elastic Load Balancing、CloudFront、Global Accelerator、Route 53のスケーリング課金です。攻撃で保護対象がスケールした場合、通常のAWSサポート窓口からクレジットを申請する流れになります。 自動で相殺される仕組みではない点に注意してください。申請時には攻撃の発生時刻と対象リソース、増分の内訳を示すため、Shieldのイベント履歴とCloudWatchメトリクス、請求データを突き合わせられる状態を平時から作っておきます。なお料金ページには、コスト保護を含むAdvancedの特典が1年コミットの履行を前提とする旨が記載されています。 ## 2026年3月のAnti-DDoS AMR既定化とL7自動緩和の移行判断 レイヤー7の守り方は、2026年に前提が入れ替わりました。ここを踏まえずに古い記事のとおり設計すると、Advancedを契約する理由そのものを取り違えます。 ### Anti-DDoS AMRがHTTPリクエストフラッド対策の既定になった変更 [自動アプリケーション層DDoS緩和のドキュメント](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html)には、2026年3月26日以降、AWS WAFのAnti-DDoSマネージドルールグループがHTTPリクエストフラッド対策の既定手段になり、従来のLayer 7 Auto Mitigation（L7AM）に取って代わる旨が注記されています。既存のShield Advanced契約者はレガシー機能を使い続けられますが、新規契約者がL7AMを使うにはAWSサポートへの依頼が要ります。 差はスピードです。AWSはAnti-DDoS AMRについて、攻撃の検知と緩和が分単位ではなく秒単位で完了すると説明しています。L7AMはベースライン確立に24時間から30日を要し、カスタムルールの配備までにも時間がかかる仕組みでした。新規に設計するなら、L7AMではなくAnti-DDoS AMRを前提に置いてください。 ### AWS WAF単体で組めるAnti-DDoS AMRの構成と感度設定の勘所 Anti-DDoS AMRは`AWSManagedRulesAntiDDoSRuleSet`という名前の、ベンダー名AWSのマネージドルールグループです。消費WCUは50。[ルールグループの仕様](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-anti-ddos.html)によると、収録ルールは`ChallengeAllDuringEvent`、`ChallengeDDoSRequests`、`DDoSRequests`の3本で、前2つが無言のブラウザチャレンジ（ソフト緩和）、最後の1本がブロック（ハード緩和）を担当します。 ``` { "Name": "anti-ddos", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesAntiDDoSRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesAntiDDoSRuleSet": { "SensitivityToBlock": "LOW", "ClientSideActionConfig": { "Challenge": { "UsageOfAction": "ENABLED", "Sensitivity": "HIGH", "ExemptUriRegularExpressions": [ { "RegexString": "\\/api\\/|\\.(css|gif|jpe?g|js|png|woff2?)$" } ] } } } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "anti-ddos" } } ``` `SensitivityToBlock`の既定はLOWで、疑いの強いリクエストだけをブロックします。チャレンジ側の`Sensitivity`は既定HIGHで、低・中・高すべての疑いラベルに反応します。`ExemptUriRegularExpressions`には、HTMLを期待しないクライアントが叩くパスを列挙してください。APIエンドポイントや静的ファイルをここから外し忘れると、チャレンジに応答できないクライアントが実質ブロックされます。AWSはこのルールグループにスコープダウンステートメントを使わないよう明記しています。観測対象が減るとベースラインが不正確になるためです。 ### L7AMを継続する条件とAnti-DDoS AMRへ切り替える判断基準 切り替えの判断は言い切れます。**新規にレイヤー7の自動緩和を組むなら、Anti-DDoS AMRを選んでください。**秒単位の緩和、感度の明示設定、ラベルによる後段ルールでの制御という3点が揃っており、L7AMを新規で選ぶ理由はほぼ残っていません。 L7AMを継続するのは、既に本番で機能しており、切り替え時の挙動変化を評価する時間が取れない場合に限られます。移行する場合も、いきなり本番へ入れないでください。[AWSの導入手順](https://docs.aws.amazon.com/waf/latest/developerguide/waf-anti-ddos-rg-using.html)は、検証環境で調整したうえで本番トラフィックに対してカウントモードで試し、影響を確認してから有効化する順序を求めています。ルールの優先順位は、Allowアクションのルールの直後、ほかのルールより前に置きます。 ## AWS WAFとの役割分担とCloudFront前提の構成の考え方 ShieldとWAFは代替関係ではありません。守る層が違うため、どちらか片方で足りるという整理にはなりません。 ### L3・L4はShield、L7はWAFという責務の切り分け方 Shieldが得意なのは、帯域とパケットで殴ってくるレイヤー3・4の攻撃です。SYNフラッドやリフレクション攻撃はアプリに届く前に落とすしかなく、AWSのネットワーク側でしか処理できません。対してSQLインジェクションやログイン試行の連打は、中身を見るWAFの領域です。 レイヤー7のDDoSは、その中間に位置します。実体はWAFのルールグループとして動くため、Shield Advancedを契約してもweb ACLが無ければ何も起きません。Anti-DDoS AMRが既定になったことで、この関係はさらにはっきりしました。レイヤー7を守る主体はWAFであり、Shield AdvancedはSRT・コスト保護・レイヤー3・4の高度な緩和を足す位置づけです。 ### Global AcceleratorとCloudFrontで攻撃面を絞る設計 実装で効くのは、攻撃を受け得る面そのものを減らす構成です。HTTPやHTTPSはCloudFrontの背後に置き、オリジン側のセキュリティグループをCloudFrontのマネージドプレフィックスリストに限定します。TCPやUDPを直接扱うワークロードはGlobal Accelerator経由にすると、エッジで攻撃を受け止められます。保護指定すべきリソース数も減るため、契約前に済ませておきたい作業です。自社だけで構成の見直しが難しい場合は、[AWSを含むクラウドインフラの設計・構築支援](https://www.issoh.co.jp/service/system/aws/)で公開面の整理から相談できます。 ### Cloud ArmorやCloudflareと比べたときの選定の観点 他社のDDoS防御と比較する場面もあります。Google Cloudの[Cloud Armorとは？Google CloudのWAF／DDoS防御の仕組み・料金・実装判断](https://www.issoh.co.jp/tech/details/15566/)はロードバランサー前段で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側で組めます。2026年3月以降はAnti-DDoS AMRをweb ACLへ入れるだけで、Advanced契約なしに秒単位のチャレンジとブロックが手に入ります。50WCUと追加のルールグループ料金で済むため、月額3,000USDとの差は大きいでしょう。レートベースのルールでIP単位のリクエスト数を制限し、Auto Scalingの上限値を現実的な水準で止めておけば、攻撃時の請求暴走もある程度は抑えられます。ここまで組んだうえで足りない部分だけをAdvancedで埋める順序が費用面では合理的です。 ### Shield Advancedを見送るべき3つの条件と事前の確認事項 見送るべき条件は3つに絞れます。第1に、AWSサポートがDeveloperプラン以下の場合。SRTへのエスカレーションにはBusinessまたはEnterpriseが必要で、そこを満たさないままではAdvancedの目玉である人的支援を使えません。サポートプランの費用も含めて再計算してください。 第2に、保護指定を維持する運用が回らない場合です。登録漏れが常態化するなら、支払っている割に守れていない状態が続きます。第3に、1年以内に構成の大きな移行を予定している場合。1年コミットが条件のため、途中でアーキテクチャを変えても契約は残ります。判断の前に露出面を棚卸しすると精度が上がるので、自社で洗い出しきれない場合は[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で外部から見える攻撃面を先に確定させ、そのうえで保護対象を決めてください。 ## Shield Advanced導入後の監視・通知設計とSRT連絡の段取り 契約は入口で、価値が出るのは攻撃を受けた30分間の動き方です。ここを設計しないと、通知に気づいたときには既に終わっていたという結果になります。 ### CloudWatchメトリクスとアラームで異常を掴む具体的な設定 Shield Advancedは名前空間`AWS/DDoSProtection`にメトリクスを発行します。検知系の中心は`DDoSDetected`で、対象のARNで攻撃イベントが進行中かを示し、イベント中は0以外の値を取る指標です。ほかに`DDoSAttackBitsPerSecond`、`DDoSAttackPacketsPerSecond`（レイヤー3・4向け）、`DDoSAttackRequestsPerSecond`（レイヤー7向け）があります。[メトリクス一覧](https://docs.aws.amazon.com/waf/latest/developerguide/shield-metrics.html)には緩和系の`VolumePacketsPerSecond`と、送信元IPやASN、TCPフラグ別の上位寄与メトリクスも定義されています。 ``` aws cloudwatch put-metric-alarm \ --alarm-name shield-ddos-detected \ --namespace AWS/DDoSProtection \ --metric-name DDoSDetected \ --dimensions Name=ResourceArn,Value=arn:aws:cloudfront::123456789012:distribution/E198WC25FXOWY8 \ --statistic Maximum --period 60 --evaluation-periods 1 \ --threshold 0 --comparison-operator GreaterThanThreshold \ --treat-missing-data notBreaching \ --region us-east-1 \ --alarm-actions arn:aws:sns:us-east-1:123456789012:ddos-alert ``` AWSが推奨する起点は、保護リソースごとに`DDoSDetected`が0以外になったら通知するアラームです。値が0以外でも必ず攻撃とは限らず、リクエストフラッドは健全性やリクエスト量を組み合わせた複合条件で鳴らす構成が推奨されています。報告頻度は攻撃中が毎分、平時は1日1回のため、欠損を違反扱いしない`notBreaching`の指定が要ります。CloudFrontとRoute 53、および保護グループのメトリクスはus-east-1へ報告される点にも注意してください。 ### SRTへの事前アクセス許可とプロアクティブ関与を使う設定手順 SRTは、攻撃の前後と最中に支援を受けられる24時間365日の窓口です。[SRTサポートのドキュメント](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-srt-support.html)には、利用にはBusinessまたはEnterpriseのサポートプラン契約が必要と注記されています。SRTができるのはWAFログの解析とルール適用、インフラ層のカスタム緩和の作成、ネットワークトラフィックの調整、構成面の助言の4種です。攻撃当日にSRTがWAFのルールを触れるようにするには、事前にIAMロールでアクセスを許可する設定が要ります。 [プロアクティブ関与](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-srt-proactive-engagement.html)を使うなら、前述のヘルスチェック関連付けが前提です。健全性が損なわれた状態を起点にAWS側から接触してもらう仕組みのため、未設定だと機能しません。SRTの認可はアカウント単位で、Firewall Manager管理者ではなく各アカウントの所有者が実施します。契約初日にSRTのアクセス許可、ヘルスチェック関連付け、連絡先の登録をまとめて済ませておくのが実務的です。 ### Firewall Manager展開で漏れる2種別と補完する運用設計 保護指定の漏れを構造的に潰す手段がFirewall Managerです。Shield Advancedポリシーを作ると組織内の対象リソースへ保護を自動適用でき、新規リソースも条件に合致すれば取り込まれます。メンバーアカウントのShield Advanced登録もポリシー作成時に代行されます。 ただし穴があります。[Firewall ManagerのShield Advancedポリシー手順](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-shield.html)は、Route 53とGlobal Acceleratorをサポートしないと3箇所で繰り返し警告しています。この2種別だけはアカウント個別に手で保護指定するしかありません。CloudFront以外のリージョナルリソースはリージョンごとに別ポリシーが要る点も含め、ポリシーで配れる範囲と手作業で残る範囲を台帳に分けて持ってください。保護状況の可視化先を決めるなら、検出結果を横断で集約する[AWS Security Hubとは？CSPMとの違い・料金と導入判断](https://www.issoh.co.jp/tech/details/15890/)が受け皿になります。攻撃検知から緩和までの手順や体制づくりは[AWS Shieldを利用した効果的なDDoS攻撃対策](https://www.issoh.co.jp/column/details/2705/)で扱っているため、本記事で構成と費用を固めたら、そちらへ引き継ぐと運用設計まで途切れません。 ## AWS Shieldの料金・保護範囲と運用に関するよくある質問 検索でよく問われる5点を、公式ドキュメントの記載に沿って答えます。 ### AWS Shield Standardを有効化する設定はどこにありますか？ 設定は存在しません。Standardは全AWS顧客へ追加料金なしで自動適用されており、申し込みも有効化操作も不要です。コンソールで有効化を求められる項目はAdvancedの契約に関するものです。Standardの強度を上げたいなら、設定を探すのではなくCloudFrontとRoute 53の背後へ公開エンドポイントを寄せる構成変更が答えになります。 ### Shield Advancedは1アカウントだけ契約すれば足りますか？ 同一のAWS Organizations一括請求ファミリー内であれば、複数アカウントを登録しても1つのサブスクリプション料金でカバーされ、請求は支払いアカウントに対して行われます。ただし料金がカバーされることと保護が有効になることは別で、各アカウントのリソースを明示的に保護指定する作業は引き続き必要です。組織を複数またぐ場合は、すべてを自社が所有していることを前提に、アカウントマネージャーへ免除を申請する経路があります。 ### Advancedを契約するとAWS WAFの料金は無料になりますか？ 保護対象リソースの標準的なWAF利用料は含まれます。対象は保護パック（web ACL）単位、ルール単位、Webリクエスト検査の基本料金で、1,500WCUまでかつ既定のボディサイズまでという条件が付きます。Bot Control、CAPTCHAアクション、1,500WCU超のweb ACL、既定を超えるボディ検査、保護指定していないリソースのWAF利用料は対象外です。暦月あたり500億リクエストを超えた分も別途課金されます。 ### Anti-DDoS AMRはShield Advancedを契約しないと使えませんか？ 使えます。`AWSManagedRulesAntiDDoSRuleSet`はAWS WAFのマネージドルールグループで、web ACLへ追加すればShield Advanced契約なしに動きます。その場合はルールグループの追加料金の支払いが必要です。Shield Advancedを契約している場合は、保護指定したリソースについて暦月500億リクエストまでが月額に含まれる扱いになります。レイヤー7だけが課題なら、Advancedを契約する前にこちらを検討してください。 ### AWS Shield network security directorはもう使えますか？ 2025年6月に発表された機能で、2026年9月時点でもパブリックプレビュー段階です。アカウント内のリソースを検出し、トポロジーと設定をAWSのベストプラクティスや脅威情報と突き合わせて評価する仕組みです。2025年12月にマルチアカウント分析、2026年3月にSecurity Hubへの検出結果連携が加わり、[AWS Organizationsのポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs%5Fmanage%5Fpolicies%5Fnetwork%5Fsecurity%5Fdirector.html)で組織単位の有効化も指定できます。ただしAWS Shield料金ページには、Shield AdvancedにもStandardにもnetwork security directorは含まれないと明記されています。プレビュー中の課金有無とGA時の価格が未確定のため、本番の前提に組み込むのは時期尚早でしょう。 ## 関連記事 - [AWS Shieldを利用した効果的なDDoS攻撃対策](https://www.issoh.co.jp/column/details/2705/)：導入後の攻撃対策運用と体制づくり。 - [DDoS攻撃とは？仕組み・種類とDoS攻撃との違い、企業が取るべき対策](https://www.issoh.co.jp/column/details/13260/)：守る対象となる攻撃の型。 - [WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方](https://www.issoh.co.jp/tech/details/13275/)：レイヤー7を担う防御層。 - [Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断](https://www.issoh.co.jp/tech/details/15431/)：攻撃面を絞る前段の設計。 - [Cloud Armorとは？Google CloudのWAF／DDoS防御の仕組み・料金・実装判断](https://www.issoh.co.jp/tech/details/15566/)：他クラウドの対応サービス。 --- 出典: [AWS Shieldとは？StandardとAdvancedの違い・料金と採用判断を実装者目線で解説]()（株式会社一創）