AWS Config の記録頻度を分析するためのベストプラクティス

本記事は 2025 年 8 月 5 日に公開された「Best practices for analyzing AWS Config recording frequencies」を翻訳したものです。

AWS Config は、AWS リソースおよび AWS Organizations 全体の設定変更を追跡します。AWS Config は設定レコーダーを使用して変更を検出し、それを設定項目 (CI) として記録します。インフラストラクチャが成長し複雑になるにつれ、運用上の可視性の維持、コンプライアンス要件への対応、セキュリティ態勢を支えるために、適切な記録頻度を選択することが重要になります。

2023 年の定期的記録機能のローンチ以降、記録方法には 2 つの選択肢があります。1 つ目は継続的記録で、設定変更が発生するたびにすべてをキャプチャし、環境をリアルタイムに可視化します。2 つ目は定期的記録で、リソースの最新の状態を 24 時間ごとにキャプチャしますが、記録されるのは前回記録した状態と異なる場合のみです。定期的記録は、変更が多い環境において CI の総数を削減できます。それぞれのアプローチは異なる運用ニーズに対応しており、最適な記録頻度を選択することで、個々のユースケースに適した可視性のレベルを維持できます。

この記事では、環境を評価し、運用、セキュリティ、コンプライアンスの目標に最も適した記録頻度を選択する方法を解説します。AWS Config を導入する際の意思決定のフレームワークと一般的なシナリオを取り上げ、リソースインベントリやコンプライアンスレポート、およびコストを最適化するためのベストプラクティスを紹介します。さらに、これらのベストプラクティスは、プロアクティブコントロールを適用して大規模なガバナンスを実現し、運用上の俊敏性を高めることにも役立ちます。

AWS Config に求める要件を理解する

AWS Config は環境内の変更を追跡することで、主に次の 4 つの目的を果たします。それぞれ記録頻度の要件は異なります。

• リソースインベントリの管理
• コンプライアンス評価のための Compliance-as-Code
• 運用調査とセキュリティ調査の効率化
• 継続的な監査

記録頻度の決定は、これらの目的において AWS Config をどのように使用するかに合わせる必要があります。ワークロードによって要件は異なります。リアルタイムのコンプライアンス監視やセキュリティインシデント対応には、通常、継続的記録が必要です。リソースインベントリや運用上のトラブルシューティングは、変更のパターンや対応時間の要件によっては、定期的記録でも十分に機能する場合があります。AWS Config を使用すると、ユースケースにとって最も重要な環境内の変更を追跡できます。そして、修復ルール、アラート、分析を作成することで、それらの変更に対応し、将来の変更に備えることができます。こうした違いを理解することで、運用ニーズに合ったきめ細かな記録戦略を実装できます。

環境の特性

AWS 環境の特性は、最適な記録頻度に大きく影響します。動的な環境には、AWS Lambda、Amazon EKS、Amazon EMR といったサービスを使用して自動的にスケールする一時的なリソースが含まれます。これらのリソースは、ワークロード、スケジュール、開発およびデプロイのパターンに応じて頻繁に状態が変化します。静的な環境には、Amazon RDS や Amazon VPC といったサービスを使用した、より永続的なリソースが含まれます。これらのリソースは、ネットワークやデータの要件により、長期にわたって存続し、一定の状態を保つことが期待されます。変更頻度の低い長時間稼働のリソースは、どちらの記録モードでも同程度の CI 数になる可能性があるため、完全な可視性を得られる継続的記録が望ましくなります。

記録頻度の意思決定フレームワークを検討するにあたり、次の例を考えてみましょう。

• シナリオ A: 開発環境で、Amazon EMR と Amazon EC2 スポットインスタンスを使用して短時間のタスクをデプロイし、終了させています。各タスクの実行時間は 1 時間未満です。ジョブごとにスポットインスタンスを解放し、Amazon EMR クラスターを終了させます。また、複数の変更を加えています。
• シナリオ B: 本番環境で、クラスターとタスクは終了前に少なくとも 24 時間稼働し、クラスターやタスクの設定への変更はほとんど行いません。

記録頻度の選択を成功させるには、主要なユースケースと併せて次の 3 つの重要な要素を評価する必要があります。

• リソースの静的性
• リソース間の関係
• ベースラインの変更頻度

図 1. Amazon EMR および関連サービスと AWS Config 設定項目の関係

リソースの静的性

