Amazon CloudWatch Logs の一元化を使用したログ管理の簡素化

複数の AWS アカウントとリージョンにまたがるログの管理は、組織にとって常に複雑な課題でした。本番環境、開発環境、ステージング環境用の個別のアカウントやリージョンを含む AWS インフラストラクチャーが成長するにつれ、ログ管理の複雑さは指数関数的に増加します。特に時間外の重大なインシデント発生時には、チームは貴重な時間を費やして、複数のアカウントを検索し、異なるリージョン間でイベントを関連付け、複雑なログ集約システムを管理し、クロスアカウントのアクセス権限を管理しています。このような従来のログ管理アプローチは、多大なリソースを消費するだけでなく、インシデント解決を遅らせ、顧客体験に影響を与える可能性があります。このブログでは、大規模環境向けのログ管理を簡素化する方法をご紹介します。

CloudWatch Logs 一元化のご紹介

Amazon CloudWatch は複数のアカウントにわたるログのフェデレーションを通じてクロスアカウントオブザーバビリティを提供してきましたが、新しい CloudWatch Logs の一元化は根本的に異なるアプローチを採用しています。新しい CloudWatch Logs の一元化では、複数のアカウントとリージョンからのログデータを中央アカウントに統合します。この統合により、カスタムビルドの集約ソリューションの管理に関連する運用上のオーバーヘッドとコストの両方が排除され、図1 に示すように、組織のすべてのログデータに対する確実な単一の情報源が提供されます。

Figure 1:- Consolidating logs across multiple accounts and regions

図1. 複数のアカウントとリージョンにまたがるログの統

CloudWatch Logs の一元化は AWS Organizations と連携して、お客様の正確な要件に基づいてログデータを自動的に複製するルールを定義します。セキュリティ境界とコンプライアンス要件を維持しながら、何を一元化するか、どこに保存するか、どのように暗号化するかについて完全な制御が可能です。

ソリューションの手順説明

このセクションでは、このソリューションをお客様の環境に実装する方法について説明します。例えば、運用の可視性向上と迅速なインシデント対応のために、異なるリージョンで稼働している複数の本番アカウントからのログを中央アカウントに統合する必要がある場合を想定してみましょう。以下の段階的なガイドでは、ログ一元化ルールの設定方法、送信元アカウントと送信先アカウントの構成方法、および本番環境のログの一元化を開始する方法をご紹介します。

事前準備

AWS Organizations をセットアップし、送信元アカウントと送信先アカウントが組織の一部であることを確認します。
CloudWatch の信頼されたアクセスを有効にします。
1. CloudWatch コンソールに移動し、設定に進みます。
2. 図2 に示すように、組織タブで「信頼されたアクセスをオンにする」をクリックします。

Figure 2: Enabling Trusted access for CloudWatch

図2. CloudWatch の信頼されたアクセスの有効化

(オプション) 委任管理者を登録します。委任管理者は、組織内のすべてのアカウントまたは特定の組織単位（OU）に CloudWatch 機能をデプロイすることを選択できます。

ログ一元化ルールの設定

送信元アカウントから送信先アカウントにログデータを複製する一元化ルールを作成するには、以下の手順に従ってください。

組織の管理アカウントまたは委任管理者アカウントの CloudWatch コンソールに移動します。
設定を選択し、組織に移動します。
ルールを設定を選択します。
送信元の詳細を指定します。
1. ルール名を指定します（例：production-logs-central）
2. ソースアカウント をアカウントID、組織単位ID、または組織IDを選択します。
3. 図3に示すように、統合するログを選択するSource Regions を選択します。

Figure 3:- Specifying Source Details for Log Centralization

図3. ログ一元化の送信元詳細の指定

次へを選択します。
図4 に示すように、送信先アカウントと Destination Region (送信先リージョン)を選択して送信先の詳細を指定します。プライマリーリージョンで障害が発生した場合にデータの可用性を確保するため、送信先アカウント内に Backup Region を指定してログの同期コピーを保持することもできます。

Figure 4:- Specifying Destination Details for Log Centralization

図4. ログ一元化の送信先詳細の指定

次に、以下のフィールドを設定してテレメトリーデータを指定し、次へを選択します。
1. 図5 に示すように、すべてのロググループを選択するか、フィルターロググループを選択して統合したいロググループを指定します。
2. ロググループ選択基準でサポートされる構文は以下です。
  1. サポートされるキー: LogGroupName | *
  2. サポートされる演算子: = | != | IN | NOT IN | AND | OR | LIKE | NOT LIKE
