AWS Configの記録頻度最適化でコストを大幅削減

 はじめにこんにちは、KINTOテクノロジーズ CloudSecurityグループの小林です。
皆さん、AWS Configのコストが高いなと思ったことはありませんか？

今回、記録方式の最適化で約80%のコスト削減を実現しました。

本記事ではその過程と得られた知見を共有します。
 本記事の対象読者AWS Configのコストが気になっている方
AWSのコスト最適化に取り組んでいる方
セキュリティ要件とコストのバランスを考えている方
大規模なAWS環境を運用している方
Control TowerやOrganizationsを使って複数アカウントを管理している方
 AWS ConfigとはAWS Configは、AWSリソースの設定変更を記録・追跡するサービスです。
主な用途は以下の通りです：
リソース設定の変更履歴を記録
コンプライアンスルールへの準拠状況を監視
セキュリティ基準違反の検知
設定変更の監査証跡として活用
 背景：なぜ見直しが必要だったのかAWS Configは便利なサービスですが、

記録回数に応じて課金されるため、大規模環境ではコストが大きくなりがちです。
主な要因は以下の通りです。
記録対象リソースの増加（特にネットワーク関連リソース）
連続記録モードによる頻繁な記録
 Control Tower環境での課題弊社では AWS Control Towerを使用して複数アカウントを管理しています。

AWS Configのコスト削減を検討する中で、取りうる選択肢は以下の2つでした。
選択肢1: 現状維持（全て連続記録）
コストが高いまま
Control Towerのベストプラクティスに従う
選択肢2: StackSet (aws-control-tower-customizations) で記録頻度を最適化
AWSソリューション: aws-control-tower-customizations
大幅なコスト削減が期待できる
Control Towerが作成したConfigリソースを変更することになる
 Control Tower のベストプラクティスとの兼ね合いAWS Control Towerの公式ドキュメントには、以下のような記載があります：
「AWS Control Towerによって作成されたリソースを変更または削除しないでください。」
出典元: AWS Control Tower リソースの作成と変更に関するガイダンス
この記載により、選択肢2の採用には慎重な姿勢を取らざるを得ませんでした。
具体的な懸念事項は以下の通りです。
Configレコーダーの変更がControl Towerの動作に影響しないか
ドリフト検出機能が正しく動作するか
コンプライアンスレポートの正確性が保たれるか
ランディングゾーンの更新やOUの再登録が必要にならないか
このため、コスト削減の必要性は認識していたものの、実施に踏み切れない状況が続いていました。
 記録回数の実態記録回数を調査したところ、以下のリソースタイプの記録回数が特に多いことがわかりました。
記録回数が多かったリソースタイプ TOP4：
EC2 NetworkInterface - ネットワークインターフェースの状態変化
EC2 Subnet - サブネットの状態変化
EC2 SecurityGroup - セキュリティグループの関連付け変化
Config ResourceCompliance - コンプライアンスチェック
なぜこれらの記録回数が多いのか？
連続記録モードでは、リソースに何らかの変更（内部状態の変化も含む）があるたびに記録されます。

これらのリソースの記録が多い原因は、ENIの作成/削除を起点とした連鎖的な記録にありました。
① EC2 NetworkInterface（根本原因）
ECSタスクの起動/停止に伴いENIが頻繁に作成・削除されており、そのたびにConfigの記録が発生
VPC接続を有効化したLambda関数の場合も同様です。

② EC2 Subnet（ENI に連動）
ENIの作成・削除に伴い、対象のサブネットの設定項目が記録
VPC接続を有効化したLambda関数の作成時も同様です。

③ EC2 SecurityGroup（ENI に連動）
ENIの作成・削除に伴い、その ENIに関連付けられたSecurityGroupの設定項目も記録
④ Config ResourceCompliance（すべてに連動）
AWS::Config::ResourceComplianceは、Configルールによって評価されたリソースのコンプライアンス状態の変化を記録するリソースタイプです。
上記の各リソースで新しい設定項目が記録されるたびにConfigルールの評価が走り、その結果がResourceComplianceとして記録されます。

