AWSの脆弱性診断｜事前申請が要る範囲とツール選定・費用の判断基準

AWS環境の脆弱性診断でつまずく箇所は、だいたい決まっています。どこまでが自社の責任範囲なのか、AWSへの事前申請は要るのか、Amazon Inspectorを入れれば診断したことになるのか。この3点には公式ドキュメントに答えが書かれています。ところが国内の解説記事には、申請の線引きに触れないまま、すでにサポートが終了したAmazon Inspector Classicの操作を前提に書かれたものが残っています。2026年8月17日時点のAWS公式ポリシーと料金表をもとに、判断に必要な線引きだけを整理します。

まとめ

• AWSへの事前申請は、許可サービス一覧に載っているリソースへの診断であれば不要です。Simulated Eventsフォームの提出が要るのはレッドチーム演習・iPerf・模擬フィッシング・マルウェアテストの4類型で、開始日の2週間前までに申請します。
• DoS・DDoS・模擬DoS・ポートフラッディング・S3バケット乗っ取りなどは、申請の有無にかかわらず常に禁止されています。負荷試験は侵入テストポリシーではなく別のStress Testポリシーの管轄です。
• Amazon Inspector Classicは2026年5月20日でサポートが終了しました。「ネットワーク評価」「ホスト評価」「評価テンプレート」「ルールパッケージ」を説明している解説は、現行のInspectorには存在しない操作を指しています。
• Inspectorが診るのはOS・言語パッケージの既知脆弱性、ネットワーク到達性、そしてCode Securityによるソースコードの静的解析です。クラウド設定の不備はSecurity Hub CSPM、不審な挙動はGuardDutyが担当します。稼働中のWebアプリへ実際にリクエストを投げる動的診断は、いずれの守備範囲でもありません。
• EC2 50台・ECRイメージ200・Lambda 30関数の構成なら、Inspectorのセルフ診断は米国東部リージョン価格で月89.90ドルから。既知CVEの継続監視はこの単価で自動化できます。

以下では、この5点の根拠と、自社実施と外注のどちらに倒すかの分岐条件を順に見ていきます。

AWS利用企業が自分で診るべき範囲の決まり方

責任共有モデルの境界線とEC2・RDS・S3での差

AWSの責任共有モデルでは、AWSがクラウド「の」セキュリティを、利用者がクラウド「内」のセキュリティを担います。抽象的に聞こえますが、診断の実務では境界がサービスごとにはっきり動きます。

EC2は境界がいちばん深いところにあります。ゲストOS、ミドルウェア、アプリケーション、そこに載るパッケージまですべて利用者側です。つまりOSのCVE対応もパッチ適用も自社の仕事になります。一方でRDSはOSとデータベースエンジンの管理をAWSが引き受けるため、利用者が診るのはパラメータグループ・暗号化設定・ネットワーク到達範囲・認証情報の扱いに絞られます。S3にいたっては診断対象がほぼ設定だけです。バケットポリシー、ブロックパブリックアクセス、暗号化、アクセスログ。この3サービスを同じ「AWS脆弱性診断」という言葉でまとめると、必要な手段がまったく違うことを見落とします。

責任分界の考え方そのものを整理したい場合は、クラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方で全体像を確認してください。

OSパッケージ・クラウド設定・Webアプリで分かれる診断手段

AWS環境で見つかる問題は、性質の違う3つの層に分かれます。層が違えば検出する道具も違い、片方の道具でもう片方は見つかりません。

1層目はOS・言語パッケージの既知脆弱性です。ここはCVEと突き合わせる自動スキャンの領域で、Amazon Inspectorが担います。2層目はクラウド設定の不備です。公開されたままのS3バケット、過剰なIAM権限、無制限のセキュリティグループ。これらはCVEを持たないためInspectorのEC2スキャンでは検出できず、Security Hub CSPMのようなクラウド設定監査の役割になります。3層目はWebアプリケーションの実装欠陥、つまりSQLインジェクションやアクセス制御の不備です。

3層目のうち、ソースコードの静的解析はCode Security for Amazon Inspectorが引き受けます。公式ドキュメントは対象を自社実装のソースコード、サードパーティ依存関係、Infrastructure as Codeと定義しています。ただし読むのはリポジトリのコードであって、稼働中のアプリケーションに実際のリクエストを投げる動的診断ではありません。認可制御の欠陥やビジネスロジックの穴は静的解析でも取りこぼしが多く、この部分だけは手動診断の比重が高いままです。「Inspectorを入れたので脆弱性診断は済んだ」と判断してしまう構成が、いちばん危険です。診断手法そのものの分類は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説に整理しています。

