Amazon Web Services ブログ
AWS Control Tower 環境での AWS Config リソーストラッキングのカスタマイズ
[2023 年 7 月 26 日更新] AWS Config は最近、リソースタイプ別の記録の例外 に対応しました。この変更の前は、すべてのリソースタイプを明示的に設定する必要がありました。このブログはその変更を取り入れ、運用管理を容易にするように更新されました。
AWS の最大規模のお客様の中には、AWS Control Tower を使用して、複数アカウントの AWS 環境を管理・保護している方もいらっしゃいます。AWS Control Tower は、アカウント登録時に AWS Config を有効化し、セキュリティのベストプラクティスを実装しています。これにより、サポートされているすべての AWS リソースがモニタリングされます。
すべてのリソースをモニタリングすると、必要のないリソースのアクティビティも記録されてしまうという声を一部のお客様からいただくことがあります。本番環境において、コンプライアンス目的で必要な情報を記録することは多くのお客様にとって重要です。しかし、開発環境やステージング環境では本番環境ほど詳細にログを記録する必要はないかもしれません。その場合、記録対象から不要なリソースをフィルタリングすることは、対策となるうえに AWS Config のコストを抑えることにもつながります。
AWS Config の料金は、記録された設定項目数、ルールの評価数、コンプライアンスパックの評価数に基づいて決定します。
詳細は、AWS Config の料金を参照してください。
AWS Control Tower で管理されているリソースを直接更新した場合、ランディングゾーンのドリフトが発生する可能性があります。このドリフトは、将来の AWS Control Tower のサービス更新と競合したり、アカウント管理操作のブロッカーとなる可能性があります。
したがって、個々のアカウント内の AWS Config など、AWS Control Tower で管理されているリソースを直接更新することはおすすめしません。
この記事では、アカウントの更新や作成の際に影響を与えることなく、既存の AWS Config サービスを変更するソリューションについて説明します。
先ほど述べたように、ビジネス上の必要性やメリットがない場合、一部のお客様は特定のリソースタイプの記録を AWS Config から除外することがあります。AWS Config ルールと AWS Security Hub は、AWS Config によるリソースの記録に依存しています。したがって、AWS Config レコーダーから特定のリソースタイプを除外する前に、記録しない場合の影響を理解することが不可欠です。
このソリューションをデプロイする前に、AWS Config の料金について理解し、このソリューションが要件を満たすのに役立つか確認する必要があります。これから紹介するステップ 1 と 2 を参照してください:
- AWS Config のコストについてより深く理解する
- このソリューションをデプロイして、環境内で重要だと考えているリソースのセットに記録を限定する
AWS Config のコスト理解
コストについて理解する第一歩は、多くの場合、AWS Cost Explorer の確認となります。まず、ここから始めましょう。AWS Cost Explorer の右側にあるフィルターを設定して、AWS Config サービスのみが表示されるようにします。また、ディメンションから「使用タイプ」を選択し、「使用タイプ」でグループ化されるようにします。
下図の例で示すテストアカウントでは、必要な 20 個の代わりに 2000 個以上の Amazon Simple Queue Service(SQS) キューが作成されるという誤った設定をシミュレーションしました。
図 1 では時刻の粒度を日別にしたときに、5 月 9 日に AWS Config のコストが急上昇したのがわかります。実際のドル値のスケールは説明目的で小さくしています。使用タイプでグループ化すると、us-west-2 リージョンの ConfigurationItemRecorded が主な原因であることがわかります。
図 1: 使用タイプ別にグループ化した結果
さらに「連結アカウント」としてグループ化することで、確認のために選択したアカウントのうちどれがコストに影響を及ぼしているかを理解できます。図 2 では、5 月 9 日と 10 日に AWS Config のコストが突然スパイクしたのは、raovi-2021-aft アカウントが起因だったことがわかります。
図 2: 連結アカウントでグループ化した結果
最後に、個々のアカウントにログインし、AWS Config のコンソールよりダッシュボードを表示して、記録された設定項目のメトリクスを確認してください。コスト上昇を引き起こしているリソースタイプを把握するために、リソースタイプフィルタを適用することもできます。
図 3 のシミュレーション例は、2000 件を超える AWS Config 項目が突然記録されたスパイクを示しています。これにより、ConfigurationItemRecorded コストが増加しました。
図 3: マネジメントコンソールにおける AWS Config 使用状況メトリクス
図 4: AWS Config 使用状況メトリクスのリソースタイプを使ったフィルター
マネジメントコンソールから AWS Config のダッシュボードに遷移し、AWS Config 使用状況メトリクスを確認すると、これらのメトリクスをリソースタイプでさらにフィルタリングできます。
ソリューションの概要
このソリューションは、AWS Control Tower の管理アカウントのホームリージョンにデプロイしてください。このソリューションでは各管理対象アカウントの AWSControlTowerExecution ロールを利用して、すべての AWS Control Tower 管理リージョンの AWS Config レコーダーのリソースタイプを更新します。AWS Control Tower は、アカウント作成プロセス中にこのロールを作成します。ソリューションで提供している AWS CloudFormation テンプレートのデフォルト値は、いくつかのサンプルリソースを AWS Config の記録対象から除外する設定にしています。パラメータはソリューションをデプロイする際にお客様のユースケースに応じて更新できます。
図 5: ソリューション概要
このソリューションは、ランディングゾーンの更新やアカウントの管理など、特定の管理操作に対して AWS Control Tower が生成するライフサイクルイベントを利用します。
- Amazon Event Bridge のルールが作成され、
UpdateLandingZone、CreateManagedAccount、UpdateManagedAccountのイベントが発生した際に、Producer Lambda 関数が起動します。 - AWS Lambda の Producer 関数は、AWS Control Tower によって作成された AWS CloudFormation スタックセットをクエリすることで、AWS Config レコーダーがデプロイされているすべてのアカウント ID とリージョンのリストを取得します。
- 次に AWS Lambda の Producer 関数は、アカウント ID とリージョンのリストを Amazon SQS キューに送信します。
- Amazon SQS キュー内の各メッセージが AWS Lambda の Consumer 関数を呼び出します。
- AWS Lambda の Consumer 関数はメンバーアカウント内で
AWSControlTowerExecutionロールを引き受け、デプロイ時に指定した入力パラメータに従って AWS Config レコーダーを更新します。
CreateManagedAccount と UpdateManagedAccount の 2 つのイベントについては、AWS Lambda の Producer 関数が、特定のアカウント ID の AWS Config レコーダーをデプロイするために AWS CloudFormation スタックセットを使用しているリージョンのリストを取得します。これにより、不要なリソースの使用が回避され、コストが最小限に抑えられます。
デプロイ手順
Git リポジトリをクローンするか、template.yml ファイルをダウンロードしてください。Git リポジトリからダウンロードした template.yml ファイルを使用して、AWS Control Tower 管理アカウントのホームリージョンで AWS CloudFormation スタックを作成します。2 つのパラメータが提示されるので、1 つずつ見ていきましょう。
- ConfigRecorderExcludedResourceTypes パラメータは、記録対象から除外する必要があるすべての AWS Config リソースタイプのリストです。リストがお客様のユースケースにマッチしていること、コンマ区切りの正しいフォーマットになっていること確認してください。
- ExcludedAccounts パラメータは、変更を除外の対象外とする AWS アカウントのリストです。AWS Control Tower の管理アカウント、ログアーカイブアカウントおよび監査アカウントのアカウント ID を置き換えてください。任意でこのソリューションから除外するその他の AWS アカウント ID を追加してください。
パラメータを指定した後、スタックを作成し、スタックのデプロイが成功するのを待ちます。スタックのステータスが CREATE_COMPLETE になると、ソリューションが 1 回実行されます。AWS Lambda の Producer 関数の 1 回の呼び出しと、AWS Lambda の Consumer 関数が数回呼び出されていることを確認してください。
検証
AWS Config レコーダーの変更を確認するには、リンクされた各アカウントにログインし、マネジメントコンソールから AWS Config の設定からリソースタイプを確認してください。リソースタイプのリストは、スタック作成時に入力した AWS CloudFormation パラメータ ConfigRecorderResourceTypes と一致する必要があります。
図 6: AWS Config 設定画面
さらに、使用状況メトリクスから記録された設定項目を確認することができます。この場合、除外している項目のカウントは 0 になります。
クリーンアップ
このソリューションをクリーンアップするには、上記のデプロイ手順で作成した AWS CloudFormation スタックを削除してください。
クリーンアップするまで、AWS Cloudformation テンプレートのConfigRecorderExcludedResourceTypesパラメータで指定したリソースは AWS Config に記録されません。
まとめ
本ブログでは、AWS Config のコスト上昇を特定する方法を学びました。
さらに、ビジネス価値をもたらさないリソースタイプの記録を除外する方法も学びました。
この方法により、既存の AWS Control Tower の設定、将来のランディングゾーンの更新、およびアカウント管理機能への影響を回避できます。
AWS Control Tower と AWS Config を実践的に体験していただくには、AWS Control Tower ワークショップをお試しください。
著者: