Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断

Amazon Inspector Classic のサポートは2026年5月20日に終了しました。検索で見つかる解説の多くは「ネットワーク評価」「ホスト評価」というClassic時代の用語のままで、現行コンソールの画面とも料金の数え方とも一致しません。現行のAmazon Inspectorは、EC2インスタンス・ECRのコンテナイメージ・Lambda関数・コードリポジトリを自動で見つけて継続的にスキャンする脆弱性管理サービスです。この記事では、対象リソースごとに異なるスキャン方式と前提条件、エージェント方式とエージェントレス方式で検出結果が食い違う仕様、リソース種別ごとに積み上がる料金、GuardDutyやSecurity Hubとの責務分担、そして採用条件と見送り条件を実装者目線で整理します。

まとめ：Amazon Inspector導入の判断基準と有効化前に決める3つの前提

Amazon Inspectorは、自分で脅威を検知するサービスではありません。稼働中のワークロードに含まれるソフトウェアの棚卸しを続け、公開済みのCVEと突き合わせて「いま直すべき脆弱性」を出し続ける仕組みです。導入判断の起点は、守りたい資産がAWSの中に集まっているかどうかにあります。

有効化の前に決めておくことは3つです。第1に、スキャン対象の範囲。EC2だけなのか、ECRイメージとLambdaまで含めるのかで、料金の桁も運用の手間も変わります。第2に、EC2のスキャンモード。SSM管理が徹底されていない環境ではエージェントレスが穴を埋めますが、単価は上がり、言語パッケージの検出結果もエージェント方式と一致しません。第3に、検出結果を処理する担当と頻度。

見送る判断も先に示します。検出結果を週次以上でトリアージする体制が無い環境では、有効化しても請求額と未対応findingが増えるだけです。体制が先、有効化が後。この順序を崩すと運用は続きません。

Classic終了後のAmazon Inspectorが担う検出範囲と3系統の検出結果

まず、いま自分が読んでいる情報がどちらの世代のものかを見分けるところから始めます。

2026年5月20日のInspector Classic終了後に使えない旧手順の読み替え

Inspector Classic は、評価ターゲットと評価テンプレートを作り、ルールパッケージを選んで所定時間の評価を走らせる設計でした。エージェントを入れ、実行時間を指定し、終わったら結果を見る。この操作モデルは現行Inspectorには存在しません。2026年5月20日をもってClassicのサポートは終了し、コンソールとリソースへのアクセスもできなくなりました。

現行Inspectorに評価テンプレートはなく、有効化した時点でリソースの検出と継続スキャンが始まります。国内記事に残る「ネットワーク評価」「ホスト評価」という区分もClassic固有の表現です。当社のAmazon Inspectorで行う脆弱性診断の手順とそのメリットもClassic時代の操作手順を扱っているため、現行の設定作業はこの記事の内容で読み替えてください。

パッケージ脆弱性・ネットワーク到達性・コード脆弱性という3系統の検出内容

現行Inspectorが出す検出結果は3系統に分かれます。1つ目はパッケージ脆弱性で、OSパッケージと言語パッケージの両方が対象です。2つ目はネットワーク到達性で、意図せずインターネットから届いてしまう経路を12時間ごとに調べます。3つ目はコード脆弱性で、Lambdaのコードスキャンと Code Security が担当します。

Code Security は Amazon Q Developer のスキャンエンジンを使い、自分たちで書いた一次コード、サードパーティ依存、Infrastructure as Code の3つを見ます。連携先として GitHub、GitHub Enterprise、GitLab セルフマネージド、Bitbucket が公式ドキュメントに用意済みです。修正が反映されるとInspectorはそれを検知し、該当の検出結果を自動でクローズします。

NVDのCVSSを自環境で補正するInspectorスコアと優先度づけへの使い方

Inspectorは検出結果にInspectorスコアを付けます。これはNVDが公開するCVSSベーススコアをそのまま転記した値ではなく、自環境の条件で補正した値です。インターネットからの到達経路が無いEC2インスタンス上の脆弱性であれば、ネットワーク経由で悪用可能な脆弱性でもスコアは下がります。

スコアの意味を取り違えると優先度づけが歪みます。CVSS基本値の考え方そのものはCVSSの計算方法とv4.0の変更点で整理していますが、Inspectorスコアは「この環境でどれだけ危ないか」を示す別の指標です。CVSS 9.8だがInspectorスコアが下がっている検出結果より、公開サブネットのWebサーバで見つかったスコア7点台の検出結果を先に潰す。