AWSへの事前申請が要る診断行為・要らない診断行為

承認なしで実施できる許可サービスの範囲

結論から言えば、いま多くの企業が実施している脆弱性診断は事前申請なしで実行できます。AWSは「侵入テスト」ポリシーで、事前承認なしにセキュリティ評価を実施してよいサービスを明示しています。2026年8月17日時点の英語版ページに掲載されているのは次のとおりです。

• Amazon EC2インスタンス、WAF、NATゲートウェイ、Elastic Load Balancer
• Amazon RDS
• Amazon CloudFront
• Amazon Aurora
• Amazon API Gateway
• AWS AppSync
• AWS Lambda関数およびLambda Edge関数
• Amazon Lightsailリソース
• Amazon Elastic Beanstalk環境
• Amazon Elastic Container Service
• AWS Fargate
• Amazon OpenSearch Service
• Amazon FSx
• Amazon Transit Gateway
• Amazon Bedrock AgentCore

一般的なWebシステムはELB・EC2・RDS・CloudFrontの組み合わせで構成されるため、この一覧の中に収まります。かつて必要だった侵入テスト申請フォームの提出は、これらのサービスについては不要です。

常に禁止される行為と、フォーム提出が必要な4類型

申請が不要になったからといって、何をしてもよいわけではありません。ポリシーは禁止行為を個別に列挙しています。Amazon Route 53ホストゾーン経由のDNSゾーンウォーキング、Route 53経由のDNSハイジャックとDNSファーミング、DoS・DDoS・模擬DoS・模擬DDoS、ポートフラッディング、プロトコルフラッディング、リクエストフラッディング（ログインリクエスト・APIリクエスト）、S3バケット乗っ取り、サブドメイン乗っ取り。

ここで注意したいのが負荷試験の扱いです。大量の正規トラフィックを送るネットワークストレステストは、侵入テストポリシーではなく別途用意されたStress Testポリシーの管轄になります。禁止されているのは模擬DoSを含むフラッディング行為であって、正規の負荷試験そのものではありません。ただし手続きの窓口が分かれるため、負荷試験と脆弱性診断を同じ作業枠でまとめる計画は組み直しが必要です。

事前承認が必要な領域も残っています。ポリシーは「Command and Control（C2）を含むすべてのセキュリティテストには事前の承認が必要」と明記したうえで、Simulated Eventsフォームの提出を求める行為を4つ挙げています。

• レッドチーム／ブルーチーム／パープルチーム演習（隠密裏の敵対的シミュレーション、またはC2のホスティングを伴うもの）
• iPerfによる試験
• 模擬フィッシングキャンペーン
• マルウェアテスト

提出期限はいずれも開始日の2週間前までです。標的型メール訓練やレッドチーム演習を年間計画に組み込むなら、この2週間を最初からスケジュールに織り込んでおいてください。診断とレッドチーム演習の目的の違いはペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理で確認できます。

日本語ページだけを見ると許可リストを取り違える落とし穴

ここは実務で効く差分です。AWSの侵入テストポリシーは英語版と日本語版が公開されていますが、2026年8月17日時点で内容が一致していません。英語版の許可サービス一覧には末尾にAmazon Bedrock AgentCoreが含まれているのに対し、日本語版の許可サービス一覧にはこの項目がなく、Amazon Transit Gatewayで終わっています。

生成AIエージェントの基盤としてBedrock AgentCoreを使っている環境で、日本語版だけを根拠に「許可リストにないから申請が必要」と判断すると、不要な待ち時間が発生します。逆に日本語版にしか載っていない制限があれば、そちらを見落とします。AWSの各種ポリシーは英語版が先に更新される構造なので、診断範囲の可否を判断するときは英語版を正本として確認してください。判断に迷う項目が出たら、その場でAWSサポートに照会するほうが早く片付きます。

AWSネイティブ診断ツールの守備範囲と月額の実額

Amazon Inspectorが自動で診る対象とスキャン間隔