3. KMS 暗号化されたロググループを処理するために、以下のオプションがあります。
  1. Centralize log groups encrypted with AWS KMS key in destination account with AWS KMS key (送信先アカウントのAWS KMSキーで暗号化されたロググループを一元化)
    1. このオプションでは、提供された送信先KMSキー ARN を使用して、送信元アカウントから送信先に暗号化されたロググループを一元化します。
    2. このオプションを選択する場合、送信先の暗号化キー ARN とバックアップ送信先の暗号化キー ARN (前のステップでバックアップリージョンを選択した場合のみ必要) を提供する必要があります。
    3. 指定されたKMSキーは CloudWatch Logs が暗号化するための権限を持っている必要があります。詳細については、「ステップ 2: KMS キーでアクセス許可を設定する」を参照してください。
  2. Centralize log groups encrypted with AWS KMS key in destination account なし AWS KMS key (AWS KMSキーで暗号化されたロググループを送信先アカウントでAWS KMSキーなしで一元化)
    1. このオプションでは、送信元アカウントの KMS 暗号化されたロググループを送信先アカウントでは暗号化せずに一元化します。
  3. Do not centralize log groups encrypted with AWS KMS key (AWS KMSキーで暗号化されたロググループを一元化しない)
    1. このオプションでは、送信元アカウントで AWS KMS 暗号化されているロググループは一元化されません。

Figure 5: Specify telemetry data for Log Centralization

図5. ログ一元化のテレメトリーデータの指定

確認と設定ページで、すべての詳細を確認し、一元化ルールの作成をクリックします。

一元化ルールが作成され有効化されると、ログイベントは中央アカウントへの統合を開始します。図6 に示すように、同じ名前のロググループはログ管理を効率化するために統合され、ログストリームには送信元アカウントIDと送信元リージョンの識別子が追加されます。さらに、ログイベントには新しいシステムフィールド (@aws.account と @aws.region ) が追加され、ログデータの出所を簡単に追跡できるようになります。

注意: CloudWatch ログ一元化機能は、一元化ルールの作成後に送信元アカウントに到着する新しいログデータのみを処理します。過去のログデータ (ルール作成前に存在していたログ) は一元化されません。

Figure 6: Centralized Logs in the destination account

図6. 送信先アカウントでの一元化されたログ

一元化ルールの健全性の監視

ルールがアクティブになると、図7 に示すようにコンソールを使用して、または GetCentralizationRuleForOrganization API を使用してプログラムで、その健全性のステータスを確認できます。

Figure 7: Monitoring centralization rule health

図7. 一元化ルールの健全性の監視

ルールの健全性ステータスには以下が含まれます。

HEALTHY (正常): ルールは正常に動作しており、設定通りにログデータを複製しています。
UNHEALTHY (異常): ルールに問題が発生しており、データが正しく複製されていない可能性があります。
PROVISIONING (プロビジョニング中): 組織の一元化が設定処理中です。

ルールが UNHEALTHY とマークされた場合、FailureReason フィールドに対処が必要な具体的な問題の詳細が表示されます。

一元化されたログを使用した統合分析

ログが一元化されると、分散ログでは不可能だった強力な分析機能が利用可能になります。@aws.account と@aws.region というシステムフィールドが追加されることで、大規模なトラブルシューティングと分析の方法が変革されます。これらのフィールドは自動的にインデックス化され、より迅速なクエリ結果の取得を支援します。以下の例では、図8に示すように、CloudWatch Logs Insights が、us-west-2 リージョンからのタイムスタンプ、アカウント、リージョン、メッセージ、ログストリーム、ロググループフィールドを表示するクエリを実行し、結果を 100 エントリに制限しています。

fields @timestamp, @aws.account, @aws.region, @message, @logStream, @log 
| filter @aws.account = 123456789012 and @aws.region = 'us-west-2'
| sort @timestamp desc
| limit 100

Figure 8: Querying using CloudWatch Log Insights

図8. CloudWatch Log Insights を使用したクエリの実行

@aws.account と @aws.region フィールドを分析に活用する方法を示す追加のサンプルクエリは以下の通りです。

アカウントとリージョン別の認証失敗の試行一覧

fields @timestamp, @aws.account, @aws.region, @message 
| filter @message like /(?i)(failed|unauthorized|denied|forbidden)/
| stats count() as failed_attempts by @aws.account, @aws.region
| sort failed_attempts desc

複数のアカウントとリージョンにわたるDBのスロークエリの分析

fields @timestamp, @message, @aws.account, @aws.region
| filter @message like /(query|database|sql)/ and @message like /(slow|timeout|duration)/
| parse @message /query.*?(?<query_duration>\d+)ms/
| parse @message /rows.*?examined[=:]?\s*(?<rows_examined>\d+)/
| parse @message /rows.*?returned[=:]?\s*(?<rows_returned>\d+)/
| parse @message /(?<query_type>SELECT|INSERT|UPDATE|DELETE)/
| parse @message /table[=:]?\s*(?<table_name>\w+)/
| filter query_duration > 1000
| stats 
    count() as slow_queries,
    avg(query_duration) as avg_duration,
    max(query_duration) as max_duration,
    avg(rows_examined) as avg_rows_examined,
    avg(rows_returned) as avg_rows_returned
    by query_type, table_name, @aws.account, @aws.region, bin(5m)
| sort max_duration desc

CloudWatch Logs 機能のベストプラクティス

