Amazon Config のよくある質問

AWS Config を開始するには、AWS マネジメントコンソールを使用するのが最も簡単です。数回の選択で AWS Config を有効にできます。詳細については、「ご利用開始にあたって」をご覧ください。

AWS マネジメントコンソール、AWS コマンドラインインターフェイス、SDK を使用して現在および過去のリソース設定を確認できます。

より詳しい情報は、「AWS Config ドキュメント」を参照してください。

アカウント内のリージョンごとに、AWS Config を有効にできます。

はい。適切な IAM ポリシーを Amazon S3 バケットに適用すれば、異なるアカウントから 1 つの Amazon Simple Storage Service (S3) バケットに設定更新の情報を集めるように AWS Config を設定できます。また、適切な IAM ポリシーを 1 つの SNS トピックに適用すれば、その同じリージョンの SNS トピックに通知を公開できます。

はい。AWS Config API オペレーションを使用した設定データの読み込みなど、AWS Config API のすべてのアクティビティは CloudTrail によって記録されます。

AWS Config には、タイムラインのリソースに対して設定項目 (CI) が記録された時間が表示されます。すべての時間は協定世界時 (UTC) で記録されます。マネジメントコンソールでタイムラインを表示すると、現在のタイムゾーン (該当する場合、サマータイムに合わせて調整) が使用され、記録されているすべての時間がタイムラインビューで表示されます。

設定項目 (CI) とは、特定時点でのリソースの設定です。CI は次の 5 つのセクションで構成されています。

異なるリソースタイプでも共通な基本情報 (Amazon リソース名、タグなど)、

リソースに特有な設定データ (EC2 インスタンスタイプなど)、

他のリソースとの相関関係 (EC2::Volume vol-3434df43 などは EC2 instance i-3432ee3a に「アタッチされています」)、

このステータスに関連する CloudTrail イベント ID (AWS リソースのみ)

CI のバージョン、CI がキャプチャされた時間など、その CI についての情報が特定できるメタデータ。

設定項目の詳細

カスタムの設定項目 (CI) は、サードパーティーまたはカスタムのリソースのための CI です。オンプレミスのデータベース、アクティブディレクトリサーバー、GitHub のようなバージョン管理システム、Datadog のようなサードパーティーのモニタリングツールなどがその例です。

AWS Config は変更を記録する際にリソース同士の関連性を考慮します。たとえば、新しい EC2 セキュリティグループが EC2 インスタンスに関連付けられている場合、AWS Config ではプライマリリソースとEC2 セキュリティグループの両方、および関連リソース (これらのリソースが変更された場合) の構成の更新を記録します。

AWS Config では、リソースの設定の変更を検出し、その変更によってもたらされた設定状態を記録します。リソースに対していくつかの設定変更が立て続けに行われた場合、AWS Config では、そのリソースへの変更全体の累積的影響を表す最新の設定のみが記録されます。このような状況では、AWS Config は設定項目の relatedEvents フィールドに最新の変更点のみをリストアップします。これにより、ユーザーやプログラムは、AWS Config が中間的な過渡状態を記録するのを待つことなく、インフラストラクチャの構成を変更し続けることができます。

定期的に記録することで、環境内の変更を記録する頻度を決定できるため、頻繁に変更されるリソースから設定項目を減らすことができます。更新を継続的に受け取る代わりに、定期的な記録を使用して、ユースケースに合わせて 24 時間ごとに設定の変更を受け取ることもできます。 

定期的に記録することで、リソース設定の更新を受信する頻度を決定できます。有効にすると、AWS Config はリソースの最新の設定が変更された場合、24 時間の期間の終了時にのみ配信します。これにより、設定データの頻度が減り、運用計画や監査などのユースケースでこのデータを収集するコストを予測しやすくなります。セキュリティとコンプライアンスのニーズにより、リソースを継続的に監視する必要がある場合は、継続的な記録を使用する必要があります。

はい。AWS Config では、まだ記録されていない変更がないかリソースの設定を定期的にスキャンし、そのような変更を記録します。このようなスキャンによって記録された CI のメッセージには、[relatedEvent] フィールドがありません。記録済みの状態とは異なる最新の状態のみが選択されています。

はい。AWS Config では、AWS アカウント内の EC2 インスタンス内に加え、オンプレミス環境の仮想マシン (VM) やサーバー内のソフトウェアに対する設定変更を記録できます。AWS Config で記録される設定情報には、オペレーティングシステム更新、ネットワーク設定、インストール済みのアプリケーションがあります。AWS Config ルールを使用して、インスタンス、VM、およびサーバーがガイドラインに従っているかどうかを評価できます。AWS Config が提供する詳細までの可視性と連続的モニタリング機能によって、コンプライアンスを評価し、運用上の問題をトラブルシューティングできます。

