AWS Config で費用が増加した原因を調べるときのやつ
こんにちは
摂取アルコール量は除外記録
運用イノベーション部のかわいです。
AWS Config を有効にすると、予期せぬコストが発生することがあります。
Cost Exploror から原因を探ろうとしても、どのリソースタイプが Configuration Item（設定変更の記録単位。以降 CI）を多く生成したかまでは追えません。
本記事では、何がコスト増の原因になっているか不明な状況から、 CloudWatch Metrics Insights を使って CI 数をリソースタイプ別に分けて、原因を特定する方法を紹介します。
先に、本記事で取り扱う原因ですが、以下記事に記載のステップ2が要因となったケースを想定しています。
もちろん他の原因の場合にも使える汎用的な手順なので、調査方法が知りたい方はそのまま読み進めてみてください。
※後述しますが、AWS::ec2::NetworkInterface を有効化する際は要注意です。
1. Cost Explorer からコスト増加の性質を絞り込む
まず、どのような記録方法でコスト増が発生しているかを確認します。
前提として、AWS Config の料金は主に以下で構成されており、
- 継続記録（Continuous Recording）/日次(または定期)記録（Periodic Recording）による CI 記録費用
- Config Rule の評価費用（Conformance Pack）
まずは大まかにどの部分で料金がかかっているかの目星をつける必要があります。
特に継続記録はリソースに変更が生じるごとに記録が行われるため、思わぬコスト増加に繋がることがあります。
絞り込む方法として、Cost Explorer からサービスを「Config」に絞り、ディメンションを「使用タイプ」にすると、ConfigurationItemRecorded（継続記録）、ConfigurationItemRecordedDaily（日次記録）、ConfigRuleEvaluations（ルール評価）の3点の内訳が確認できます。
↑今回のケースでは ConfigurationItemRecorded（継続記録分）で増加が見られました。
ただ Cost Explorer で分かるのはここまでなので、次はリソースタイプの内訳調査に進みます。
2.CloudWatch でリソースタイプ別のメトリクスを確認する
AWS Config は CloudWatch と統合されており、AWS/Config 名前空間に ConfigurationItemsRecorded というメトリクスが ResourceType ディメンション付きで存在しています。
念のため、まずはメトリクス自体があるかを確認します。
aws cloudwatch list-metrics \
--namespace AWS/Config \
--metric-name ConfigurationItemsRecorded \
--region ap-northeast-1
{
"Metrics": [
{
"Namespace": "AWS/Config",
"MetricName": "ConfigurationItemsRecorded",
"Dimensions": [
{
"Name": "ResourceType",
"Value": "All"
}
]
},
{
"Namespace": "AWS/Config",
"MetricName": "ConfigurationItemsRecorded",
"Dimensions": [
{
"Name": "ResourceType",
"Value": "AWS::Lambda::Function"
}
]
},
{
"Namespace": "AWS/Config",
"MetricName": "ConfigurationItemsRecorded",
"Dimensions": [
{
"Name": "ResourceType",
"Value": "AWS::IAM::Role"
}
]
}
]
}
存在していることが確認できたので、次に進みます。
3. Metrics Insights で Top N クエリを投げる
CloudWatch Metrics Insights を使って、リソースタイプ別の件数を洗い出します。
これは、CloudWatch メトリクスに対して SQL に近い構文で問い合わせできる仕組みです
今回は以下のような基本構文を応用します。
SELECT FUNCTION(metricName)
FROM namespace | SCHEMA(...)
[ WHERE labelKey OPERATOR labelValue [AND ...] ]
[ GROUP BY labelKey [, ...] ]
[ ORDER BY FUNCTION() [ DESC | ASC ] ]
[ LIMIT number ]
GROUP BY でディメンション別に時系列を分け、ORDER BY と LIMIT を組み合わせると「上位N件」を取得できる、いわゆる Top N クエリが書けます。今回はこれを ResourceType ディメンションに対して使います。
コンソールの「All metrics」からもクエリエディタで実行できますが、複数期間を機械的に比較したかったので、aws cloudwatch get-metric-data の MetricDataQueries に Expression としてクエリを渡す形で CLI から実行しました。
aws cloudwatch get-metric-data \
--start-time 2026-08-06T00:00:00Z \
--end-time 2026-08-07T00:00:00Z \
--metric-data-queries '[
{
"Id": "q1",
"Expression": "SELECT SUM(ConfigurationItemsRecorded) FROM SCHEMA(\"AWS/Config\", ResourceType) GROUP BY ResourceType ORDER BY SUM() DESC LIMIT 50",
"Period": 86400
}
]' \
--region ap-northeast-1
※SCHEMA("AWS/Config", ResourceType) は、ResourceType ディメンションを1つだけ持つメトリクスに絞り込むための指定です。これを用いることで、リソースタイプごとの CI 記録数を SUM で集計し、多い順に並べ替えた結果が得られます。
{
"MetricDataResults": [
{
"Id": "q1",
"Label": "AWS::EC2::Subnet",
"Timestamps": ["2026-08-06T00:00:00Z"],
"Values": [842.0]
},
{
"Id": "q1",
"Label": "AWS::EC2::SecurityGroup",
"Timestamps": ["2026-08-06T00:00:00Z"],
"Values": [615.0]
},
{
"Id": "q1",
"Label": "AWS::EC2::VPC",
"Timestamps": ["2026-08-06T00:00:00Z"],
"Values": [310.0]
}
]
}
ただここで注意なのが、get-metric-dataを叩く際には「直近3時間以内のデータ」のみが取得可能なため、ある程度直近の情報しか拾えない点を考慮しておく必要があります。
Data points with a period of less than 60 seconds are available for 3 hours.
▼ マネージドコンソールの場合、同様のクエリで14日間まで遡れます。可視化するのであればこちらの方がいいかも。
▼ ラベル別に一覧にもできるので見やすい
上述のクエリ結果からも、AWS::EC2::Subnetが842回、AWS::EC2::SecurityGroupも615回呼ばれています。
変更前の期間と照会し明らかに値の増加が確認できたため、ここが原因である可能性が高いと分かります。
特定リソースタイプまで絞り込めたら
先ほどの結果からも、AWS::EC2::Subnet、AWS::EC2::SecurityGroup、AWS::EC2::VPCの件数が爆増したことが確認できました。
リソースタイプがある程度絞り込めたら、以下ドキュメントから「Related Resource」を確認します。
サブネットやセキュリティグループ、VPCを関連リソースに持つリソースタイプを探すと、「AWS::EC2::NetworkInterface」が確認できました。このリソースタイプを直近で有効化したため、今回の原因だと確定できました。
これは、記録対象として追加したリソースタイプそのものではなく、付随する関連リソースタイプでも記録が取得されることに起因しています。
この点深堀りすると、AWS Config のドキュメント上に、リソース間の関係を「直接リレーション」と「間接リレーション」に分けて記録する仕様が明記されています。
AWS Config derives the relationships for most resource types from the configuration field, which are called "direct" relationships. A direct relationship is a one-way connection (A→B) between a resource (A) and another resource (B), typically obtained from the describe API response of resource (A). In the past, for some resource types that AWS Config initially supported, it also captured relationships from the configurations of other resources, creating "indirect" relationships that are bidirectional (B→A). For example, the relationship between an Amazon EC2 instance and its security group is direct because the security groups are included in the describe API response for the Amazon EC2 instance. On the other hand, the relationship between a security group and an Amazon EC2 instance is indirect because describing a security group does not return any information about the instances it is associated with.
要約すると、
- 直接リレーション（A→B）は、リソースA の API情報 から取得できる一方向の関係
- 間接リレーション（B→A）は、他のリソースの情報から推測される逆方向の関係
例として、EC2 インスタンスの API 情報にはセキュリティグループが含まれるため、EC2 → セキュリティグループ は直接的に関係しています。
反対に、セキュリティグループの API 情報には関連する EC2 が含まれないため、セキュリティグループ → EC2 は間接的な関係となります。
そのため、今回 AWS::EC2::NetworkInterface有効化によって、間接的な関係として「AWS::EC2::SecurityGroup, AWS::EC2::Subnet, AWS::EC2::VPC」が同時に取得された、という結果になりました。
対処法について
原因が分かったところで、実際に取り得る対応を整理します。
-
記録対象から一時的に除外
→ 即効性はありますが、完全に除外することで監査要件に影響するかもしれません（あまり推奨しません）。 -
関連リソースタイプも含めて日次記録へ切り替える
日次記録に記録頻度を落とすことで、CI 生成数そのものを抑えられます。recordingModeOverridesでリソースタイプ単位の記録頻度を上書きできます。
監査要件とコストとのトレードオフになりますが、上記いずれかの手段になるのかなと思います。
上記に加え、そもそも Config を適用しているアカウント数も見直しても良いかもしれません。
まとめ的な
AWS Config のコストが急増した際は、Cost Explorer だけでは「使用タイプ」までしか追えないので、まずは CloudWatch Metrics Insights から調査してみてください。
記録対象に追加した覚えのないリソースタイプで CI 数が増加している場合は、関連リソースタイプ側で記録が行われているかを調べると良いかもしれません。
参考情報
完