リソースの静的性の分析とは、リソースがいつ、どのように状態を変えるかを理解することです。記録モード間で CI 数を比較することで、生成されるデータ量の差を定量化し、リソースの追跡を最適化できます。シナリオ A のように短命なリソースが存在する環境では、継続的記録によって開始、終了、および関連する変更が記録され、運用状況を漏れなく把握できます。定期的記録では、開始と停止が 24 時間以内に収まるようなリソースの一時的な状態変化は記録されないため、運用状況の把握に欠落が生じる可能性があります。シナリオ B のように 24 時間を超えて稼働するリソースがある静的な環境では、継続的記録であれば引き続き運用状況を漏れなく把握できます。そして定期的記録では、2 日間にわたる状態の遷移が記録されます。AWS Config は、24 時間を超えて存続するリソースについては、どちらの記録方法でも開始と終了を記録します。

訳注：ここでの分岐点はリソースの寿命です。例えば、10 月 1 日に起動して 10 月 5 日に停止したリソースは、開始と終了が別々の記録タイミングに入るため、どちらの記録方法でも 2 つの CI が記録されます。つまり継続的記録を定期的記録に切り替えても CI 数は減りません。一方、1 時間で起動と停止が完了するようなリソースは、定期的記録では次の記録タイミングを迎える前に消えてしまうため記録されません。CI 数は減りますが、その分の可視性は失われます。

リソース間の関係

Amazon EMR の環境と DescribeCluster API アクションで確認できるコンポーネントを考えてみましょう。Amazon EMR クラスターを作成すると、多くのやり取りが発生します。例を挙げます。

• Amazon EC2 インスタンスがアタッチされる
• Amazon VPC 上で動作する
• IAM プロファイルを利用する
• EBS ボリュームがアタッチされる
• EC2 インスタンスにパッチを適用するため AWS Systems Manager にアタッチされる
• AWS Config ルールがトリガーされる

つまり、1 つの変更が関連リソースにおいて複数の CI を生成する可能性があります。間接的な関係を使用している場合、EC2 インスタンスへの 1 つの変更が 4 つの CI を生成することがあります。

• セキュリティグループ
• サブネット
• VPC
• EC2 インスタンス

訳注：間接的な関係 (indirect relationship) はデフォルトで有効な設定で、リソース A の Describe API からは導出できない逆方向の関係 (例: セキュリティグループから EC2 インスタンスへの関係) に基づいて CI を生成する仕組みです。AWS サポートへの依頼により、アカウントおよびリージョン単位で無効化できます。詳細は AWS Config FAQ を参照してください。

Systems Manager のマネージドインスタンスの場合、定期的記録でも開始と停止の少なくとも 2 つの CI が記録されます。これは非マネージドのインスタンスとは異なり、追加の CI が生成されることを意味します。しかもこれは、コンプライアンスチェックのための AWS Config ルール (これもまた関係のひとつです) が動作する前の段階での話です。

環境内に存在し得る AWS サービス間のこうした関係を理解することは、適切なリソースに適切な記録頻度を設定するために重要です。

ベースラインの変更頻度

記録設定を停止またはオーバーライドすると、リソースタイプごとに記録頻度が変わることになります。また、AWS Config のレコーダーの料金は AWS アカウントごと、および AWS リージョンごとに配信された CI 単位で発生するため、頻度の変更が妥当かどうかを判断するには、リソースタイプごとの変更頻度を理解する必要があります。

Amazon EMR や Amazon EKS を考えてみましょう。クラスターの作成で 1 CI、クラスターの終了で 1 CI が生成されます。本記事の公開時点では、継続的記録のコストは配信された CI あたり $0.003、定期的記録は配信された CI あたり $0.012 です。シナリオ B では、クラスターと同様に、一時的な EC2 インスタンスが 24 時間を超えて稼働します。定期的記録のほうがコスト効率が高くなるのは、インスタンスの開始・停止のタイミングがクラスターの開始・停止と一致せず、かつインスタンスの開始から停止までの 2 日間にインスタンス以外で 3 つの CI が発生する場合に限られます。インスタンスタイプの変更やタグの更新といった変更は、通常、CI の総数を削減できるほど頻繁には発生しません。

分析

定期的記録と継続的記録の違いを理解するには、まず継続的記録から始めて、CI 数の推移を観察します。次に、特定のリソースについて定期的記録に切り替え、CI 数を比較します。CI をクエリする方法の例については、「AWS Config の請求を把握するために、月ごとに記録された CI 数を利用する方法を教えてください。」を参照してください。

以下の表は、シナリオ A を想定した場合の、継続的記録と定期的記録における全リソースの 1 日あたりの CI 数をまとめたものです。

表 1. シナリオ A を想定した場合の、継続的記録と定期的記録における全リソースの 1 日あたりの CI 数の比較

以下の表は、シナリオ B を想定した場合の、継続的記録における全リソースの 1 日あたりの CI 数と、EC2 タイプにおける定期的記録との差分をまとめたものです。

表 2. シナリオ B を想定した場合の、継続的記録における全リソースの 1 日あたりの CI 数と、EC2 タイプにおける定期的記録との差分

