26
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

AWS Configの請求金額が高くなった原因を調べてみた

Last updated at Posted at 2021-06-14

はじめに

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

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

現状

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

CostExplolerでConfigの料金を日ごとに出すと、1日12USDぐらい。
12USD * 30日 = 360USDで、このままだと月額4万円ぐらいかかりそうです。
FireShot Capture 281 - Cost Management - console.aws.amazon.com.png

調査

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

結果

resourcetype resourceid NumberOfChanges
AWS::EC2::VPC vpc-AAAAAAAA 8138
AWS::EC2::SecurityGroup sg-BBBBBBBB 8104
AWS::EC2::Subnet subnet-CCCCCCCC 4145
AWS::EC2::Subnet subnet-DDDDDDDD 4009
... ... ...

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

Configで確認

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

image.png

確かに変更がたくさん記録されています。
中を開いてみると、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の料金にも注意したほうがよさそうです。
今回は記録対象から外すことで対応しましたが、
リソースタイプを丸ごと対象外にするといった大雑把な方法です。

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

26
11
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
26
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?