セキュリティサービス部 佐竹です。
Amazon Inspector (インスペクター) による Amazon EC2 インスタンスのスキャンによって Amazon EFS の費用が高騰するケースについて記載します。
- はじめに
- Amazon EFS への請求額が高額になる条件
- コスト増が発生するメカニズム
- EFS でコスト増を発生させないための対処方法
- inspectorssmplugin と仕様についての詳細
- まとめ
はじめに
以前、Amazon S3 バケットを EC2 インスタンスにマウントしている環境下において、Amazon Inspector のスキャンにより S3 の API リクエスト料金が高額になるケースについてのブログ記事を記載しました。
今回は S3 ではなく、Amazon EFS (Elastic File System) を利用している環境において、同様に Amazon Inspector のスキャンによって利用料が急増する可能性が確認されましたため、本ブログ記事にて、注意喚起と備忘を目的としてご紹介させていただきます*1。
特に、Amazon EFS の「ライフサイクル管理」機能を利用してコスト最適化を行っている環境下で、その影響が顕著です。
Amazon EFS への請求額が高額になる条件
まずは最初に Amazon Inspector によって Amazon EFS の利用料が高額になる条件についてまとめておきます。以下の条件が全て揃った場合に発生します。
- EC2 インスタンスに Systems Manager Agent がインストールされている
- Systems Manager が正常に動作する状態となっている
- Amazon Inspector が有効化されている
- Amazon Inspector のオプションである EC2 インスタンスのスキャンが有効化されている
- Amazon EFS のファイルシステムを EC2 インスタンス上にマウントしている
- Amazon EFS のライフサイクルポリシーを設定し、ファイルを低頻度アクセス (IA) ストレージクラスに移行させている
前半の条件は S3 の事例と同様ですが、特に重要なのは最後の「ライフサイクルポリシー」の設定有無です。
また以下の内容は前回の S3 版のブログと重複する点も多いため、重複部分は簡素な説明に留めます。
EC2 インスタンスに Systems Manager Agent がインストールされている
Systems Manager (SSM) Agent はデフォルトで多くの AMI にインストールされています。Amazon Linux や Windows OS がその代表例です。
SSM Agent がインストールされている環境では、Amazon Inspector は自動的にこのエージェントを利用した「エージェントベーススキャン」を実行しようとします。
Systems Manager が正常に動作する状態となっている
また、SSM Agent がインストールされているだけでなく、適切な IAM ロール（インスタンスプロファイル）が付与され、SSM のエンドポイントへの通信が可能であるなど、Systems Manager が正常に動作している（マネージドノードとして認識されている）必要があります。
適切な IAM ロール（インスタンスプロファイル）が付与されていない場合でも、上記の SSM デフォルトホスト管理設定で SSM が有効化されている場合もあるでしょう。
重要なのは、Fleet Manager において「マネージドノード」として認識されているかどうかです。
Amazon Inspector が有効化されている
Amazon Inspector を有効化すると、SSM エージェントを介して EC2 インスタンス内のソフトウェアインベントリの収集や脆弱性スキャンが開始されます。
Amazon Inspector のオプションである EC2 インスタンスのスキャンが有効化されている
Amazon Inspector の設定で「Amazon EC2 scanning」が有効化されている場合、対象のインスタンスに対して定期的なスキャンが実行されます。
上画像のように、Amazon EC2 scanning の設定が「Activated」されている場合、EC2 インスタンスのスキャンが有効化されていることがわかります。
また、このスキャン頻度はデフォルトで「6時間毎」となっています。
スキャン頻度や、その頻度の変更については上記 AWS 公式ドキュメントをご参照ください。
Amazon EFS のファイルシステムを EC2 インスタンス上にマウントしている
さて、ここからが本題です。S3 と同様、EFS が EC2 インスタンスにマウントされているかどうかが重要です。
EC2 インスタンスが Amazon EFS をマウントしている場合、SSM エージェント経由で実行される Inspector のスキャンプロセスは、ローカルディスクだけでなく、マウントされているネットワークファイルシステム（EFS）配下のファイルもスキャン対象として認識し、アクセスを行います。
この点については、後程その仕様の詳細を掘り下げます。
Amazon EFS のライフサイクルポリシーを設定している
Amazon EFS には、一定期間アクセスのないファイルを安価な「低頻度アクセス (IA)」ストレージクラスへ自動的に移行させるライフサイクル管理機能があります。
EFS Standard クラスと比較して IA クラスの保存料金は非常に安価であるため、コスト最適化の観点からも本設定が有効化されているシーンは多いと思われます。
コスト増が発生するメカニズム
これらの条件が揃った場合、以下のような挙動によりコスト増が発生します。
1. エージェントベーススキャンの仕様
SSM Agent が稼働している EC2 インスタンスでは、Inspector は強制的に「エージェントベース」のスキャンを実行します。
エージェントレススキャン（EBS スナップショットベースのスキャン）では EFS はスキャン対象外となりますが、エージェントベースの場合は OS 上で見えているファイルシステム全体をスキャンするため、EFS 配下の全ファイルにアクセスが発生します。
2. IA (低頻度アクセス) の意図しないクラス移動
Inspector が EFS 内の全ファイルをスキャン（読み取り）すると、EFS 側はそれを「ファイルへのアクセス」とみなします。これにより、以下の2つのコストが発生します。
データアクセス料金の発生（一時的コスト）
IA ストレージにあるファイルを読み取る際には、「低頻度アクセス - 読み取り」料金に加え、Standard クラスへの「低頻度アクセス - 階層化（Standard への移行）」料金が初回時に発生します。Inspector が全ファイルをスキャンするため、これらの料金がファイル総量分だけ発生します。ストレージ料金の増加（継続的コスト）
これが最も大きなインパクトとなります。一度アクセスされたファイルは、安価な IA クラスから高価な Standard クラスへと自動的に移動されてしまいます。フルスキャンにより、全てのファイル群がStandard クラスへと移動します。
Standard クラスの料金は IA クラスの数倍〜十数倍高額です。東京リージョン(プロビジョンドスループット)では、USD 0.0272→USD 0.36と、約13倍になってしまいます。
そして、Inspector のスキャンはデフォルトで6時間毎に行われるため、ライフサイクルポリシーで「30日間アクセスがなければ IA へ移行」と設定していても、6時間毎にアクセスが発生し続ける結果、ファイルは Standard クラスに留まり続けます。
結果として、本来安価に運用できていた EFS のストレージコストが、Inspector を有効化した直後から Standard クラスの料金単価で計算されることになり、請求額が急増してしまいます。
また一度 IA から Standard クラスへ移動してしまうと、再度 IA に移動されなおすには「デフォルトでは、スタンダードストレージクラスまたは 30 日間アクセスされないファイルは IA に移行されます（※この日数は設定変更可能）」の仕様に沿う必要があり、再度、設定した日数の待機期間が必要となってしまいます。
実際の設定は、EFS の「Lifecycle management」からご確認ください。
Metered size 等でストレージクラスを事前に確認する
File system のストレージが Standard にあるのか、IA にあるのか等は、マネジメントコンソール(Metered size タブ)から確認頂けます。
また、Cost Explorer で費用明細を確認するのも良いでしょう。
Dimension を「Usage type」とすることで、IATimedStorage-ByteHrs の費用がどの程度占めるのか、組織やアカウント単位で分析できます。
前提条件が揃った状態で Inspector を有効化した場合、この利用料が約13倍程度に増えてしまいますが、この月額料金がコストとして許容できるかが判断のポイントとして重要です。
EFS でコスト増を発生させないための対処方法
対応として、実現不可能なこと
まず残念ながら、現時点の Amazon Inspector の仕様では「特定のディレクトリ（例：/mnt/efs）だけをスキャンから除外する」という設定はできません*2。
また、SSM Agent がインストールされている以上、「このインスタンスだけエージェントレススキャン（EBS スナップショットスキャン=ハイブリッド）にする」という強制設定もできません。SSM Agent がインストールされている限り、エージェントベースのスキャンが強制されます。
もし SSM Agent をインストールしておらず、かつハイブリッドモードで動かす場合、Inspector のコストは少し上がりますが、スナップショット経由のスキャンであれば、EFS がマウントされない状態になるため、EFS へのスキャンを回避できます。ですが、そのために SSM Agent のアンインストールを行うことは、運用保守の観点からも許容が厳しいでしょう。
そのため、コスト増を回避するための有効な手段は Amazon Inspector の EC2 スキャン自体が対象のインスタンス（EFS がマウントされているインスタンス）で行われないようにすることのみとなります。
Inspector スキャン除外の設定方法
① スキャン除外のためのタグキーを付与する
EFS をマウントしている EC2 インスタンス自体を Inspector のスキャン対象から除外します。
対象の EC2 インスタンスにタグキー InspectorEc2Exclusion を付与してください。値（バリュー）は不要です。バリューはオプションのため、何らかの値を入力しても問題ありません。
② インスタンスメタデータのタグへのアクセスを許可する
タグを付与しただけでは EC2 内部のスキャンは停止しません。完全に停止するためには、インスタンスメタデータのタグへのアクセスを許可する必要があります。
デフォルト「Disabled」となっているため、設定を意図的に行っていない限りは「Disabled」のままの環境が多いと思われます。
マネジメントコンソールからインスタンスごとに設定変更が可能です。「Allow tags in instance metadata」を「Enabled」に変更してください。
AWS CLI での設定例は以下の通りです。
aws ec2 modify-instance-metadata-options --instance-id i-1234567890abcdef0 --instance-metadata-tags enabled
なお、先のブログでも記述しているのですが、インスタンスメタデータのタグへのアクセスを許可するには、そのインスタンスに付与されている全てのタグキーで、半角スペースが使用できません。「Patch Group」タグなど、半角スペースを持つタグキーが付与されている場合は、合わせてその修正が必要な場合があります。
inspectorssmplugin と仕様についての詳細
さて、最後に inspectorssmplugin について少し触れます。
まず、以下が AWS 公式ドキュメント「The Amazon Inspector SSM plugin for Linux and Windows」です。
そして合わせて「Amazon Inspector スキャンからのインスタンスの除外」について、その記述のあるドキュメントをみていきましょう。
Amazon Inspector スキャンから除外するようにインスタンスにタグ付けすると、Amazon Inspector はインスタンスを除外済みとしてマークし、その検出結果を作成しません。ただし、Amazon Inspector SSM プラグインは引き続き呼び出されます。プラグインが呼び出されないようにするには、インスタンスメタデータのタグへのアクセスを許可する必要があります。
この記述を念入りに見ていくことで、仕様とその裏側が理解できます。
先の除外設定が「①スキャン除外のためのタグキーを付与する」と「②インスタンスメタデータのタグへのアクセスを許可する」という、2つの作業が何故必要なのか？これを紐解くための記述がこれです*3。
まず、「①スキャン除外のためのタグキーを付与する」ことによって実現されるのは、あくまで「Inspector が検出結果を作成しない」だけです。最後にレポートされる Inspector の結果表示からそれらが除外されるだけなのです。
このため、SSM Agent（Inspector の Agent でもある）は継続して EC2 インスタンスの中の脆弱性に関する情報自体を集め続けてしまいます。それが「Amazon Inspector SSM プラグインは引き続き呼び出されます」という記述で説明されています。
「Amazon Inspector SSM プラグイン」は先の inspectorssmplugin そのものです。このプラグインは、OS 上のパッケージや脆弱性を検出するために「ディープインスペクションスキャン」を実行します。具体的には、ファイルシステム上のディレクトリを走査し、インストールされているパッケージ情報を収集しようとします。
この走査プロセスにおいて、EFS がマウントされているディレクトリ（例: /mnt/efs）もスキャン対象のパスとして認識され、プラグインが EFS 内の全ファイルに対してアクセスを行ってしまいます。これが、S3 や EFS への大量アクセスが発生する直接的な原因です。
そして、この inspectorssmplugin の完全な停止を行うためには、「②インスタンスメタデータのタグへのアクセスを許可する」が「①」とセットで必要になります。「②」だけを単体で行っても、効果がない点にも注意してください。
まとめ
本ブログでは、Amazon Inspector によるスキャンが原因で、Amazon EFS のライフサイクルポリシーが無効化され、利用料が高騰してしまう可能性について解説しました。
あくまで「可能性」とさせて頂いているのは、実環境で設定を行う前にこの仕様に気付き、AWS サポート等で技術的な裏付けを行ったためで、実環境でのコスト増は現状回避できています。
重要なポイントは以下の通りです。
- Inspector のエージェントベーススキャンは EFS マウントポイント配下もスキャンする
- スキャンによるアクセス検知で、ファイルが IA (安価) から Standard (高価) へ移動してしまう
- 特定のパスだけを除外することはできない
- 回避策は EC2 インスタンス自体をスキャン対象外とする (
InspectorEc2Exclusion) しかない
セキュリティの強化は重要ですが、それによって予期せぬコストが発生することが稀にあります。今回は以前の S3 に引き続き、Amazon Inspector とファイルシステムのマウント、という形での注意点が明らかになりました。
EFS でライフサイクルポリシーを活用されている環境で Inspector を導入される際は、十分にご注意ください。なお補足ですが、ライフサイクルポリシーを設定していないか、もしくは全てが Standard クラスにある EFS においてはこのようなコスト増は発生しません。
最後に
今回のケースは、AWS の推奨する「ライフサイクルポリシーを用いた EFS のコスト最適化」と、責任共有モデルに基づく EC2 インスタンスの「セキュリティ強化（Inspector による脆弱性管理）」という、本来であれば両立すべきベストプラクティスがコストの観点でコンフリクトしてしまっている状況と言えます。
正しい運用を行おうとしたお客様が、その結果としてまるでペナルティのようなコスト増を受けてしまう現在の仕様は、サービス連携として非常に歯痒いものがあります。 ディレクトリ（パス）単位での除外機能など、これらがスムーズに共存できるようなアップデートが早期になされることを切に願っています。
では、またお会いしましょう。
*1:本ブログの記載にあたっては、技術的な背景や仕様、回避策について AWS サポートからの回答を踏まえて記載しています
*2:これは以前より機能改善要望を出していますが、実現されておりません
*3:以前、S3 のブログを記述したときにはこのような内容の記述はありませんでした
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