AWS Config は、コンプライアンス状況に変化があったときにのみ通知を送信します。以前にコンプライアンス違反であったリソースが依然としてコンプライアンス違反である場合、AWS Config は新しい通知を送信しません。コンプライアンス状況が「コンプライアンス遵守」に変化した場合、状況変化の通知がお客様に届きます。

はい。コンソールの AWS Config の「レコーダー設定」ページに移動し、[Exclude Resource Types (リソースタイプを除外)] オプションを選択し、必要な除外を指定することで、リソースを除外できます。あるいは、PutConfigurationRecorder API を利用してこの機能にアクセスすることもできます。この API は、そのリソースタイプの設定記録を無効にします。また、AWS Config ルールを構成するとき、指定されたリソースタイプ、または特定のタグが付いたリソースに対してルールが評価を実行するかどうかを指定できます。

リソースの設定は、AWS Config の設定項目 (CI) に含まれるデータによって定義されるものです。AWS Config ルールを最初にリリースするときに、リソースの CI に関連するルールが利用可能になります。AWS Config ルールはこの情報と、アタッチされたその他のリソース、営業時間など、関連するすべての情報を使用し、リソース設定のコンプライアンスを評価します。

ルールとはリソースの設定項目 (CI) の理想的な属性値であり、これらの属性値と AWS Config によって報告された CI を比較することによって評価されます。ルールには以下の 2 種類があります。

AWS のマネージドルール: AWS のマネージドルールは、AWS によって事前にビルドおよび管理されます。有効にするルールを選択し、いくつかの設定パラメータを入力すれば開始できます。詳細 »

お客様が管理するルール: お客様が管理するルールは、お客様自身で定義し、作成します。カスタムルールの一部として呼び出すことができる関数を AWS Lambda で作成し、これらの関数はアカウントに適用されます。詳細 »

AWS Config を開始するには、AWS マネジメントコンソールを使用するのが最も簡単です。数回の選択で AWS Config を有効にできます。詳細については、「ご利用開始にあたって」をご覧ください。

ルールは基本的に AWS アカウント管理者が設定します。ルールは AWS のマネージドルール (AWS が提供する事前定義のルール) を活用して、またはお客様が管理するルールによって作成できます。AWS のマネージドルールの場合、そのルールを使用するアカウントに対して自動的にルールの更新が適用されます。お客様が管理するモデルでは、お客様がルールの完全なコピーを持ち、自身のアカウントに対してルールを適用します。ルールはお客様が保守します。

デフォルトでは、AWS アカウントに最大 150 個のルールを作成できます。また、AWS サービスの制限ページから、アカウントのルール数の制限の引き上げをリクエストできます。

すべてのルールが変更によってトリガーされるルールとして、または定期的に実行されるルールとして設定できます。変更によってトリガーされるルールは、AWS Config が指定されたいずれかのリソースの設定変更を記録すると適用されます。さらに、以下のうち 1 つを指定する必要があります。

タグキー (および任意の値): 指定したタグキーと値でリソースに対する設定変更が記録されると、ルールによる評価が開始されます。

リソースタイプ (複数可): 指定したリソースタイプでリソースに対する設定変更が記録されると、ルールの評価が開始されます。

リソース ID: 指定したリソースタイプおよびリソース ID でリソースに対する設定変更が記録されると、ルールによる評価が開始されます。

定期的に実行されるルールは特定の頻度で開始されます。使用可能な頻度は、1 時間、3 時間、6 時間、12 時間、または 24 時間です。定期的に実行されるルールの場合、ルールに公開されているすべてのリソースの現在の設定項目 (CI) に対する完全なスナップショットが使用されます。

ルールによる評価によって、特定時点でルールとリソースが一致しているかどうかが判断されます。これは、ルールをリソースの設定と比較して評価した結果です。AWS Config ルールは各評価を取得し、保存します。結果にはリソース、ルール、評価が実行された時間、コンプライアンス違反の原因となった設定項目 (CI) へのリンクが含まれます。

リソースは、そのリソースに適用されるすべてのルールに従っている場合は準拠しています。それ以外の場合は、非準拠です。同様に、あるルールによって評価したすべてのリソースがルールに従っている場合、そのルールはコンプライアンスを遵守していることになります。それ以外の場合は、非準拠です。ルールの権限が不足している場合などでは、リソースに対する評価が実行されず、データ不足のステータスとなる場合があります。このステータスはリソースまたはルールのコンプライアンス状況の判断材料から除外されます。