現行のAmazon Inspectorは、有効化すると対象リソースを自動検出して継続的にスキャンします。手動でスキャンを起動する運用ではありません。公式ドキュメントが定義するスキャン種別は、Amazon EC2スキャン、Amazon ECRスキャン、Lambda標準スキャン、Lambdaコードスキャン、Code Security for Amazon Inspectorの5つです。初回有効化時にはEC2・ECR・Lambda標準の3つが自動で有効になります。

EC2スキャンの収集方式は2種類あります。エージェントベースはSSMエージェント経由でソフトウェアインベントリを取得し、エージェントレスはEBSスナップショットから取得します。エージェントレスが受け持つのはSSM管理下にないインスタンスだけです。公式が挙げる対象条件は、ステータスがUnmanaged EC2 instance・Stale inventory・No inventoryのいずれかであること、EBSバックドでファイルシステムがext3・ext4・xfsのいずれかであること、アタッチされたボリュームが8本未満かつ合計1200GB以下であること。大容量インスタンスはこの条件を外れるため、SSM管理下に置かないとスキャン対象から漏れます。

既定のスキャンモードについては、公式ドキュメント内で記述が割れています。EC2スキャンの概要は有効化時にハイブリッドモードへ自動登録されると書いており、スキャンモード管理の節は新規有効化アカウントの既定をエージェントベースとしています。自社アカウントがどちらで動いているかは、コンソールのEC2スキャン設定で実際の値を確認してください。

スキャン頻度も把握しておくと運用設計が楽になります。ネットワーク到達性スキャンは12時間ごと、エージェントレスのパッケージ脆弱性スキャンは24時間ごと、エージェントレス対象として新たに該当したインスタンスの検出は1時間ごと、SSMインベントリの評価は既定で30分ごとです。「即座に結果が出ない」という問い合わせの多くは、この間隔で説明がつきます。

2026年5月31日には、エージェントベースEC2スキャンの新しいエンジンとしてInspector VM Scannerの提供が始まりました。WordPress、Apache HTTP Server、Pythonパッケージ、Ruby gemsの検出が加わっています。ただし自動では切り替わりません。コンソールのSettings＞Scan SettingsでStart Upgradeを選びEnhanced EC2 Scanningへオプトインするまでは従来のSSMプラグインのままで、追加された検出対象も拾えないままです。WordPressを載せたEC2を運用しているなら、まずこの切り替え状態を確認してください。

スキャン対象から外したいインスタンスにはInspectorEc2Exclusionタグを付けます。除外したインスタンスは課金対象になりません。ただしタグを付けてもSSMプラグインの呼び出し自体は続くため、呼び出しごと止めるにはインスタンスメタデータでのタグ参照を許可する設定が別に必要です。Inspectorの機能と料金をより詳しく追う場合はAmazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断を参照してください。

GuardDuty・Security Hub CSPMとの役割分担

AWSのセキュリティサービスは名前が似ているため混同されがちですが、検出するものが重なっていません。

Inspectorは「穴が空いているか」、GuardDutyは「すでに誰か入ってきていないか」を見ます。前者が予防、後者が検知です。脆弱性診断という目的だけで言えば入れるべきはInspectorが先で、GuardDutyは診断ではなく監視の予算枠で考えるほうが筋が通ります。それぞれの詳細はAmazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説とAWS Security Hubとは？CSPMとの違い・料金と導入判断を実装者目線で解説にまとめています。

なお、Inspectorの検出結果はSecurity Hub CSPMとAmazon EventBridgeへ自動連携されます。SBOMとして棚卸ししたい場合はAmazon InspectorのSBOMエクスポート手順｜CycloneDX・SPDX出力とCI/CD連携・料金の手順が使えます。

EC2 50台構成の月額試算と単価内訳

Inspectorは従量課金で、最低料金も前払いもありません。米国東部（バージニア北部）リージョンの単価は次のとおりです。

EC2を50台（エージェントベース）、ECRへ月200イメージをプッシュ、Lambda 30関数を標準スキャンする構成なら、62.90ドル＋18.00ドル＋9.00ドルで月額89.90ドル。1ドル150円換算で約1万3千円です。ただしこれは下限の見積りにあたります。ECRのイメージはプッシュ後も監視が続き、新規CVEが公開されるたびに1イメージ0.01ドルの再スキャンが加算されます。ハイブリッドモードで動いている場合は、SSM管理外のインスタンスが1.75ドル側で課金されます。導入前の評価には15日間の無料トライアルが用意されています。単価はリージョンで異なるため、東京リージョンで見積もる際は必ず公式の料金表を再確認してください。