EC2・ECR・Lambda・コードリポジトリで分かれるスキャン方式と前提条件

リソース種別ごとに、スキャンの契機も前提条件も別物です。ここを揃えて理解しないと、有効化したのにスキャンされないリソースが残ります。

EC2のエージェント方式・エージェントレス方式とハイブリッドの既定挙動

EC2のパッケージ脆弱性スキャンには2方式あります。エージェントベースはSSM Agentでインベントリを収集する方式で、対象はSSM管理下のインスタンスだけです。SSMインベントリの評価は既定で30分ごと、LinuxとMacでは新しいCVEがデータベースへ追加された時点でも再スキャンが走ります。

エージェントレスはEBSスナップショットからインベントリを取る方式です。Inspectorがスナップショットを作成し、EBS direct APIで読み取り、評価後にスナップショットを削除します。適格条件は明確です。

• インスタンスの状態が Unmanaged EC2 instance、Stale inventory、No inventory のいずれか
• EBSバックトで、ファイルシステムが ext3・ext4・xfs のいずれか
• アタッチされたボリュームが8本未満、かつ合計1,200GB以下
• 除外タグ InspectorEc2Exclusion が付いていないこと

ハイブリッドスキャンモードでは、エージェントレスの実行は24時間ごと、新たに適格になったインスタンスの検出は1時間ごとです。なお公式ドキュメントには「EC2スキャン有効化でハイブリッドに自動登録される」旨と「新規アカウントの既定はエージェントベース」旨が併記されています。設定画面のEC2スキャン設定で現在のモードを実際に確認してから設計してください。

言語パッケージの走査範囲が方式で変わるディープインスペクションの落とし穴

同じインスタンスをスキャンしても、方式によって検出結果が変わります。原因は走査するパスの範囲です。Linuxの言語パッケージについて、エージェントレスは利用可能な全パスを走査します。一方エージェントベースはディープインスペクションの既定パスと、追加で指定したパスしか見ません。

非標準の場所へアプリケーションを配置している環境では、エージェントを入れた途端に検出件数が減るという逆転が起こります。減ったのは脆弱性ではなく、見えている範囲です。SSM管理へ移行する際は、追加パスの指定を先に済ませてください。プライベートサブネットで Enhanced EC2 Scanning を使う場合は、ec2messages・inspector2-telemetry・s3・ssm・ssmmessages のVPCエンドポイントも必要です。inspector2-telemetry は未対応のリージョンがあります。

ECRの30日・90日ルールとLambda標準スキャン・コードスキャンの層構造

ECRスキャンを有効化すると、プライベートレジストリのリポジトリが基本スキャンから拡張スキャンへ切り替わります。対象は imageStatus が ACTIVE のイメージのうち、過去30日以内にプッシュまたはアクティブ化されたもの、あるいは過去90日以内にプルされたものです。既定の監視期間は90日。包含ルールでプッシュ時のみ、あるいは対象リポジトリのみに絞れます。レジストリ側の前提はAWS ECRの料金とDockerイメージのpush手順で確認できます。

Lambdaは2層です。標準スキャンが関数とレイヤーの依存パッケージのCVEを検出し、デプロイ・更新・新規CVE公開の各タイミングで再スキャンします。コードスキャンは任意で足す層で、有効化すると標準スキャンも自動的に有効になります。

コードリポジトリのスキャンだけは、他と違ってスキャン設定で頻度とタイミングを自分で決める設計です。

リソース種別ごとに単価が変わる料金構造と試算から漏れやすい課金項目

Inspectorの請求は1本の単価では決まりません。対象ごとに課金単位が違うため、有効化する範囲がそのまま金額の形になります。

EC2・ECR・Lambda・CISで分かれる課金単位と15日間の無料トライアル

米国東部（バージニア北部）表記・2026年7月時点の公表単価は次のとおりです。リージョンと利用量で単価は変わるため、試算前に料金ページで自分のリージョンを確認してください。

前払いも最低料金もありません。Inspectorを使ったことがないアカウントには15日間の無料トライアルが付き、Azureリソースのスキャンには独立した30日間のトライアルが用意されています。Azure VMは1.258USD／VM月、Azure Function Appsは0.30USD／アプリ月と、AWS側と同水準の単価です。

エージェントレス差額・再スキャン頻度・除外タグという試算のずれ要因

見積もりが外れる要因は3つあります。最大のものはエージェントレスとの差額です。1台あたり月0.49USDの差は小さく見えますが、SSM管理が行き届いていない500台規模の環境では月245USDの上振れになります。SSM管理率が低いほど請求は膨らむ、という関係です。