訳注：表 2 では EC2 関連のリソースタイプのみを定期的記録に切り替えており、それ以外のリソースタイプは継続的記録のままです。そのため非 EC2 行の「定期的記録」列は、定期的記録による削減効果を示すものではありません。たとえば AWS::Config::ResourceCompliance の大幅な減少は、EC2 の変更が減ったことでルール評価の回数が減った結果です (AWS::Config::ResourceCompliance と AWS::Config::ConformancePackCompliance は AWS Config の仕様上、定期的記録に設定できません)。また AWS::SSM::Document の定期的記録の欄が空なのは、計測時にデータが得られなかったためです。

この分析の目的は、継続的記録において 1 日あたりの CI が 4 を超え、かつ定期的記録に切り替えることで CI の総数が 75% 以上削減されるリソースタイプを見つけることです。表 2 では、EC2 インスタンスは定期的記録により CI が 90% 減少していますが、NetworkInterface は 34%、Volume は 30% の削減にとどまっています。表 1 では、EC2::SubnetRouteTableAssociation、KMS::Key、EC2::NatGateway、KMS::Alias、Events::Rule、ECS::Cluster は CI が 4 を超えておらず、定期的記録では CI がゼロになりました。

その結果、前述の 3 つの重要な要素を踏まえると、(継続的記録から定期的記録に切り替えた場合に) 表 2 では NetworkInterface と Volume により AWS Config の全体コストがむしろ増加し、その一方で表 1 では全体コストが削減されることがわかります。

ここからは、AWS Config の記録機能における 4 つの一般的なユースケースについて説明します。

ユースケース 1: リソースインベントリの管理

AWS リソースの正確なインベントリを維持するには、AWS Config において適切な設定追跡のアプローチを選択する必要があります。定期的記録モードと継続的記録モードがコスト、効率、セキュリティ、運用上の可視性にどう影響するかを理解することで、リソース管理の戦略を最適化できます。また、AWS が (リソース間の) 関係を利用して既にインベントリを取得していることも理解しておく必要があります。AWS Config では、すべての関係のインベントリを一元的に取得することになるため、どの関係に追跡する価値があるのかを理解し、インベントリが重複している箇所を特定することが重要です。

Amazon EMR のタスクフローの例の分析に基づくと、まずは 1 つのリソースタイプ、たとえば EC2 インスタンスについて定期的記録を有効にしたいと考えるかもしれません。しかし、前述のリソース間の関係のセクションで述べたとおり、他のリソースも分析する必要があります。シナリオ A の場合、AWS Config は (EC2 インスタンスタイプとは異なり) 少なくとも Systems Manager に関連付けられた開始イベントと停止イベント、およびインスタンスに関連付けられた EBS ボリュームを引き続き記録します。EC2 インスタンス上のソフトウェアインベントリの変更を記録し続けるには、ManagedInstanceInventory を記録する必要があります。以下のグラフは、Amazon EMR クラスターの起動に伴って多数のサービスで CI が増減する様子を示しています。

図 2. 継続的記録において、Amazon EMR クラスターの起動と停止に伴って増減する Amazon EMR および関連サービスの AWS Config 設定項目

ベストプラクティス: 環境の要件に基づき、複数のサービス (EC2、Systems Manager) からの追跡が必要かどうかを評価してください。

ユースケース 2: コンプライアンス評価のための Compliance-as-Code

HIPAA (Health Insurance Portability and Accountability Act)、GDPR (General Data Protection Regulation)、PCI DSS (Payment Card Industry Data Security Standard) などの規制の対象となる組織は、AWS Config を使用して Compliance-as-Code のフレームワークを導入するのが一般的です。このアプローチでは、ルールをコードとして定義することでコンプライアンスの監視を自動化し、AWS 環境全体で一貫性のあるスケーラブルなコンプライアンスチェックを実現します。本番環境では、PHI を処理するリソースに影響する設定変更について、詳細な監査履歴とリアルタイムの可視化を維持するために、継続的記録を導入することが考えられます。

Amazon EMR のタスクフローの例の分析に基づくと、AWS::Config::ResourceCompliance の CI が最も多いことに気づくかもしれません。ここで重要なのは、コンプライアンスステータスを正確にレポートし、AWS Config の設定タイムラインを使用するには、このリソースタイプを記録する必要があるという点です。さらに前述のとおり、多くの AWS Config ルールは変更をトリガーとして実行され、ResourceCompliance の CI を生成します。コンプライアンスのために AWS Config ルールを利用する場合は、ルールのトリガーと記録頻度の戦略を揃えることで、効果を最大化できます。また、関連する AWS Config や AWS Security Hub のコントロールに必要なリソースタイプも評価する必要があります。

ベストプラクティス: AWS Config ルールと記録頻度を揃えることで、コンプライアンスレポートとコストの両方を最適化してください。