AWS Config ルールのダッシュボードには AWS Config によって追跡されたリソースの概要と、リソースおよびルールごとの現在のコンプライアンス状況のサマリが表示されます。リソースごとにコンプライアンス状態を確認すると、そのリソースに適用されているルールの中に現在コンプライアンス違反があるかどうかが判断できます。ルールごとにコンプライアンス状態を確認すると、ルールが適用されているリソースの中に現在コンプライアンス違反があるかどうかが判断できます。このサマリビューを使用すると、リソースの AWS Config タイムラインをさらに詳しく調べて、どの設定パラメータが変更されたかを判断できます。ダッシュボードを使用すれば概要から開始してより詳細なビューに移動し、コンプライアンス状況の変化について、またどの変更がコンプライアンス違反の原因となったかについて完全な情報を取得できます。

各 AWS Config ルールは、1 つまたは複数のアカウントのリソース設定のコンプライアンス状態を評価するために使用できます。コンフォーマンスパックは、1 つの選択で組織全体にわたりデプロイできる 1 つのエンティティとして、修復操作とともにルールをパッケージ化するという別のメリットを提供します。コンフォーマンスパックは、複数アカウントを管理している場合に、大規模なコンプライアンス管理とレポーティングを簡素化することを意図したものです。コンフォーマンスパックは、パックレベルで集計されたコンプライアンスレポートと不変性を提供するように設計されています。これにより、コンフォーマンスパック内の管理された AWS Config ルールと修復ドキュメントが、組織の個々のメンバーアカウントによって変更または削除されるのを防ぐことができます。

AWS Security Hub は、セキュリティおよびコンプライアンス体制の管理をサービスとして提供するセキュリティおよびコンプライアンスサービスです。AWS リソースの設定を評価するための主なメカニズムとして AWS Config と AWS Config ルールを使用します。AWS Config ルールは、リソースの設定を直接評価するためにも使用できます。AWS Config ルールは、AWS Control Tower や AWS Firewall Manager などの他の AWS のサービスでも使用されます。

PCI DSS などのコンプライアンス標準が既に Security Hub に存在する場合、それを運用するための最も簡単な方法として、フルマネージド型の Security Hub サービスを挙げることができます。Security Hub の Amazon Detective との統合を通じて検出結果を調査できるほか、Security Hub の Amazon EventBridge との統合を使用して、自動または半自動の修正アクションを構築できます。ただし、セキュリティ、運用、およびコスト最適化チェックが含まれる場合がある独自のコンプライアンスまたはセキュリティ標準を組み合わせるには、AWS Config コンフォーマンスパックが最適です。AWS Config コンフォーマンスパックは、AWS Config ルールのグループと、関連する是正アクションを単一のエンティティにパッケージ化することによって、AWS Config ルールの管理をシンプル化します。このパッケージ化により、組織全体でのルールのデプロイと修正アクションが簡素化されます。また、コンプライアンスの概要をパッケージレベルで報告できるため、集約された報告も可能になります。AWS が提供する AWS Config コンフォーマンスパックのサンプルから始めて、必要に応じてカスタマイズできます。

はい、Security Hub と AWS Config の両方のコンフォーマンスパックは、AWS Config と AWS Config ルールへの依存を前提として、継続的なコンプライアンス監視をサポートしています。基盤となる AWS Config ルールは、定期的に、またはリソースの設定に対する変更を検知したときにトリガーできます。これにより、AWS リソースの設定と企業ポリシーおよびガイドラインとの全体的なコンプライアンスを継続的に監査および評価できます。

CLI または AWS Config コンソールからサンプルテンプレートを使用してコンフォーマンスパックを作成するのが一番簡単です。サンプルテンプレートには、S3 Operational Best Practices、Amazon DynamoDB Operational Best Practices、および Operational Best Practices for PCI を含むものがあります。これらのテンプレートは YAML で記述されています。これらのテンプレートは、ドキュメントサイトからダウンロードし、任意のテキストエディタを使用してユーザーの環境に合わせて編集できます。パック内に以前に記述したカスタムの AWS Config ルールを追加することもできます。

コンフォーマンスパックには階層化された料金モデルが適用されます。詳細については、AWS Config の料金ページをご参照ください。

AWS Config のデータ集約機能では、複数のアカウントやリージョンの AWS Config データを単一のアカウントやリージョンに集約できます。マルチアカウントのデータ集約は、中央の IT 管理者がエンタープライズ内にある複数の AWS アカウントのコンプライアンスをモニタリングするのに便利です。