Inspector Classic終了で無効になった解説記事の見分け方

AWSは公式ドキュメントで「we decided to end support for Amazon Inspector Classic, effective May 20, 2026」と告知しており、2026年5月20日をもってAmazon Inspector Classicのサポートは終了しました。新規顧客の受け付けは2025年5月20日に停止済みで、終了日以降はClassicのコンソールもリソースも利用できません。

問題は、日本語で書かれたAWS脆弱性診断の解説にClassic前提のものが多く残っている点です。次の用語が出てきたら、その記事は現行のInspectorを説明していません。

• ネットワーク評価（Network Assessment）／ホスト評価（Host Assessment）という2分類
• 評価テンプレート（Assessment Template）と評価ターゲット（Assessment Target）の作成手順
• ルールパッケージ（Rules Package）を選んでスキャン内容を決める操作
• スタンドアロンのInspectorエージェントを個別インストールする手順
• スキャン頻度を手動でスケジュールする設定

いずれも現行のInspectorには存在しません。現行版は対象を自動検出して継続スキャンする設計に変わり、エージェントもSSMエージェントに統合されています。2026年8月時点で公開されている国内の解説記事にも「Amazon Inspectorのルールパッケージと評価テンプレート」という見出しが残っています。手順どおりに操作しようとしてもコンソールに該当画面がないため、記事の公開日ではなく用語で判断してください。判断基準としては、EC2・ECR・Lambdaの3つが自動で有効化されると書かれていれば現行版の説明です。

外部の脆弱性診断サービスに出すべき場面・出さなくてよい場面

手動診断が必要になる3つの条件

「AWSを使っているので専門業者に全部見てもらいたい」という出し方は、費用対効果が悪くなります。前述の3層のうち、外注が本当に効くのは3層目の動的なWebアプリケーション診断だからです。

外注すべき条件ははっきりしています。認証・認可ロジックを自社実装している、決済や個人情報を扱う画面がある、取引先やISMS審査から第三者診断の報告書を求められている。このいずれかに当てはまるなら手動診断を含む外部診断が必要です。認可制御の欠陥やビジネスロジックの穴は、パッケージのバージョンを照合する自動スキャンでは原理的に見つかりません。Code Securityの静的解析でも、権限判定が実行時のデータに依存する箇所は追い切れません。

発注前にネイティブツールで潰しておく範囲

外注しなくてよい場面もあります。マネージドサービス中心で自社実装のアプリがほとんどない構成、社内向けの管理ツールしか動いていない環境、そしてまだInspectorもSecurity Hub CSPMも有効化していない段階。特に最後のケースで数十万円規模の診断を先に発注するのは順序が逆です。月90ドル程度で潰せるCVEを残したまま手動診断を受けても、報告書の大半が「パッケージを更新してください」で埋まります。機械的に潰せる範囲を先に潰し、残った領域を外注する。この順序のほうが、同じ予算で深く見てもらえます。

診断を一度きりで終わらせない運用サイクル

計画からトリアージまでの5ステップ

脆弱性は日々公開されるため、診断を年1回のイベントにすると次の実施までの11か月が無防備になります。AWS環境では、この継続部分の大半をツールに寄せられます。全体の流れは次のとおりです。

1. 診断対象の棚卸し（アカウント・リージョン・EC2・ECRリポジトリ・Lambda関数・コードリポジトリ）
2. 診断行為が許可サービスの範囲に収まるかの確認と、必要ならSimulated Eventsフォームの提出
3. Inspectorとクラウド設定監査の有効化、スキャンモードと除外タグの決定
4. 検出結果のトリアージ（重大度・到達可能性・影響範囲での優先順位付け）
5. 修正の適用と、自動クローズを使った再確認

手動で回すのはステップ1・2・4だけで、3と5はツールが担います。年次の実施計画に落とすなら、ステップ1と2を期初にまとめて済ませておくと運用が軽くなります。

検出結果の処理ルールで先に決める4項目

Inspectorは新しいCVEがデータベースに追加された時点で影響を受けるリソースを再スキャンし、新規EC2の起動やECRへのイメージプッシュ、パッケージのインストールでも再スキャンを走らせます。修正が適用されると検出結果は自動的にクローズされます。運用側で決めるべきは、スキャンの実行タイミングではなく検出結果の処理ルールです。

