はじめに

AWS Configを使うと、リソースへの変更が記録されていくため、
この変更は誰がいつしたのだろう？など監査をするのに便利です。
他にも設定ルール通りになっているかのチェックもできます。

そのAWS Configなのですが、
利用料金が高くなっている旨がコストの異常検出で検知されました。
なぜ高くなったのか内訳を調べてその対応をした時の記録を残しておきます。

現状

請求書のConfigの欄を見てみると、
ConfigurationItemRecorded、つまり設定変更の記録に費用が掛かっていることがわかりました。
10日の時点で32019回なので1日3000回ぐらい変更がなされてそれを記録しているとのこと。
人間がそんなに数多く設定変更しているとは思えないので、何か原因がありそうです。

CostExplolerでConfigの料金を日ごとに出すと、1日12USDぐらい。
12USD * 30日 = 360USDで、このままだと月額4万円ぐらいかかりそうです。

調査

ConfigのログはS3に記録されているので、それをAthenaで検索すれば、
どのリソースへの変更がたくさん記録されているか（費用が掛かっているか）を調べることができそうです。
参考：1 か月あたりに記録された設定項目の数を取得することにより、AWS Config の請求を理解する方法を教えてください。

Athenaテーブルの作成

上記の参考ページをベースに調査を進めます。
Athenaコンソールを開き、クエリエディタで以下のSQLを流します。
awsconfigというデータベースの中にawsconfigテーブルを作っています。
LOCATIONのS3パスについてはConfigの設定を参考に埋めます。

CREATE DATABASE awsconfig;

CREATE EXTERNAL TABLE awsconfig.awsconfig (
         fileversion string,
         configSnapshotId string,
         configurationitems ARRAY < STRUCT < configurationItemVersion : STRING,
         configurationItemCaptureTime : STRING,
         configurationStateId : BIGINT,
         awsAccountId : STRING,
         configurationItemStatus : STRING,
         resourceType : STRING,
         resourceId : STRING,
         resourceName : STRING,
         ARN : STRING,
         awsRegion : STRING,
         availabilityZone : STRING,
         configurationStateMd5Hash : STRING,
         resourceCreationTime : STRING > > 
) 
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe' LOCATION 's3://<BUCKET-NAME>/AWSLogs/<ACCOUNT-ID>/Config/<REGION>/';

SQLで調査

作成したAthenaテーブルにSQLを投げて、どのリソースへの変更が多いのかを調べます。

SELECT configurationItem.resourceType,
         configurationItem.resourceId,
         COUNT(configurationItem.resourceId) AS NumberOfChanges
FROM awsconfig.awsconfig
CROSS JOIN UNNEST(configurationitems) AS t(configurationItem)
WHERE "$path" LIKE '%ConfigHistory%'
        AND configurationItem.configurationItemCaptureTime >= '2021-06-01T%'
        AND configurationItem.configurationItemCaptureTime <= '2021-06-10T%'
GROUP BY  configurationItem.resourceType, configurationItem.resourceId
ORDER BY  NumberOfChanges DESC

結果

この4件が突出して多いことがわかりました。
sg-BBBBBBBBやsubnet-CCCCCCCC, subnet-DDDDDDDDは
vpc-AAAAAAAAに紐づいているものなので、
実質的にはvpc-AAAAAAAAに対する変更が主な要因だということがわかりました。

Configで確認

vpc-AAAAAAAAをConfigで見てみましょう。
Config > リソース > vpc-AAAAAAAA > タイムライン

確かに変更がたくさん記録されています。
中を開いてみると、EC2のNetwork Interface(ENI)をつけたり外したりが記録されていました。

問題となったVPC(vpc-AAAAAAAA)はApp Runnerで使うために作ったVPCです。
どうやらデプロイしたり負荷の増減などでコンテナの増減があると
そのコンテナに関連したENIがVPCやsubnetに割り当てられて、
Configに記録される(=費用が掛かる)ということのようです。

対応

これらのリソースに対する変更はConfigには記録しないようにすることで対応します。
コンソール画面で Config > 設定 > 編集 と開きます。
設定の編集 画面で 記録するリソースタイプ を このリージョンでサポートされているすべてのリソースを記録します に設定していたのを、
特定のリソースタイプを記録する に変更します。
そして、リソースタイプで
　AWS EC2 NetworkInterface
　AWS EC2 SecurityGroup
　AWS EC2 Subnet
　AWS EC2 VPC
以外をすべて選択します。

これらを記録対象から外したところ、Configの料金を抑えることができました。

おわりに

App Runnerなどオートスケールするようなサービスを利用するときはConfigの料金にも注意したほうがよさそうです。
今回は記録対象から外すことで対応しましたが、
リソースタイプを丸ごと対象外にするといった大雑把な方法です。

もっと他に良い方法をご存知の方、教えていただけると幸いです。