CloudWatch Logs の一元化を実装する際、これらの CloudWatch 機能のベストプラクティスに従うことで、一元化されたログの価値を最大限に引き出すことができます。これらのプラクティスには、メトリクス、サブスクリプションフィルター、ログ変換、コスト最適化が含まれており、組織全体で安全で効率的、かつコスト効果の高いログ管理を確保します。

1. メトリクスとサブスクリプションフィルター

CloudWatch Logs の一元化により、メトリクスとサブスクリプションフィルターを通じて強力なデータ変換と統合機能が可能になります。組織は一元化されたログデータを数値メトリクスに変換し、グラフによる可視化とアラームベースの監視を実現できます。

例えば、アカウントやリージョンに関係なく、すべてのログに対してメトリクスフィルターを作成することができます。

aws logs put-metric-filter \
  --log-group-name /centralized/production \
  --filter-name ThrottledAPICalls \
  --filter-pattern '{ $.errorCode = "*Throttled*" }' \
  --metric-transformations \
metricName=ThrottledCalls,\
metricNamespace=CentralizedMetrics,\
metricValue=1,\
dimensions={Account=$aws.account,Region=$aws.region}

さらに、サブスクリプションフィルターを通じてリアルタイムのログイベントストリーミングを設定でき、Amazon Kinesis stream、Amazon Data Firehose stream、Amazon OpenSearch Service、AWS Lambda などの様々なサービスとシームレスに統合できます。サブスクリプションフィルターを設定する際、アカウントとリージョンのフィールドを使用して、特定のソースからのログを選択的に転送できます。ログデータにソースアカウントとリージョン情報を含めるには、図9 に示すように、システムフィールドの発行の下で @aws.account と @aws.region システムフィールドを選択して有効にします。

図9. サブスクリプションフィルターでのアカウントとリージョンフィールドのフィルタリング

2. ログの変換

CloudWatch Logs の一元化を使用する場合、送信元アカウントから中央アカウントにコピーされるのは生のログデータのみです。送信元アカウントでの取り込み時に適用されたログ変換は、一元化されたログには反映されません。組織全体で一貫したログ変換を行うために、ログが統合された後、中央アカウントで直接ログ変換を適用することを推奨します。

3. ログストレージコストの最適化

CloudWatch Logs の一元化は、複数のアカウントとリージョンにまたがるログ管理のためのコスト効率の高い価格体系を提供します。一元化されたログの最初のコピーには、追加の取り込み料金やリージョン間データ転送コストはかからず、標準的なCloudWatchのストレージコストと機能価格のみが請求されます。最初の一元化を超える追加コピーについては、1GBあたり0.05ドルの料金が発生します（バックアップリージョン機能の使用も追加コピーを作成します）。詳細については、CloudWatchの料金ページをご覧ください。CloudWatch Logs の一元化を使用する際のコストを最適化するために、以下のベストプラクティスの実施を推奨します。

1. 階層化された保持戦略の実装

2層の保持ポリシーを実装することで、ストレージコストを大幅に削減できます。

送信元アカウントには、即時の運用ニーズに対応するための短期保持期 (7-30日) を設定してください。
一元化されたアカウントには、コンプライアンス要件を満たし、履歴分析をサポートするための長期保持期間 (90日以上) を設定してください。

2. 選択的な一元化の利用

ログの追加コピーを作成する際は、以下のような戦略的な一元化アプローチを取ってください。

ロググループフィルターを活用して、特定のアプリケーションやサービスのみを一元化してください。
ビジネス要件に合致するログのみを特定し、一元化してください。
特定のユースケースに役立たない不要なログデータの一元化を避けてください。

3. バックアップ戦略

バックアップ戦略を計画する際には、以下の要因を考慮してください。

バックアップコピーは追加コピーとして扱われ、1GBあたり0.05ドルの料金が発生することに注意してください。
中央アカウントへの専用バックアップに関する特定の要件がある場合にのみ、バックアップの一元化を有効にしてください。
追加料金を排除するため、送信元アカウントをバックアップコピーとして活用することを検討してください。

これらの最適化戦略を実装することで、コストを管理しながら効果的なログ管理を維持できます。

まとめ

CloudWatch Logs の一元化は、カスタムログ集約システムの複雑さを排除するネイティブなAWSソリューションを提供することで、クロスアカウントおよびクロスリージョンのログ管理を変革します。自動レプリケーション、AWS Organizations とのシームレスな統合、クロスリージョンサポート、柔軟な暗号化オプションなどの機能により、組織は最小限のセットアップ時間で包括的なログ管理を実現できます。運用効率の向上、セキュリティ態勢の強化、インシデント解決の迅速化を通じて、即座に価値を提供します。開始するには、クロスアカウントクロスリージョンログの一元化のドキュメントをご参照ください。

本記事は、Simplifying Log Management using Amazon CloudWatch Logs Centralization を翻訳したものです。翻訳は Technical Account Manager の日平が担当しました。

Amazon Web Services ブログ