マネージドサービス部 佐竹です。
Amazon Inspector (インスペクター) による Amazon EC2 インスタンスのスキャンによって Amazon S3 の費用が高騰するケースについて記載します。
はじめに
Amazon S3 の利用料が高額になる原因としては様々ありますが、特に以下の3つが高額になるケースを経験してきています*1。
- ストレージクラスの GB 単価に基づいて課金される、保存されたデータ容量に対するストレージ料金
- API リクエスト料金とも呼ばれるリクエストとデータ取得料金。例えば、GET、PUT、LIST といった操作で、行われる API の呼び出し回数に基づくもの
- インターネットや他リージョンにデータを転送する際のデータ転送料金
今回は、2つ目の「API の呼び出し回数」が増加したことによる課金額の急増を経験しましたため、本ブログ記事に注意喚起と備忘を目的として記載しご紹介とさせて頂きます。
Amazon S3 へのリクエスト費用が高額になる条件
まずは最初に Amazon Inspector によって Amazon S3 へのリクエスト費用が高額になる条件についてまとめておきます。以下の条件が全て揃った場合に発生した実績があります。
- EC2 インスタンスに Systems Manager Agent がインストールされている
- Systems Manager が正常に動作する状態となっている
- Amazon Inspector が有効化されている
- Amazon Inspector のオプションである EC2 インスタンスのスキャンが有効化されている
- Amazon S3 のバケットに大量のオブジェクトが配置されている
- Amazon S3 のバケットを EC2 インスタンス上にマウントしている
まずは、これらの条件を1つずつ簡単にご説明します。
EC2 インスタンスに Systems Manager Agent がインストールされている
Systems Manager (SSM) Agent はデフォルトで AMI にインストールさています。例えば、Amazon Linux や Windows OS がそうです。
条件については詳しくは以下をご確認ください。
このため多くの場合でEC2 インスタンスには SSM Agent がインストール済であることが多いでしょう。
しかし、SSM Agent がインストールされているだけでは Systems Manager が動作することはありません。
Systems Manager が正常に動作する状態となっている
Systems Manager が正常に動作するためには、まず起動した EC2 インスタンスにおいて IAM Role（インスタンスプロファイル）の設定が施されている必要があります。さらにアウトバウンドのインターネットアクセスが可能か、SSM の VPC Endpoint ( ssm.ap-northeast-1.amazonaws.com ) と通信が可能である必要があります。
確認方法として、SSM Agent がインストールされている EC2 インスタンスにおいて、Systems Manager が正常に動作するかどうかは AWS マネジメントコンソールの Fleet Manager から対象のインスタンスが「マネージドノード」として表示されているか否かで判断が可能です。
前提条件が満たされていると考えられるにもかかわらず、マネージドノードとして一覧に表示されない場合は、以下のトラブルシューティングをご参考ください。
Amazon Inspector が有効化されている
上記 AWS 公式ブログに
Amazon Inspector は、Systems Manager (SSM) エージェント を使用して Amazon EC2 インスタンスのソフトウェアアプリケーションインベントリを収集します。
と記載があるように、SSM Agent を介して Amazon Inspector は動作します。
このため、SSM Agent が動作している EC2 インスタンスにおいては、Amazon Inspector を有効化するだけで脆弱性診断が開始されます。
Amazon Inspector のオプションである EC2 インスタンスのスキャンが有効化されている
Amazon Inspector には Amazon EC2 インスタンスのスキャンが可能なオプションが用意されています。
上画像のように、Amazon EC2 scanning の設定が「Activated」されている場合、EC2 インスタンスのスキャンが有効化されていることがわかります。
本設定の詳細は以下の各ドキュメントもご参考ください。
なお、本 EC2 インスタンスのスキャン頻度は（Windows の場合）デフォルトで「6時間毎」となっています。
このスキャン頻度を変更するには aws ssm update-association の AWS CLI を利用する必要があります。以下はスキャン頻度を「14日に1回へと変更する例」です。
aws ssm update-association --association-id "1111e!1e-sample-id-test-bca1111111c1" --association-name "InvokeInspectorSsmPlugin-do-not-delete" --schedule-expression "rate(14 days)" --region ap-northeast-1
注意点としてはこのコマンドを実行すると、そのタイミングで1回目のスキャンが実行されるという点です。その後、約14日後に2回目のスキャンが実行されるという流れになります。
「インスタンススキャンのカスタムスケジュールの設定」については以下のドキュメントも合わせてご確認ください。
Amazon S3 のバケットに大量のオブジェクトが配置されている
対象の Amazon S3 のバケットに大量のオブジェクトが配置されているかどうかは、CloudWatch もしくは S3 Storage Lens 等で確認が可能です。
CloudWatch では各バケットにおいてメトリクス NumberOfObjects を確認します。
Amazon S3 のバケットを EC2 インスタンス上にマウントしている
Amazon S3 のバケットを EC2 インスタンス上にマウントし、ドライブとして利用することが可能となる 3rd Party 製品が存在します。
代表的な製品としては現「MSP360 (旧 CloudBerry ) Drive」あたりでしょうか。最近では「JPCYBER S3 Drive」を耳にすることが増えました。
これらの製品を導入している場合、S3 バケットの API 履歴には Useragent が本製品名として記録される点が特徴です。
条件が揃った場合にコスト増が発生する理由
これらの条件が全て重なった場合、Amazon S3 バケット内に存在する大量のオブジェクトが Amazon Inspector の Agent によってフルスキャンされてしまうことが判明しています。そしてその結果、S3 の API リクエスト料金が高額になってしまう場合があります。
なお、このフルスキャンは「ディレクトリ（フォルダ）」ごとに進むため、バケット内の各オブジェクトに階層構造が作られている場合はオブジェクト数よりも API リクエスト料金が増加することも判明しています。
そしてデフォルトでは6時間毎にスキャンが行われるため、高頻度にバケット内のオブジェクトがフルスキャンされてしまい、急激なコスト増に見舞われることもあるでしょう。場合によっては、AWS Cost Anomaly Detection でコストの異常が検出されます。
コスト増が発生した場合の対処方法
コスト増のための回避策は以下の通りです。
1. スキャン除外のためのタグキーを付与する
S3 バケットをマウントしている対象の EC2 インスタンスにタグキー InspectorEc2Exclusion を付与してください。値（バリュー）は不要です。
ただし、本設定のみでは Amazon Inspector のスキャンが停止できないことがわかっています。
2. インスタンスメタデータのタグへのアクセスを許可する
EC2 インスタンスのスキャンを完全に停止するためには Inspectorec2Exclusion タグキーの付与に加えて、インスタンスメタデータのタグへのアクセスを許可する必要があります*2。
詳しくは以下のドキュメントに記載のある通りですが、マネジメントコンソールからでも操作は可能であり「Allow tags in instance metadata」で設定が可能です。
デフォルト「Disabled」となっているため、設定を意図的に行っていない限りは「Disabled」のままかと想定されます。
なお、本設定を許可するにあたり、前提条件として以下も運用上の注意が必要です。
合わせて、Patch Group を PatchGroup へと修正する
SSM で運用を行っている場合に、「Patch Group」というタグキーを利用されている場合も多いと存じます。
問題は、SSM が指定するこのタグキーに「半角スペース」が含まれている点です。以下の通り、インスタンスメタデータのタグへのアクセスを許可するには、タグキーに半角スペースは使用できません。
このため、「Patch Group」タグキーが付与されている EC2 インスタンスでは、インスタンスメタデータのタグへのアクセスを許可するタイミングで以下のエラーが発生してしまいます。
An error occurred (InvalidParameterValue) when calling the ModifyInstanceMetadataOptions operation: 'Patch Group' is not a valid tag key.
これを回避するには「Patch Group」を「PatchGroup」へと修正する必要があります。過去、SSM はその設定において「Patch Group」のみを設定可能としていましたが、2022年8月末に「PatchGroup」も利用可能となるアップデートが施されています。
もし、その他のタグキーにおいても「半角スペース」が含まれている場合は、そのタグキーを削除していただく必要がある点には注意して本設定を有効化ください。
ディレクトリの除外設定はできない
現状、Amazon Inspector ではスキャン対象のディレクトリやフォルダを除外する設定を行うことができません。
このため、先の通り「スキャン自体が行われないよう EC2 インスタンス自体に除外設定を行う」対処が必要となります。
まとめ
本ブログでは、意図せず Amazon Inspector (インスペクター) による Amazon EC2 インスタンスのスキャンによって Amazon S3 の API リクエスト費用が高騰してしまったケースについて記載しました。
再掲となりますが、前提条件は以下の通りです。
- EC2 インスタンスに Systems Manager Agent がインストールされている
- Systems Manager が正常に動作する状態となっている
- Amazon Inspector が有効化されている
- Amazon Inspector のオプションである EC2 インスタンスのスキャンが有効化されている
- Amazon S3 のバケットに大量のオブジェクトが配置されている
- Amazon S3 のバケットを EC2 インスタンス上にマウントしている
また、本事象の対応方法は以下の通りです。
- スキャン除外のためのタグキー (InspectorEc2Exclusion) を EC2 インスタンスに付与する
- EC2 インスタンスでインスタンスメタデータのタグへのアクセスを許可する
少々再現性の低い前提条件とは思われますが、Amazon S3 バケットを EC2 インスタンスへとマウントして利用されている場合には Amazon Inspector のスキャンには十分にご注意ください。
では、またお会いしましょう。
*1:以下の3つは AWS 公式ブログを参考にしています https://aws.amazon.com/jp/blogs/news/optimize-storage-costs-by-analyzing-api-operations-on-amazon-s3/
*2:2024年2月現在 AWS ドキュメントに掲載がない仕様
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
