翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # クロスアカウントクロスリージョンログの一元化 Amazon CloudWatch Logs データ一元化は と連携して AWS Organizations 、クロスアカウントおよびクロスリージョン一元化ルールを使用して、複数のメンバーアカウントから 1 つのデータリポジトリにログデータを収集します。複数のアカウントおよび AWS リージョン から組織内の一元化されたアカウントにログデータを自動的にレプリケートするルールを定義します。この機能により、ログの統合が効率化され、 AWS インフラストラクチャ全体の一元的なモニタリング、分析、コンプライアンスが向上します。 CloudWatch Logs データ一元化は、障害耐性を高めるために、送信先アカウント内でのルール設定中にバックアップリージョンを設定する機能など、運用上およびセキュリティ上の要件を満たすための設定の柔軟性を提供します。さらに、元々カスタマーマネージド KMS キーで暗号化されたデータを処理するために、ソースアカウントからコピーされたロググループの暗号化動作を完全に制御できます。 **注記** CloudWatch Logs の一元化機能は、一元化ルールの作成後にソースアカウントに到着した新しいログデータのみを処理します。履歴ログデータ (ルールの作成前に存在していたログ) は一元化されません。 ## データ一元化の概念 CloudWatch Logs データ一元化の使用を開始する前に、以下の概念を理解してください。 **一元化ルール** ソースアカウントとリージョンからのログデータを送信先アカウントとリージョンにレプリケートする方法を定義する設定。ルールは、ソース条件と送信先設定を指定します。 **ソースアカウント** ログデータの送信元の AWS アカウント。ソースアカウントからのログイベントは、定義した一元化ルールに基づいて送信先アカウントにレプリケートされます。 **送信先アカウント** レプリケートされたログデータが保存される送信先 AWS アカウント。このアカウントは、ログの分析とモニタリングのための一元的な場所として機能します。 **バックアップリージョン** 障害耐性とディザスタリカバリの目的でログデータをレプリケートできる、送信先アカウント内のオプションのセカンダリリージョン。 **CloudWatch Logs での暗号化 ** ロググループのデータは常に CloudWatch Logs で暗号化されます。デフォルトでは、CloudWatch Logs は 256 ビットの Advanced Encryption Standard Galois/Counter Mode (AES-GCM) によるサーバー側の暗号化を使用して、保管中のログデータを暗号化します。別の方法として、この暗号化に AWS Key Management Service を使用することもできます。詳細については、[CloudWatch Logs Encryption ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)」を参照してください。 + **一元化中の暗号化の仕組み**: CloudWatch Logs の一元化は、取り込み時にログデータをソースアカウントから宛先アカウントにアクティブにコピーします。このプロセス中、データは AWS 所有のサービスキーを使用して転送中に暗号化されたままになります。ソースロググループと宛先ロググループの保管中のデータは、選択した暗号化方法 (カスタマー管理または AWS 所有の KMS キー) を使用して暗号化されます。送信先ロググループでカスタマーマネージド KMS キーを使用している場合は、一元化サービスがアクセスできるように kms `LogsManaged = true` キーに タグを追加します。 + **KMS アクセス許可が必要な場合**: + ソースアカウントでカスタマーマネージド KMS キーを使用している場合、CloudWatch Logs では次のシナリオ例で [KMS アクセス許可](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html#cmk-permissions-lg)が必要です。 + **スループット管理**: 一元化スループット制限に達すると、帯域幅が利用可能になるまで、ログデータはカスタマーマネージド KMS キーで暗号化されて一時的に保存されます。 + **データ保護と秘匿化**: ソースロググループでデータ保護ポリシーが有効になっている場合、CloudWatch Logs は raw ログデータにアクセスして一元化するための復号アクセス許可を必要とします。 一元化ルールは、 AWS Organizations 管理アカウントまたは委任された管理者によって管理されます。カスタマーマネージド KMS で暗号化されたロググループを一元化から除外するには、ルール設定を「KMS AWS キーで暗号化されたロググループを一元化しないでください」に設定します。 ## ログの一元化の設定 CloudWatch Logs Centralization を設定するには、ソースアカウントのロググループから送信先アカウントのロググループへのログデータのフローを定義する一元化ルールを設定する必要があります。 一元化ルールが有効になり、ログイベントが送信先アカウントにレプリケートされたら、強化されたフィルタリング機能を使用して、一元化されたロググループにメトリクス、サブスクリプション、アカウントフィルターを作成できます。これらのフィルターは、特定のソースアカウントとリージョンからのログイベントをターゲットにすることができ、ソースアカウントとリージョンの情報をメトリクスディメンションとして出力できます。詳細については、「[フィルターを使用したログイベントからのメトリクスの作成](MonitoringLogData.md)」を参照してください。 ### 前提条件 + AWS Organizations をセットアップする必要があり、送信元アカウントと送信先アカウントの両方が組織に属している必要があります。 + ログデータへのアクセスを提供するには、CloudWatch、管理アカウント、送信先アカウントに対して信頼されたアクセスを有効にする必要があります。 **注記** コンソールを使用して信頼されたアクセスを有効にすることをお勧めします。これにより、必要なサービスにリンクされたロール (SLR) が自動的に作成されます。信頼されたアクセスが他の方法で有効になっている場合は、サービスにリンクされたロールを個別に作成する必要があります。 ### 送信先ロググループ名をカスタマイズする 一元化ルールを作成するときに、属性を使用して送信先ロググループ名の構成方法をカスタマイズできます。これらの属性は、ロググループの作成時に自動的に実際の値に置き換えられるため、送信先アカウントでログを階層的に整理できます。デフォルトでは、 `${source.logGroup}` 属性のみが使用され、送信先アカウントの同じ名前のすべてのロググループがマージされます。変数を解決できない場合は、階層内の親変数から値を継承します。 #### 使用可能な属性 送信先ロググループ名パターンでは、次の属性を使用できます。 **送信先ロググループ名の属性** | 属性 | 説明 | | --- | --- | | \$1\$1source.accountId\$1 | ログが発生した AWS アカウント ID。 | | \$1\$1source.region\$1 | ログが発生した AWS リージョン 。 | | \$1\$1source.logGroup\$1 | ソースアカウントの元のロググループ名。 | | \$1\$1source.org.id\$1 | ソースアカウントの AWS Organizations ID。 | | \$1\$1source.org.ouId\$1 | ソースアカウントの組織単位 ID | | \$1\$1source.org.rootId\$1 | 組織のルート ID | | \$1\$1source.org.path\$1 | アカウントからルートへの完全な組織パス | #### 例 元のロググループ構造を保持する パターン: `/centralized/${source.accountId}${source.logGroup}` 結果: `/centralized/123456789012/aws/lambda/my-function` アカウントとリージョン別に整理する パターン: `/centralized/${source.accountId}/${source.region}` 結果: `/centralized/123456789012/us-east-1` 組織構造別に整理する パターン: `/logs/${source.org.id}/${source.org.ouId}/${source.accountId}` 結果: `/logs/o-abc123/ou-xyz-12345678/123456789012` シンプルなフラット構造 パターン: `/centralized-logs` 結果: `/centralized-logs` #### ベストプラクティス + ソースアカウント ID を含めると、どのアカウントログの出所かを簡単に識別できます。 + 複数のリージョンから一元化する場合は、ソースリージョンを含めます。 + 構造の送信先ロググループ名は 512 文字未満にする必要があります。CloudWatch Logs では、ロググループ名の最大長は 512 文字です。 ### 一元化ルールの作成 次の手順を使用して、ソースアカウントから送信先アカウントにログデータをレプリケートする一元化ルールを作成します。 **一元化ルールを作成するには** 1. 組織の管理アカウントまたは委任管理者アカウントの CloudWatch コンソールに移動します。 1. **[設定]** を選択します。 1. **[組織]** タブに移動します。 1. **[ルールの設定]** を選択します。 1. 次のフィールドを設定してソースの詳細を指定し、**[次へ]** を選択します。 1. **一元化ルール名**: 一元化ルールの一意の名前を入力します。 1. **ソースアカウント**: テレメトリデータを一元化するアカウントを選択するソース選択基準を定義します。選択基準には以下を含むことができます。 + 組織のメンバーアカウントのリスト + 組織の組織単位のリスト + 組織全体 選択基準は 2 つのモードで指定できます。 + **ビルダー**: ソース選択基準を生成するためのクリックベースのエクスペリエンス + **エディタ**: ソース選択基準を提供する自由形式のテキストボックス ソース選択基準でサポートされている構文: + *サポートされているキー:* OrganizationId \$1 OrganizationUnitId \$1 AccountId \$1 \$1 + *サポートされている演算子:* = \$1 IN \$1 OR 1. **ソースリージョン**: 一元化するテレメトリデータを検索するリージョンのリストを選択します。 1. 次のフィールドを設定して送信先の詳細を指定し、**[次へ]** を選択します。 1. **送信先アカウント**: テレメトリデータの中央送信先として機能する組織内のアカウントを選択します。 1. **送信先リージョン**: 一元化されたテレメトリデータのコピーを保存するプライマリリージョンを選択します。 1. **バックアップリージョン**: 必要に応じて、一元化されたテレメトリデータの 2 番目のコピーを保存するリージョンを選択します。 1. 次のフィールドを設定してテレメトリデータを指定し、**[次へ]** を選択します。 1. **ロググループ**: 次のオプションのいずれかを選択します。 + **すべてのロググループ**: ソースアカウントのすべてのロググループからのログを一元化します。 + **ロググループのフィルタリング**: ソースアカウントのロググループのサブセットからのログを一元化し、選択基準を一致させます。選択基準は 2 つのモードで指定できます。 + **ビルダー**: 選択条件を生成するためのクリックベースのエクスペリエンス + **エディタ**: 選択基準を提供する自由形式のテキストボックス ログのフィルタリングに使用できる選択基準は 2 つあります。 + **ロググループの選択基準**: 一元化するソースロググループを指定する選択基準。 + *サポートされているキー:* LogGroupName \$1 \$1 + *サポートされている演算子:* = \$1 \$1= \$1 IN \$1 NOT IN \$1 AND \$1 OR \$1 LIKE \$1 NOT LIKE + **データソース選択基準**: 一元化するデータソースを指定する選択基準。 + *サポートされているキー:* DataSourceName \$1 DataSourceType + *サポートされている演算子:* = \$1 \$1= \$1 IN \$1 NOT IN \$1 AND \$1 OR \$1 LIKE \$1 NOT LIKE ロググループ選択基準とデータソース選択基準の両方を指定する場合、ログイベントを一元化するには両方の基準と一致する必要があります。 1. **KMS 暗号化ロググループ** **重要** CloudWatch 一元化ルールは、その一元化ルールで指定された KMS キーで CloudWatch Logs によるその使用が許可されていない場合、ソースアカウントから送信先ロググループにログを配信できません。送信先ロググループでカスタマーマネージド KMS キーを使用している場合は、タグ LogsManaged = true を kms キーに追加します。詳細については、「[ステップ 2: KMS キーでアクセス許可を設定する](CloudWatchLogs-Insights-Query-Encrypt.md#cmk-permissions)」を参照してください。 以下のオプションのいずれかを選択してください。 + ** 送信先固有のカスタマーマネージド KMS キーを使用してカスタマーマネージド KMS キーで暗号化されたソースロググループを一元化**する: カスタマーマネージド KMS キーで暗号化されたソースロググループからのログイベントを送信先アカウントのカスタマーマネージド KMS キーで暗号化された送信先ロググループに一元化します。 この設定を選択すると、以下も設定する必要があります。 + **送信先暗号化キー ARN**: 新しく作成された送信先ロググループに関連付ける、送信先アカウントとプライマリ送信先リージョンのカスタマーマネージド KMS キーの ARN。 + **バックアップ先暗号化キー ARN** (バックアップリージョンが選択されている場合): 新しく作成された送信先ロググループに関連付ける、送信先アカウントとバックアップ先リージョンのカスタマーマネージド KMS キーの ARN。 + **暗号化されていない送信先ロググループへの一元化をスキップする** (オプション): カスタマーマネージド KMS キーなしでロググループが既に存在する場合、CloudWatch は暗号化を更新できません。このオプションを選択すると、カスタマーマネージド KMS キーで暗号化されたソースロググループから、カスタマーマネージド KMS キーに関連付けられていない送信先ロググループへのログイベントの一元化がスキップされます。 + ** AWS 所有の KMS キーを使用して送信先アカウントのカスタマーマネージド KMS キーで暗号化されたロググループを一元化**する: カスタマーマネージド KMS キーで暗号化されたソースロググループからのログイベントを、 AWS 所有の KMS キーを使用して暗号化された新しく作成された送信先ロググループに一元化します。 + **カスタマーマネージド KMS キーで暗号化されたロググループを一元化しない**: カスタマーマネージド KMS キーで暗号化されたソースロググループからのログイベントの一元化をスキップします。 1. 一元化ルールを確認し、オプションで直前の編集を行い、**一元化ポリシーの作成**を選択します。 ### 一元化ルールの変更 既存の一元化ルールを変更するには、次の手順に従います。 **一元化ルールを変更するには** 1. 組織の管理アカウントまたは委任管理者アカウントの CloudWatch コンソールに移動します。 1. **[設定]** を選択します。 1. **[組織]** タブに移動します。 1. **[ルールの管理]** を選択します。 1. ルールを選択してから、**[編集]** を選択します。 1. 必要に応じてルール設定を更新し、**[次へ]** を選択して各ステップに進みます。 1. ステップ 4「確認して設定」で、**[一元化ポリシーの更新]** を選択します。 ### 一元化ルールの表示 既存の一元化ルールの詳細を表示するには、次の手順に従います。 **一元化ルールを表示するには** 1. 組織の管理アカウントまたは委任管理者アカウントの CloudWatch コンソールに移動します。 1. **[設定]** を選択します。 1. **[組織]** タブに移動します。 1. **[ルールの管理]** を選択します。 1. 既存のすべての一元化ルールのリストを表示し、特定のルール名を選択して詳細を表示します。 ### 一元化ルールの削除 既存の一元化ルールを削除するには、次の手順に従います。 **一元化ルールを削除するには** 1. 組織の管理アカウントまたは委任管理者アカウントの CloudWatch コンソールに移動します。 1. **[設定]** を選択します。 1. **[組織]** タブに移動します。 1. **[ルールの管理]** を選択します。 1. 削除するルールを選択し、**[削除]** を選択します。 1. 削除を確認し、**[Delete]** (削除) を選択します。 ## 一元化ルールのモニタリングとトラブルシューティング CloudWatch メトリクス、CloudWatch Logs コンソール、および AWS CloudTrail ログを使用して、一元化ルールのステータスとパフォーマンスをモニタリングできます。これにより、ログデータが正常にレプリケートされ、一元化の設定に伴う問題を特定していることを確認しやすくなります。 CloudWatch Logs は以下を提供します。 1. *一元化ルールあたりのルールの正常性* 1. **[設定]** を選択します。 1. **[組織]** タブに移動します。 1. **[ルールの管理]** を選択します。 1. *を使用して API コールをログに記録します。 AWS CloudTrail* 1. CloudWatch は、レプリケートされたログイベント、エラー、スロットリングなど、一元化のメトリクスも発行します。これらのメトリクスとそのディメンションの詳細については、「」を参照してください[一元化メトリクスとディメンション](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md#CloudWatchLogs-Centralization-Metrics)。 ### 一元化ルールのヘルスステータス 個々の一元化ルールには、正しく動作しているか否かを示すヘルスステータスがあります。ルールのヘルスは、コンソールを使用するか、API を使用してプログラムで確認できます。 ルールのヘルスステータスは次のとおりです。 + `HEALTHY`: ルールが正常に動作し、ログデータが設定どおりにレプリケートされている + `UNHEALTHY`: ルールで問題が発生し、データが正しくレプリケートされていない可能性がある + `PROVISIONING`: 組織の一元化がセットアップ中である ルールが UNHEALTHY としてマークされると、`FailureReason` フィールドには、対処する必要がある特定の問題に関する詳細が表示されます。 ### による一元化 API コールのモニタリング AWS CloudTrail AWS CloudTrail は、一元化サービスに対して行われた API コールをログに記録します。これにより、設定の変更を追跡し、 のメンバーであるアカウントの問題をトラブルシューティングできます AWS Organizations。 一元化の主な CloudTrail イベントには以下が含まれます。 + `CreateCentralizationRuleForOrganization`: 新しい一元化ルールが作成された場合 + `UpdateCentralizationRuleForOrganization`: 既存のルールが変更された場合 + `DeleteCentralizationRuleForOrganization`: ルールが削除された場合 + `GetCentralizationRuleForOrganization`: ルールの詳細が取得された場合 + `ListCentralizationRulesForOrganization`: ルールがリストされた場合 CloudTrail ログを使用して、一元化設定の変更を監査し、パフォーマンスの問題やレプリケーションの失敗にそれらを関連付けることができます。 ### モニタリングの推奨事項 一元化が正しく機能するように、CloudWatch メトリクスに供給した主要な一元化メトリクスに CloudWatch アラームを設定することをお勧めします。このプロアクティブモニタリングは、問題を早期に検出し、組織全体で信頼性の高いログの一元化を維持するのに役立ちます。 モニタリングする主なメトリクスは次のとおりです。 + `IncomingCopiedBytes`: 送信先アカウントに正常にレプリケートされるログデータの量を監視します。このメトリクスが突然低下または欠落した場合、一元化の問題を示している可能性があります。 + `CentralizationError`: 一元化プロセスでエラーが発生した場合にアラームを設定して、問題をすばやく特定して解決します。 + `CentralizationThrottled`: ログレプリケーションのパフォーマンスに影響を与える可能性のあるスロットリングイベントをモニタリングします。 利用可能な一元化メトリクスとそのディメンションの完全なリストについては、「」を参照してください[一元化メトリクスとディメンション](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md#CloudWatchLogs-Centralization-Metrics)。 ログが想定どおりに一元化されていない場合は、ログの一元化を妨げる可能性がある以下の一般的なシナリオを確認してください。 **履歴ログデータ** CloudWatch Logs の一元化機能は、一元化ルールの作成後にソースアカウントに到着した新しいログデータのみを処理します。履歴ログデータ (ルールの作成前に存在していたログ) は一元化されません。 **KMS キーのアクセス許可** 一元化ルールで指定された KMS キーが CloudWatch Logs に使用を許可していない場合、一元化ルールはソースアカウントから送信先ロググループにログを配信できません。KMS キーポリシーが CloudWatch Logs に必要なアクセス許可を付与していることを確認します。詳細については、「[ステップ 2: KMS キーでアクセス許可を設定する](CloudWatchLogs-Insights-Query-Encrypt.md#cmk-permissions)」を参照してください。 **カスタマーマネージド KMS キー設定** ルールの作成中に**カスタマーマネージド KMS キーで暗号化されたロググループを一元化しないこと**を選択した場合、カスタマーマネージド KMS キーで暗号化されたソースロググループからのログイベントはスキップされ、一元化されません。 **送信先暗号化の不一致** 送信先ロググループが、一元化ルールで指定されているものとは異なる KMS 暗号化設定で既に存在しており、競合解決が SKIP に設定されている場合、レコードは削除され、`DestinationEncryptionMismatch`エラーが発生します。たとえば、これは送信先にデフォルトの暗号化があるが、ルールでカスタマーマネージド KMS キーが指定されている場合に発生します。 **信頼されたアクセスが有効になっていない** ログデータへのアクセスを提供するには、 で CloudWatch AWS Organizations に対して信頼されたアクセスを有効にする必要があります。 **ソース選択基準** 一元化ルールのソース選択基準が正しく設定されていることを確認します。 + *アカウントとリージョン*: ログが発生するソースアカウントとリージョンがルールに含まれていることを確認します。ルールで指定されていないアカウントまたはリージョンからのロググループは一元化されません。 + *ロググループフィルター*: ロググループフィルターを設定した場合、指定された条件に一致するロググループのみが一元化されます。ロググループの選択基準に、一元化が予想されるロググループが含まれていることを確認します。 + *組織のメンバーシップ*: 送信元アカウントと送信先アカウントの両方が同じ AWS Organizations 組織に属している必要があります。組織外のアカウントは、一元化に参加できません。 **ロググループのクォータ制限に達しました** 送信先アカウントがロググループのクォータ制限に達した場合、一元化のために新しいロググループを作成することはできません。送信先アカウントに、すべての送信元アカウントの集中ロググループに対応するのに十分なクォータがあることを確認します。必要に応じて、クォータの引き上げをリクエストできます。 **ログストリーム名の長さの制限を超えました** ログストリーム名には最大長の制限があります。一元化がログストリームを送信先アカウントにレプリケートすると、ログストリーム名にサフィックスが追加されます。結果のログストリーム名が最大許容長を超えると、レコードは削除され、エラー`InvalidLogStream`がお客様のアカウントに出力されます。 **ルールのヘルスステータス** コンソールまたは `GetCentralizationRuleForOrganization` API を使用して、一元化ルールのヘルスステータスを確認します。ルールが UNHEALTHY としてマークされている場合は、問題に関する特定の詳細について `FailureReason`フィールドを確認してください。 一元化の問題を診断するには、コンソールで一元化ルールのヘルスステータスを確認し、CloudWatch メトリクスでエラーとスロットリングをチェックし、API コールの失敗の AWS CloudTrail ログを調べます。一元化メトリクスの詳細については、「」を参照してください[一元化メトリクスとディメンション](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md#CloudWatchLogs-Centralization-Metrics)。