データ集約機能を使って複数アカウントにルールをプロビジョニングすることはできません。これは純粋に、コンプライアンスの可視性を実現するレポート機能です。複数のアカウントやリージョンにルールをプロビジョニングする場合は、AWS CloudFormation StackSets を使用できます。詳細については、この「ブログリンク」をご覧ください。

AWS Config および AWS Config Rules が自分のアカウントと集約対照のアカウントで有効化されると、アカウントにアグリゲータを作成してデータ集約を有効化できます。詳細をご覧ください。

アグリゲータは AWS Config のリソースタイプで、複数のアカウントやリージョンから AWS Config データを収集します。アグリゲータを使用して、複数のアカウントやリージョンについて AWS Config に記録されたリソース設定とコンプライアンスデータレコードを表示できます。

集計ビューには、組織全体でのルール違反合計数、違反リソース数の多いルールのトップ 5、ルール違反の多い AWS アカウントのトップ 5 が表示されます。これによりルールに違反しているリソースについての詳細を見、あるアカウントが違反しているルールのリストを見ることができます。

ファイルのアップロードまたは各アカウントの個別入力によって、AWS Config データの集約対象アカウントを指定できます。AWS Organization に属していないアカウントでは、アカウントそれぞれに対してアグリゲータアカウントを明示的に承認する必要があることに注意してください。詳細をご覧ください。

データ集約機能はマルチリージョンの集約にも役立ちます。そのため、この機能を使えば、複数リージョンにまたがるアカウントの AWS Config データを集約できます。

マルチアカウント、マルチリージョンのデータ集約が可能なリージョンの詳細については、AWS Config デベロッパーガイド:「マルチアカウントマルチリージョンデータ集約」をご覧ください。

アグリゲータを作成するときには、データの集約対象となるリージョンを指定します。リストには、この機能が利用できるリージョンのみ表示されます。[all regions] を選択することもできます。この場合、その他のリージョンがデータの集約に対応すると、自動的にデータが集計されます。

サポートされているリソースタイプの完全なリストは、こちらの「ドキュメント」を参照してください。

AWS Config が利用可能な AWS リージョンの詳細については、AWS リージョン表をご覧ください。

AWS Config では、アカウントの記録された設定項目の数、アクティブな AWS Config ルールの評価数、コンフォーマンスパックの評価数に基づいて課金されます。設定項目は、AWS アカウントのリソースの設定状態を記録したものです。AWS Config が設定項目を配信できる頻度には、継続的と定期的の 2 つがあります。継続的な記録により、変更が発生するたびに設定の変更が記録され、配信されます。定期的な記録により、変更が発生した場合にのみ、24 時間に 1 回設定データが配信されます。AWS Config ルール評価は、AWS アカウントのAWS Config ルールによるリソースのコンプライアンス状態の評価です。コンフォーマンスパック評価とは、コンフォーマンスパック内の AWS Config ルールによるリソースの評価です。詳細については、「https://aws.amazon.com/config/pricing/」をご参照ください。

お客様は AWS が提供する一連のマネージドルールから選択するか、Lambda 関数で独自のルールを作成できます。マネージドルールは AWS によって完全に管理され、ルールを実行するために追加の Lambda 利用料は発生しません。マネージドルールを有効にし、必要なパラメータを入力し、それぞれのアクティブな AWS Config ルールの単一月額料金を支払うことができます。カスタムルールを使用すると、使用中のアカウント内の Lambda 関数として適用され、そのすべてをお客様がコントロールできます。カスタム AWS Config ルールには、アクティブなルールに対する月額料金に加えて、通常の Lambda 無料利用枠* および関数適用料金が適用されます。

*AWS 無料利用枠は、AWS 中国 (北京) リージョンまたは AWS 中国 (寧夏) リージョンではご利用いただけません。

新しいルールを作成し、アクティブになるたびに料金が発生します。ルールに関連付けられた Lambda 関数の更新または置き換えが必要な場合は、ルールを削除して新しいルールを作成するのではなく、ルールを更新することをお勧めします。

Splunk、ServiceNow、Evident.io、CloudCheckr、Redseal、RedHat CloudForms などの APN パートナーソリューションは、AWS Config のデータと完全に統合されたサービスを提供しています。2nd Watch や Cloudnexa といったマネージドサービスプロバイダーも AWS Config との統合を発表しました。さらに、AWS Config ルールを使用して、CloudHealth Technologies、AlertLogic、および TrendMicro といったパートナーが利用可能な統合サービスを提供しています。これらのソリューションでは変更管理、セキュリティ分析などが利用でき、AWS リソースの設定を視覚化、モニタリング、管理するのに役立ちます。