検証でデプロイを繰り返したらAWS Configの料金が膨らんだ

はじめに

検証用のAWSアカウントのコストを確認していたところ、AWS Configがアカウント内で最も高いサービスになっていることに気づきました。

このアカウントはCDKのデプロイ検証にしか使っておらず、常時稼働のワークロードもありません。調べてみると、検証のためにデプロイを繰り返したことが原因で、特にスタックの削除→再作成で料金が大きく増えていました。

本記事では、気づいたきっかけから原因、対策までを整理します。

1. 料金が高いことに気づいた

Cost Explorerでサービス別の月間コストを確認したところ、AWS Configが単独で最も大きい項目になっていました。

金額の絶対値は大きくありませんでしたが（月約$10.8）、何に対して課金されているのか説明できなかったため、原因を調べることにしました。

2. Configの「構成項目の記録」で課金されていた

Cost Explorerで、AWS Configの料金を使用タイプ別に分解します。

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-02 \
  --granularity MONTHLY --metrics UnblendedCost UsageQuantity \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Config"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

全額が ConfigurationItemRecordedDaily、つまり構成項目（Configuration Item、以下CI）の記録に対する課金で、ルール評価の課金はありませんでした。使用タイプ名のとおり、記録頻度は DAILY（日次記録）です。

東京リージョン（ap-northeast-1）のCI単価は次のとおりです（AWS Config の料金、AWS Price List API で確認）。

日次記録は、同じ日の変更を1件のCIにまとめる設定です（RecordingMode）。件数は減りますが、単価は連続記録の4倍です。

3. 検証のデプロイを繰り返した日にCIが急増していた

次に、CIの記録件数を日次で見てみます。UsageQuantity がCIの記録件数です。

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-02 \
  --granularity DAILY --metrics UnblendedCost UsageQuantity \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Config"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

整形すると、次のようになりました。

9/18・9/24・9/28の3日だけが突出しており、この3日の合計773件は月間CI件数（約900件）の**約86%**でした。

この3日は、いずれもCDKのデプロイを繰り返した日でした。CloudFormationのイベント数も、CIが増えた日にだけ数百〜数千件と大きく増えていて、デプロイするたびに、デプロイしたリソース分のCIが記録されていたことになります。

4. 削除→再作成はさらに料金が高くなる

3日のうち、9/28だけ357件と他の2日（208件）より約1.7倍多くなっていました。

この日は旧スタックの削除と再作成を繰り返しました。日次記録は「前回のCIと異なる場合に記録」する仕様のため、次の両方がCIとして記録されます。

• 削除されたリソース：「削除された」状態のCI
• 新しく作られたリソース：物理IDが異なる別リソースとしての新規CI

つまり、スタックを削除して作り直すと、同じ構成でも新規作成の2倍近いCIが発生します。

5. 対策

Config側：記録対象のリソースタイプを絞る

記録対象を絞るとCI自体を減らせます。
EXCLUSION_BY_RESOURCE_TYPES（すべて記録しつつ指定タイプを除外）または INCLUSION_BY_RESOURCE_TYPES（指定タイプのみ記録）の記録戦略を使います。詳細はExcluding resources from recording with AWS Configを参照してください。

1つのリソースから多数の子リソースが作られるタイプ（API Gatewayのメソッドやリソースなど）は、除外の効果が大きくなりやすいです。ただしConfigはセキュリティやガバナンスの仕組みでもあるため、除外は監視要件と照らし合わせて判断してください。
今回のような社内のデプロイ検証環境の場合は積極的に除外すべきです。

Config側：記録頻度は損益分岐で選ぶ

「日次記録にすれば安くなる」とは限りません。日次記録は単価が連続記録の4倍のため、1つのリソースが1日に平均4回を超えて変更される場合にのみ、日次記録のほうが安くなります。変更頻度の低い環境では、連続記録のほうが安いことがあります。

デプロイ側：削除→再作成を避ける

リソースの削除→再作成は、更新に比べて2倍のCIを発生させます。
検証作業やCI/CDを見直して、リソースの削除→再作成ではなく更新を行うようにします。

まとめ

• Configの料金は、全額がCIの記録に対するものだった
• 対策は、削除→再作成を避けることと、Configの記録対象リソースタイプの絞り込み、記録頻度の見直し

検証用アカウントでConfigの料金に心当たりのある方は、まず使用タイプ別のコストを確認し、デプロイした日とCIの増えた日が重なっていないか見てみてください。