具体的には、重大度ごとの対応期限（Criticalは何営業日以内か）、抑制ルールを適用してよい条件、EventBridge経由でチケットを起票する対象の閾値、そしてスキャン対象から外したリソースの棚卸し頻度。この4点を決めておかないと、検出結果が数千件たまってから誰も見なくなります。

プライベートサブネットのEC2をEnhanced EC2 Scanningの対象にする場合は、com.amazonaws.リージョン名.ec2messagesの形式で、ec2messages・inspector2-telemetry・s3・ssm・ssmmessagesの5つのVPCエンドポイントが必要です。inspector2-telemetryは一部リージョンで未対応と公式に注記があるため、対象リージョンで先に確認してください。

Azure上にもサーバーがある構成なら、Inspectorのコネクタを作成してAzure仮想マシン、Azure Function Apps、Azure Container Registryのイメージを同じコンソールで継続スキャンできます。Azure分の無料トライアルはAWS分とは別枠で30日間用意されているため、マルチクラウドの脆弱性管理を1か所へ寄せる価値があるかどうかを試してから判断できます。

よくある質問

AWSの脆弱性診断に事前申請は必要ですか？

AWSが公開している侵入テストポリシーの許可サービス一覧に含まれるリソースへの診断であれば、事前申請は不要です。一覧にはEC2・WAF・NATゲートウェイ・ELB・RDS・CloudFront・Aurora・API Gateway・AppSync・Lambda・Lightsail・Elastic Beanstalk・ECS・Fargate・OpenSearch Service・FSx・Transit Gateway・Bedrock AgentCoreが挙げられています。一方でSimulated Eventsフォームの提出が必要な行為が4類型あります。レッドチーム／ブルーチーム／パープルチーム演習、iPerf試験、模擬フィッシング、マルウェアテストです。いずれも開始日の2週間前までに提出します。DoS・DDoSやリクエストフラッディングは申請の有無を問わず禁止です。

Amazon Inspectorを入れれば脆弱性診断は足りますか？

足りません。InspectorはOS・言語パッケージの既知CVE、ネットワーク到達性、そしてCode Securityによるソースコードとサードパーティ依存関係、IaCの静的解析までを守備範囲としています。ただしS3の公開設定や過剰なIAM権限のような設定不備はCVEを持たないため対象外で、ここはSecurity Hub CSPMの領域です。稼働中のWebアプリケーションにリクエストを投げる動的診断も含まれません。Inspectorは「継続的に潰せる範囲を機械的に潰す」道具と位置づけ、残る領域を別の手段で埋める設計にしてください。

Amazon Inspector Classicはまだ使えますか？

使えません。AWSは2026年5月20日付でAmazon Inspector Classicのサポートを終了しており、終了日以降はClassicのコンソールとリソースにアクセスできなくなりました。新規顧客の受け付けは2025年5月20日に停止済みです。現行のAmazon Inspectorは再設計された別サービスで、評価テンプレートやルールパッケージを作る操作はありません。Classicの用語で書かれた解説記事は、手順として再現できない点に注意してください。

Amazon InspectorとGuardDutyはどちらを先に入れるべきですか？

脆弱性診断が目的ならInspectorが先です。Inspectorは既知CVEとネットワーク到達性という「まだ悪用されていない穴」を検出し、GuardDutyはログから「すでに起きている不審な挙動」を検出します。役割が予防と検知に分かれているため、どちらかで代替できる関係にはありません。予算が限られる場合は、機械的に修正できる問題を先に潰せるInspectorから着手し、GuardDutyは監視体制の整備と合わせて導入するのが現実的です。

AWSの脆弱性診断サービスを外注する費用の目安は？

外部の診断サービスは診断対象と手法で価格が大きく変わるため、一律の目安を示すのは適切ではありません。判断の順序として、Inspectorで潰せる既知CVEを先に処理してから見積もりを取ると、外注範囲がWebアプリケーションの動的診断や認可制御の検証に絞られ、費用も内容も比較しやすくなります。診断種別ごとの費用構造と外注時の判断基準は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説にまとめています。

関連記事

• Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説
• ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理
• AWS Security Hubとは？CSPMとの違い・料金と導入判断を実装者目線で解説
• Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説