ユースケース 3: 運用調査とセキュリティ調査の効率化

リソースの状態を正確に把握し続けることで、リソースに関する確かな情報が得られ、開発のプラクティスを効率化できます。また、問題の修復とその状態の確認をより迅速に行えます。AWS Config ルールは変更に基づいて迅速に対応するのに役立ち、予期しないイベントの通知を受け取ることができます。変更に対する可視性のレベルやニアリアルタイムの更新は、環境とワークフローによって異なります。下位の開発環境 (本番環境から遠い開発段階の環境) では、リソース変更のうち、24 時間を超えて残っているもののみを追跡したい場合があります。ステージング環境では、他のワークロードとの依存関係や関係を追跡したいものの、即時の修復アクションを実装する必要はない場合があります。

前述の分析に基づくと、短命なリソースについて記録頻度を比較した結果 (表 1) から、頻繁に変更が発生する下位環境における日次の異常が明らかになります。Amazon EMR クラスターを作成する際、AWS Key Management Service (AWS KMS)、DynamoDB、Events といったサービスがインフラストラクチャにおける重要な依存関係として浮かび上がることがあります。CI が最も多いリソースタイプを選ぶのではなく、頻繁に変更が発生する下位環境における異常や、本番前環境における関係ベースのサービス (他の多くのリソースタイプを伴うサービス) といったように、環境ごとの役割を評価する必要があります。以下のグラフは CI の増減を示していますが、図 2 とは異なりより散発的であり、運用上のニーズに基づいてサービスの監視対象をより絞り込めることを表しています。

図 3. 定期的記録において、Amazon EMR クラスターの起動と停止に伴って増減する Amazon EMR および関連サービスの AWS Config 設定項目

ベストプラクティス: 複数のアカウントを使用して環境とワークロードを分離し、AWS Config の記録戦略をより細かく調整してください。

ユースケース 4: 継続的な監査とニアリアルタイム検出

多くの組織では、チームの運用を標準化するための組織内のプロセスやコントロールが定められています。コンプライアンスフレームワークは体系化された要件を提供しますが、組織は固有のセキュリティニーズやリスク許容度に基づいて、追加のコントロールやオプションのコントロールを実装することもできます。AWS Config を使用してコントロールを継続的に監査する場合は、影響度を分類し、デプロイ戦略を検討することが重要です。IDE や CI/CD パイプラインにランタイムバージョンの開発・デプロイのコントロールがある場合は、AWS Config のランタイム評価で取り組みを重複させるのではなく、既存のコントロールを使用することをお勧めします。同様に、ニアリアルタイムでアクションを実行するイベントベースのアーキテクチャがある場合は、重要な変更の即時検出と対応を確実に行うために、定期的記録ではなく継続的記録を使用することをお勧めします。

前述の分析に基づくと、短命なリソースについて記録頻度を比較した結果 (表 1) から、AWS Lambda 関数における一時性の影響がわかります。AWS Lambda 関数をアドホックに作成・削除しており、かつ IDE や CI/CD にコントロールがある場合、内部監査のための継続的記録は開発者にとってノイズになる可能性があります。組織内コントロールごとに影響を評価し、記録が 24 時間ごとの定期的記録に設定されているにもかかわらず 8 時間ごとにルールをトリガーしてしまわないよう、ルールを記録頻度に合わせる必要があります。

ベストプラクティス: 環境を影響度のレベルで分類し、開発者により近いコントロールを検討したうえで、そのギャップを埋めるために AWS Config の活用を検討してください。

まとめ

この記事で紹介したガイダンスとベストプラクティスは、固有の運用ニーズに応じた AWS Config の記録頻度について、十分な情報に基づいた意思決定を行うのに役立ちます。3 つの重要な要素を主要なユースケースと併せて理解し、それらを固有の環境特性に適用することで、組織がクラウド運用を成功させるために必要となる設定の可視性を維持しながら、運用の効果を最適化できます。

この記事では、リソースの静的性、サービス間の関係、ベースラインの変更頻度、および主要なユースケースが CI の生成にどう影響するかを探りました。実践的な例と分析を通じて、これらの要素を体系的に評価するための意思決定のフレームワークとベストプラクティスを紹介しました。

組織にとっての意思決定に役立つベストプラクティスは以下のとおりです。

• 現在の CI のパターンを分析する
• リソースの関係に関する戦略を特定し、既存の関係と比較する
• 記録頻度をニーズに合わせる
• ルールの評価を記録頻度に合わせる
• 環境固有の要件を実装する
• アカウントと環境の分離を検討する

定期的記録を有効にする手順の詳細については、「AWS Config の定期的な記録を使用した設定項目の検出」を参照してください。

著者について

翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文はこちらです。