まとめると:

ENIの変更が起点となり、関連するSubnet、SecurityGroupの記録が連鎖的に発生し、

さらにそれぞれのConfigルール評価が走ることで、記録回数が増加していました。

コンテナやサーバーレスを多用している環境ほど、この傾向は顕著になります。
 解決策：記録頻度の最適化検証の結果、選択肢2のaws-control-tower-customizationsはControl Towerの検出コントロールやドリフト検出に影響しないことが判明しました。

こちらのソリューションはControl Tower側で変更があった場合にもドリフトが発生しないよう設計されているため、安全に記録頻度の変更を展開できると判断し、選択肢2の実施に踏み切りました。
 方針：リソースタイプごとに記録方式を分けるすべてのリソースを一律に変更するのではなく、コスト構造を分析した上でリソースタイプごとに最適な記録方式を選択しました。
日次記録に変更したリソース：
EC2 NetworkInterface
EC2 Subnet
EC2 SecurityGroup
連続記録のまま維持したリソース：
上記以外のリソースタイプ
Config ResourceCompliance
日次記録非対応

連続記録は記録回数ベース、日次記録はリソース数ベースの課金です。

記録回数がリソース数に対して大幅に多いリソースタイプだけを日次記録に変更し、

それ以外は連続記録のまま維持するのが最もコスト効率が良い方法です。
 展開方法記録頻度の変更はaws-control-tower-customizationsを利用し、管理アカウント上でCloudFormationテンプレートを展開することで、Control Tower管理下の全アカウントに一括適用しました。
 セキュリティへの影響日次記録にすると、変更の途中経過は記録されません。

また、Configルールの評価タイミングはルールのトリガー方式（変更通知トリガーか、定期評価か）によって異なります。
スケジュールベースの定期評価ルールは、記録頻度にかかわらず設定された評価間隔で実行されます。

一方で、設定変更検知ベース（変更通知トリガー）のルールについては、日次記録の場合、評価に利用される設定情報が最大24時間前の状態となるため、実際の設定違反検知が最大24時間遅延しうる点に注意が必要です。
ただし、弊社環境では以下のサービスと併用することで、セキュリティ要件は維持できると判断しました。
CloudTrailでAPIレベルの変更履歴は引き続き記録される
Security Hubでのセキュリティ準拠チェック
GuardDutyでの異常検知
SIEMサービスを利用した通知・分析
 結果以下はCost Explorerでの日別コスト推移です。

切り替え前後でコストが大幅に低下していることがわかります。
 学び・Tips 1. コスト構造の理解が重要AWS Configの料金は「記録回数」に基づくため、以下を理解することが重要です。
どのリソースタイプが多く記録されているか
なぜそのリソースが頻繁に記録されるのか
記録頻度を変更できるリソースはどれか
リソースタイプ別の記録回数は、CloudWatch メトリクス（AWS/Config ネームスペース）のConfigurationItemsRecordedをResourceType別に確認できます。

AIエージェントにCloudWatchを参照させて調査することもできます。

また、リソース数は以下のコマンドで取得できます。
aws configservice get-discovered-resource-counts --region ap-northeast-1
 2. この最適化が向いていないケースすべてのリソースでリアルタイム記録が必須
変更の途中経過も記録が必要
セキュリティ要件が厳しく、日次記録では不十分
Configルールを利用した自動修復などを利用している
 まとめ今回は記録回数の多いリソースタイプを特定し、日次記録に切り替えることで約80%のコスト削減を実現しました。

セキュリティ要件はCloudTrail、Security Hub、SIEMなどで補完できるため、実運用上の問題もありません。
本記事が同様の課題を抱えている方の参考になれば幸いです。
 参考資料AWS Config 料金
AWS Config の記録モード