2つ目はECRの再スキャンです。初回0.09USDに対し再スキャンは0.01USDと安いものの、CI/CDから1日に何度もイメージをプッシュする構成では回数がそのまま積み上がります。3つ目は除外タグの扱い。InspectorEc2Exclusion を付けたインスタンスは課金対象外になるため、検証用や短命なインスタンスへ先にタグ設計を入れておくと請求が締まります。タグキーは大文字小文字を区別しません。

GuardDuty・Security Hub・SASTツールとの責務分担と重複の整理

AWSのセキュリティサービスは名前が似ていて範囲が重なって見えます。Inspectorの守備範囲を線で区切っておきます。

脅威検出のGuardDutyと脆弱性検出のInspectorで分かれる責務の境界

Amazon GuardDutyが担う脅威検出は、CloudTrailやVPCフローログなどの挙動から「いま攻撃されている兆候」を拾う仕組みです。Inspectorが見るのは挙動ではなく、インストールされているソフトウェアの構成情報。まだ何も起きていない段階で「攻撃されうる弱点」を出します。

両者は代替関係ではありません。GuardDutyだけでは古いOpenSSLが載ったままのAMIを見つけられず、Inspectorだけでは認証情報を盗まれた後の不審なAPI呼び出しに気づけません。片方に寄せるなら、外部公開資産が多い環境ではGuardDutyを、内製アプリのリリース頻度が高い環境ではInspectorを先に有効化する順序になります。

Security Hub CSPMへの集約とEventBridge経由の通知設計

Inspectorの検出結果はEventBridgeへfindingイベントとして発行されます。AWS Security Hub CSPMを有効化している場合は同サービスへも自動で発行され、GuardDutyやMacieの結果と同じ画面へ並ぶ構成です。複数アカウント構成なら、Inspector単体のコンソールを見て回るより集約層側で優先度を付けるほうが実務に合います。

単一アカウント・単一リージョンで、対象が数十台程度にとどまるなら、Security Hubを重ねる必要はありません。Inspectorのダッシュボードと抑制ルール、CSVまたはJSONのレポート出力だけで足ります。

SAST・DASTツールとCode Securityの重複範囲と使い分けの基準

Code Security が見る一次コードとIaCは、SASTツールが担当する静的解析の範囲と重なります。既にSASTを導入済みなら、Code Securityを追加する理由は「AWS内の検出結果と同じ画面へ集約したい」場合だけです。検出精度そのものを理由に二重導入すると、同じ指摘が2系統から届いてトリアージ工数だけが増えます。

一方、稼働中アプリへ外部から擬似攻撃をかけるDASTの動的診断とは範囲が重なりません。Inspectorはデプロイ済みの構成物を静的に見るサービスであり、実行時の入力処理の欠陥は検出対象外です。

Amazon Inspectorを採用すべき環境と有効化が過剰になる環境の線引き

導入可否は組織の規模ではなく、資産の置き場所と運用体制の2点で決まります。

採用条件となる資産配置とトリアージ体制を見極める2つの実務要件

採用すべきなのは、次の2条件を両方満たす環境です。第1に、脆弱性を管理したい資産の大半がEC2・ECR・Lambdaに載っていること。オンプレミスのサーバや他社クラウドが主戦場なら、Inspectorは全体像の一部しか映しません。第2に、出た検出結果を週次以上の頻度で見て、対応要否を判断する担当が決まっていること。

この2つが揃うなら、有効化を先送りする理由はほぼありません。EC2スキャンだけなら1台あたり月1.258USDから始められ、評価テンプレートの設計もスケジュール調整も不要です。

見送るべき短命インスタンス中心の構成とマルチクラウド主体の環境

採用しないほうがよい環境も明確です。1つ目は、数時間で使い捨てるスポットインスタンスやCIランナーが大半を占める構成。エージェントレスは24時間ごと、新規適格インスタンスの検出は1時間ごとのため、消えた頃にようやくスキャンされる状況になります。この場合はイメージ側、つまりECRの拡張スキャンとビルド時のスキャンへ投資すべきで、EC2スキャンは切って構いません。

2つ目は、AWSが全体の一部でしかないマルチクラウド環境。Azure対応は追加されましたが、Google Cloudやオンプレミスは対象外です。3つ目は、検出結果を誰も見ない環境。この条件では有効化するほど未対応findingが積み上がり、監査時にかえって不利な材料になります。

有効化後に請求だけが増える失敗パターンと検出結果のトリアージ設計

有効化そのものは数クリックで終わります。運用が破綻するのはその後です。

リージョン単位の有効化漏れと委任管理者設定で生じる可視化の穴

最も多い抜けはリージョンです。Inspectorはリージョンごとに有効化する設計のため、東京リージョンだけ有効にした環境では、検証用に立てたバージニア北部のインスタンスが丸ごと死角になります。マルチアカウント構成ではAWS Organizationsの委任管理者を指定し、組織全体へ一括で有効化する設定を先に入れてください。新規メンバーアカウントの自動有効化も同時に設定します。

SSMリソースの誤削除にも注意が必要です。InspectorInventoryCollection-do-not-delete などの名前を持つアソシエーションは、整理対象と誤解されて削除されがちです。削除されても次回スキャン間隔で再作成が試みられますが、その間の収集は止まります。

抑制ルール未整備で高深刻度findingが滞留する運用の立て直し

有効化直後は数百件から数千件の検出結果が一度に出ます。ここで全件対応を目指すと必ず止まります。先に抑制ルールを組み、対応しないと決めたカテゴリ、たとえば開発用アカウントの検証インスタンスや、修正版が提供されていないパッケージを画面から外してください。残った件数が現実的な数になって初めて、週次のトリアージが回り始めます。

そのうえで、Inspectorスコアの高い検出結果から順に、パッチ適用かイメージ再ビルドかを判断します。社内に脆弱性対応の判断基準が無い場合は、対象範囲の切り出しから脆弱性診断・セキュリティ診断で外部と組み、初回の棚卸しと運用ルールづくりを並行させる進め方が現実的です。仕組みだけ入れて基準が無い状態が、最も費用対効果を落とします。

Amazon Inspectorのスキャン仕様と料金に関するよくある質問

導入検討時に問い合わせの多い5点をまとめます。

Amazon Inspectorは無料で使えますか？

Inspectorを使ったことがないアカウントには15日間の無料トライアルが付きます。Azureリソースのスキャンは独立した30日間のトライアルです。トライアル後は従量課金で、前払いや最低料金はありません。費用を抑えたい場合は、除外タグ InspectorEc2Exclusion を検証用インスタンスへ付けると課金対象から外れます。

SSMエージェントが入っていないインスタンスもスキャンできますか？

ハイブリッドスキャンモードであればエージェントレス方式でスキャンされます。条件は、インスタンスの状態が Unmanaged EC2 instance・Stale inventory・No inventory のいずれかで、EBSバックト、ファイルシステムが ext3・ext4・xfs、アタッチされたボリュームが8本未満かつ合計1,200GB以下であることです。実行は24時間ごとで、エージェントベースより単価は高くなります。条件を外れるインスタンスはどちらの方式でもスキャンされません。

Inspector Classicから移行する必要はありますか？

Classicのサポートは2026年5月20日に終了しており、コンソールとリソースへのアクセスはできません。移行というより、現行Inspectorを新規に有効化する作業になります。評価ターゲットや評価テンプレートに相当する設定は現行に存在せず、有効化すればリソースの検出と継続スキャンが自動で始まります。Classic向けに組んでいた実行スケジュールの仕組みは不要です。

ECRの基本スキャンと拡張スキャンは何が違いますか？

基本スキャンはECR側の機能で、OSパッケージを対象にプッシュ時などに実行される仕組みです。拡張スキャンはInspectorが担当し、OSパッケージに加えて言語パッケージも検出し、新しいCVEが公開されると既存イメージを再スキャンします。InspectorのECRスキャンを有効化すると、プライベートレジストリのリポジトリが拡張スキャンへ変換されます。対象はACTIVEなイメージで、既定の監視期間は90日です。

検出結果はどこへ集約して通知すればよいですか？

検出結果はEventBridgeへfindingイベントとして発行されるため、SNSやLambdaへ流して既存の通知経路に載せられます。AWS Security Hub CSPMを有効化していれば自動集約の対象です。単一アカウントで対象が数十台規模なら、Inspectorのダッシュボードと抑制ルール、CSVまたはJSONのレポート出力だけでも運用できます。SBOMをS3へ出力して資産管理に使う方法もあります。

関連記事

• Amazon Inspector SBOM Exportの主要な機能と特長：検出結果をSBOMとして書き出す機能の詳細。
• AWS ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】：拡張スキャンの対象となるレジストリ側の前提。
• CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説：Inspectorスコアの元になる指標の読み方。
• CI/CDパイプラインにおけるDocker脆弱性スキャン：ビルド段階でイメージを検査する場合の設計。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：ツールと外部診断の使い分けを検討する場合。