View a markdown version of this page

Terraform を使用してエンタープライズ規模で一元化されたログ記録を設定する - AWS 規範ガイダンス
概要前提条件と制限アーキテクチャツールベストプラクティスエピックトラブルシューティング関連リソース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Terraform を使用してエンタープライズ規模で一元化されたログ記録を設定する

Amazon Web Services、Aarti Rajput、Yashwant Patel、Nishtha Yadav

概要

一元化されたログ記録は、組織のクラウドインフラストラクチャにとって不可欠です。これにより、組織の運用、セキュリティ、コンプライアンスを可視化できるためです。組織が複数のアカウントにまたがって AWS 環境をスケールするにつれて、構造化ログ管理戦略は、セキュリティ運用の実行、監査要件を満たすこと、運用上の優秀性を達成するための基本となります。

このパターンは、複数の AWS アカウント および サービスからのログを一元化するためのスケーラブルで安全なフレームワークを提供し、複雑な AWS デプロイ全体でエンタープライズ規模のログ記録管理を可能にします。このソリューションは、Terraform を使用して自動化されます。Terraform は HashiCorp の Infrastructure as Code (IaC) ツールであり、一貫性のある反復可能なデプロイを保証し、手動設定を最小限に抑えます。Amazon CloudWatch Logs、Amazon Data Firehose、Amazon Simple Storage Service (Amazon S3) を組み合わせることで、以下を実現する堅牢なログ集約と分析パイプラインを実装できます。

  • での組織全体の一元化されたログ管理 AWS Organizations

  • 組み込みのセキュリティコントロールを使用した自動ログ収集

  • スケーラブルなログ処理と耐久性のあるストレージ

  • シンプルなコンプライアンスレポートと監査証跡

  • リアルタイムの運用に関するインサイトとモニタリング

このソリューションは、CloudWatch Logs を介して Amazon Elastic Kubernetes Service (Amazon EKS) コンテナ、 AWS Lambda 関数、Amazon Relational Database Service (Amazon RDS) データベースインスタンスからログを収集します。CloudWatch サブスクリプションフィルターを使用して、これらのログを専用のログ記録アカウントに自動的に転送します。Firehose は、Amazon S3 への高スループットのログストリーミングパイプラインを管理し、長期保存を可能にします。Amazon Simple Queue Service (Amazon SQS) は、オブジェクトの作成時に Amazon S3 イベント通知を受信するように設定されています。これにより、以下を含む分析サービスとの統合が可能になります。

  • ログ検索、視覚化、リアルタイム分析のための Amazon OpenSearch Service

  • SQL ベースクエリ用の Amazon Athena

  • 大規模な処理のための Amazon EMR

  • カスタム変換のための Lambda

  • ダッシュボード用の Amazon Quick Sight

すべてのデータは AWS Key Management Service (AWS KMS) を使用して暗号化され、インフラストラクチャ全体が Terraform を使用して環境間で一貫した設定でデプロイされます。

この一元的なログ記録アプローチにより、組織はセキュリティ体制を改善し、コンプライアンス要件を維持し、 AWS インフラストラクチャ全体の運用効率を最適化できます。

前提条件と制限

前提条件

アカウント AWS Control Tower、AFT、およびアプリケーションアカウントを設定する手順については、「エピック」セクションを参照してください。

必要なアカウント

の組織には、次のアカウントを含める AWS Organizations 必要があります。

  • アプリケーションアカウント – AWS のサービス (Amazon EKS、Lambda、Amazon RDS) が実行され、ログを生成する 1 つ以上のソースアカウント

  • ログアーカイブアカウント – 一元化されたログの保管と管理を行うための専用アカウント

製品バージョン

アーキテクチャ

次の図は、複数のアプリケーションアカウントから専用のログアーカイブアカウントにログを収集、処理、保存するためのスケーラブルなソリューションを提供する一 AWS 元的なログ記録アーキテクチャを示しています。このアーキテクチャは AWS のサービス、Amazon RDS、Amazon EKS、Lambda などの からのログを効率的に処理し、合理化されたプロセスを通じて Log Archive アカウントのリージョン S3 バケットにルーティングします。

複数のアプリケーションアカウントからログを収集する AWS の一元化されたログ記録アーキテクチャ。

ワークフローには 5 つのプロセスが含まれます。

  1. ログフロープロセス

    • ログフロープロセスはアプリケーションアカウントで開始されます。アプリケーションアカウントでは、一般ログ、エラーログ、監査ログ、Amazon RDS からのスロークエリログ、Amazon EKS からのコントロールプレーンログ、Lambda からの関数の実行ログとエラーログなど、さまざまなタイプのログ AWS のサービス が生成されます。

    • CloudWatch は最初の収集ポイントとして機能します。これらのログは、各アプリケーションアカウント内のロググループレベルで収集されます。

    • CloudWatch では、サブスクリプションフィルターによって、中央アカウントに転送するログを判断します。これらのフィルターを使用すると、ログ転送をきめ細かく制御できるため、正確なログパターンや完全なログストリームを指定して一元化できます。

  2. クロスアカウントログ転送

    • ログはログアーカイブアカウントに移動します。CloudWatch サブスクリプションフィルターによって、クロスアカウント転送が容易になり、リージョンコンテキストが保持されます。

    • このアーキテクチャは、さまざまなログソースを効率的に処理するために複数の並列ストリームを確立して、最適なパフォーマンスとスケーラビリティを確保します。

  3. ログアーカイブアカウントでのログ処理

    • ログアーカイブアカウントでは、Firehose が受信ログストリームを処理します。

    • 各リージョンは、必要に応じてログを変換、または強化できる専用の Firehose 配信ストリームを維持します。

    • これらの Firehose ストリームは、データ主権要件を維持するために、ソースアプリケーションアカウント (図のリージョン A) と同じリージョンにあるログアーカイブアカウントの S3 バケットに処理されたログを配信します。

  4. 通知と追加のワークフロー

    • ログが宛先の S3 バケットに到達すると、アーキテクチャは Amazon SQS を使用して通知システムを実装します。

    • リージョン SQS キューは、非同期処理を有効にし、保存されたログに基づいて追加のワークフロー、分析、またはアラートシステムをトリガーできます。

  5. AWS KMS セキュリティ用

    このアーキテクチャには、セキュリティ AWS KMS のために が組み込まれています。 は S3 バケットの暗号化キー AWS KMS を提供します。これにより、保存されているすべてのログが保存中の暗号化を維持するとともに、リージョンでの暗号化を保つことで、データレジデンシー要件を満たすことが保証されます。

ツール

AWS のサービス

  • Amazon CloudWatch は、ログ、メトリクス、イベントの形式でモニタリングおよび運用データを収集するモニタリングおよびオブザーバビリティサービスです。AWS サーバーとオンプレミスサーバーで実行される AWS リソース、アプリケーション、サービスの統合ビューを提供します。

  • CloudWatch Logs サブスクリプションフィルターは、受信ログイベントのパターンに一致し、一致するログイベントを指定された AWS リソースに配信して、さらなる処理または分析を行う式です。

  • AWS Control Tower Account Factory For Terraform (AFT) は、アカウントのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します AWS Control Tower。AFT は Terraform ベースのアカウントプロビジョニングを提供し、アカウントを管理できるようにします AWS Control Tower。

  • Amazon Data Firehose は、Amazon S3、Amazon Redshift、Amazon OpenSearch Service などの送信先にリアルタイムのストリーミングデータを配信します。これはデータのスループットに合わせて自動的に拡張し、継続的な管理作業は不要です。

  • Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes を使用してコンテナ化されたアプリケーションのデプロイ、管理、スケーリングを容易にするマネージドコンテナオーケストレーションサービスです。Kubernetes コントロールプレーンノードの可用性とスケーラビリティを自動で管理します。

  • AWS Key Management Service (AWS KMS) は、データを暗号化するための暗号化キーを作成および制御します。 は、他の と AWS KMS 統合 AWS のサービス して、これらのサービスで保存するデータを保護します。

  • AWS Lambda は、サーバーのプロビジョニングや管理をする必要なくコードを実行できるサーバーレスコンピューティングサービスです。各トリガーに応じてコードを実行することでアプリケーションを自動でスケーリングします。使用したコンピューティング時間に対してのみ料金が発生します。

  • Amazon Relational Database Service (Amazon RDS) は、クラウドでリレーショナルデータベースを簡単にセットアップし、運用し、スケーリングすることのできるマネージドリレーショナルデータベースです。時間のかかる管理タスクを自動化しながら、コスト効率が高くサイズ変更可能な容量を提供します。

  • Amazon Simple Queue Service (Amazon SQS) は、マイクロサービス、分散システム、およびサーバーレスアプリケーションの疎結合化とスケールを可能にするメッセージキューイングサービスです。メッセージ指向ミドルウェアの管理と運用の複雑さを解消します。

  • Amazon Simple Storage Service (Amazon S3) は、スケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するクラウドベースのオブジェクトストレージサービスです。ウェブ上の任意の場所から、任意の量のデータを保存および取得できます。

その他のツール

  • Terraform は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。

Code

このパターンのコードは GitHub 内の Centralized logging リポジトリで入手できます。

ベストプラクティス

エピック

タスク説明必要なスキル

AFT を使用して AWS Control Tower 環境をセットアップします。

  1. AWS Control Tower ドキュメントの指示 AWS Control Tower に従ってデプロイします。

  2. AWS Control Tower のドキュメントの指示に従い、AFT をデプロイします。

AWS 管理者

組織のリソース共有を有効にします。

  1. 管理アカウントの認証情報を使用して AWS Command Line Interface (AWS CLI) を設定します。これにより、管理のための管理アクセス許可が提供されます AWS Control Tower。

  2. 任意の で次の AWS CLI コマンドを実行します AWS リージョン。

    aws ram enable-sharing-with-aws-organization

    これにより、 AWS Resource Access Manager () をサポートするすべてのリージョン AWS Organizations で、 の組織内でリソースを共有できますAWS RAM。

AWS 管理者

アプリケーションアカウントを検証またはプロビジョニングします。

ユースケース用に新しいアプリケーションアカウントをプロビジョニングするには、AFT を介してアカウントを作成します。詳細については、 AWS Control Tower ドキュメントの「AFT を使用して新しいアカウントをプロビジョニングする」を参照してください。

AWS 管理者
タスク説明必要なスキル

Application_account フォルダの内容を aft-account-customizations リポジトリにコピーします。

  1. aft-account-customizations リポジトリのルートパスに Application_account という名前のフォルダを作成します。このリポジトリは、AFT を設定すると自動的に作成されます (前のエピックを参照)。

  2. centralised-logging-at-enterprise-scale-using-terraform リポジトリのルートディレクトリに移動し、aft/account ディレクトリの内容をコピーして、ステップ 1 で aft-account-customizations リポジトリに作成した Application_account ディレクトリに貼り付けます。

  3. centralised-logging-at-enterprise-scale-using-terraform リポジトリのルートディレクトリから、Application_account ディレクトリの内容を aft-account-customizations リポジトリの Application_account/terraform ディレクトリにコピーします。

  4. aft-account-customizations/Application_account/terraform.tfvars ファイルで、すべてのパラメータが対応する Terraform 設定ファイルに引数として渡されていることを確認します。

DevOps エンジニア

アプリケーションアカウントを設定するための入力パラメータを確認して編集します。

このステップでは、CloudWatch ロググループ、CloudWatch サブスクリプションフィルター、IAM ロールとポリシー、Amazon RDS、Amazon EKS、Lambda 関数の設定詳細など、アプリケーションアカウントにリソースを作成するための設定ファイルを設定します。

aft-account-customizations リポジトリの Application_account フォルダで、組織の要件に基づいて terraform.tfvars ファイルの入力パラメータを設定します。

  • environment: リソースがデプロイされる環境の名前 (prod、dev、staging など)。

  • account_name: リソースが作成される AWS アカウント の名前。

  • log_archive_account_id: ログがアーカイブされる AWS アカウント ID。

  • admin_role_name: リソースの管理に使用される管理ロールの名前。

  • tags: すべてのリソースに適用される一般的なタグを表すキー値ペアのマップ。

  • rds_config: Amazon RDS インスタンスの詳細設定を含むオブジェクト。

  • allowed_cidr_blocks: リソースへのアクセスが許可されている CIDR ブロックのリスト。

  • destination_name: ログがストリーミングされる CloudWatch の送信先の Amazon リソースネーム (ARN) を作成するために使用される変数。

  • rds_parameters: Amazon RDS パラメータグループ設定を含むオブジェクト。

  • vpc_config: VPC 設定の詳細を含むオブジェクト。

  • eks_config: Amazon EKS クラスターに関する設定の詳細を含むオブジェクト。

  • lambda_config: Lambda 関数に関する設定の詳細を含むオブジェクト。

  • restrictive_cidr_range: セキュリティグループルールの制限付き CIDR 範囲のリスト。

  • target_account_id: リソースがデプロイされるターゲットの Log Archive アカウントの AWS アカウント ID。

DevOps エンジニア
タスク説明必要なスキル

Log_archive_account フォルダの内容を aft-account-customizations リポジトリにコピーします。

  1. aft-account-customizations リポジトリのルートパスに Log_archive_account という名前のフォルダを作成します。このリポジトリは、AFT を設定すると自動的に作成されます。

  2. centralised-logging-at-enterprise-scale-using-terraform リポジトリのルートディレクトリに移動し、aft/account ディレクトリの内容をコピーして、前のステップで aft-account-customizations リポジトリに作成した Log_archive_account ディレクトリに貼り付けます。

  3. centralised-logging-at-enterprise-scale-using-terraform リポジトリのルートディレクトリから、Log_archive_account ディレクトリの内容を aft-account-customizations リポジトリの Log_archive_account/terraform ディレクトリにコピーします。

  4. aft-account-customizations/Log_archive_account/terraform.tfvars ファイルで、すべてのパラメータが対応する Terraform 設定ファイルに引数として渡されていることを確認します。

DevOps エンジニア

ログアーカイブアカウントを設定するための入力パラメータを確認して編集します。

このステップでは、Firehose 配信ストリーム、S3 バケット、SQS キュー、IAM ロールとポリシーなど、ログアーカイブアカウントにリソースを作成するための設定ファイルを設定します。

aft-account-customizations リポジトリの Log_archive_account フォルダで、組織の要件に基づいて terraform.tfvars ファイルの入力パラメータを設定します。

  • environment: リソースがデプロイされる環境の名前 (prod、dev、staging など)。

  • destination_name: ログがストリーミングされる CloudWatch の送信先の ARN を作成するために使用される変数。

  • source_account_ids: ログの送信先にサブスクリプションフィルターを配置できる AWS アカウント IDs のリスト。一元的なログ記録を有効にしたいアカウント ID をいくつでも入力できます。

DevOps エンジニア
タスク説明必要なスキル

オプション 1 – AFT から Terraform 設定ファイルをデプロイします。

AFT では、設定変更を含むコードを GitHub aft-account-customizations リポジトリにプッシュすると、AFT パイプラインがトリガーされます。AFT は変更を自動的に検出し、アカウントのカスタマイズプロセスを開始します。

Terraform (terraform.tfvars) ファイルに変更を加えたら、変更をコミットして aft-account-customizations リポジトリにプッシュします。

$ git add *
$ git commit -m "update message"
$ git push origin main
注記

別のブランチ (dev など) を使用している場合は、main をブランチ名に置き換えます。

DevOps エンジニア

オプション 2 – Terraform 設定ファイルを手動でデプロイします。

AFT を使用していない場合、またはソリューションを手動でデプロイする場合は、Application_account および Log_archive_account フォルダから次の Terraform コマンドを使用できます。

  1. GitHub リポジトリのクローンを作成し、terraform.tfvars ファイルの入力パラメータを設定します。

  2. 次のコマンドを実行します。

    $ terraform init

  3. 変更をプレビューします。

    $ terraform plan

    このコマンドは、Terraform 設定を評価してリソースの望ましい状態を判断し、インフラストラクチャの現在の状態と比較します。

  4. 変更を適用します。

    $ terraform apply

  5. 計画された変更を確認し、プロンプトで「yes」と入力して適用に進みます。

DevOps エンジニア
タスク説明必要なスキル

サブスクリプションフィルターを検証します。

サブスクリプションフィルターがアプリケーションアカウントのロググループからログアーカイブアカウントにログを正しく転送することを検証するには、以下の手順を実行します。

  1. アプリケーションアカウントで、CloudWatch コンソールを開きます。

  2. 左側のナビゲーションペインで、[ロググループ] をクリックします。

  3. 各ロググループ (/aws/rds、/aws/eks、/aws/lambda) を選択し、[サブスクリプションフィルター] タブを選択します。

    Terraform 設定ファイルで指定した名前に基づいて、送信先 ARN を指すアクティブなサブスクリプションフィルターが表示されます。

  4. サブスクリプションフィルターを選択して、その設定とステータスを検証します。

DevOps エンジニア

Firehose ストリームを確認します。

ログアーカイブアカウントの Firehose ストリームがアプリケーションログを正常に処理することを確認するには、以下の手順を実行します。

  1. ログアーカイブアカウントで、Firehose コンソールを開きます。

  2. ナビゲーションペインで [Firehose ストリーム] を選択します。

  3. [Firehose ストリーム] を選択し、以下を確認します。

    • 送信先には正しい S3 バケットが表示されています。

    • [モニタリング] タブには、成功した配信メトリクスが表示されています。

    • 直近の配信タイムスタンプは最新のものです。

DevOps エンジニア

一元化された S3 バケットを検証します。

一元化された S3 バケットがログを適切に受信して整理することを確認するには、以下の手順を実行します。

  1. ログアーカイブアカウントで、Amazon S3 コンソールを開きます。

  2. 各中央ログ記録バケットを選択します。

  3. フォルダ構造 AWSLogs/AccountID/Region/Service に移動します。

    タイムスタンプ (YYYY/MM/DD/HH) で整理されたログファイルが表示されるはずです。

  4. 最新のログファイルを選択し、その形式とデータの整合性を確認します。

DevOps エンジニア

SQS キューを検証します。

SQS キューが新しいログファイルの通知を受信することを確認するには、以下の手順を実行します。

  1. ログアーカイブアカウントで、Amazon SQS コンソールを開きます。

  2. 左のナビゲーションペインで [Queues] (キュー) を選択します。

  3. 設定された各キューを選択し、[メッセージを送受信] を選択します。

    新しいログファイルの S3 イベント通知を含むメッセージが表示されます。

  4. メッセージを選択して、正しい S3 オブジェクト情報が含まれていることを確認します。

DevOps エンジニア
タスク説明必要なスキル

オプション 1 – AFT から Terraform 設定ファイルを削除します。

Terraform 設定ファイルを削除して変更をプッシュすると、AFT は自動的にリソース削除プロセスを開始します。

  1. aft-account-customizations リポジトリに移動します。

  2. terraform ディレクトリに移動します。

  3. 次のファイルを削除します。

    • modules ディレクトリ

    • iam.tf

    • versions.tf

    • variables.tf

    • outputs.tf

    • terraform.tfvars

  4. main.tf ファイルのコンテンツをクリアします。

  5. 変更をリポジトリにプッシュします。

    # Stage all changes
$ git add *

# Commit cleanup changes
$ git commit -m "Remove AFT customizations"

# Push to repository
$ git push origin main
    注記

    別のブランチ (dev など) を使用している場合は、main をブランチ名に置き換えます。

DevOps エンジニア

オプション 2 – Terraform リソースを手動でクリーンアップします。

AFT を使用していない場合、またはリソースを手動でクリーンアップする場合は、Application_account および Log_archive_account フォルダから次の Terraform コマンドを使用します。

  1. Terraform の設定を初期化します。

    $ terraform init

    このコマンドは Terraform を初期化し、現在の状態へのアクセスを確保します。

  2. クリーンアップの変更をプレビューします。

    $ terraform destroy

    このコマンドは、破棄されるリソースを評価し、望ましい状態をインフラストラクチャの現在の状態と比較します。

  3. クリーンアップを実行します。プロンプトが表示されたら、「yes」と入力して、破棄計画を確認して実行します。

DevOps エンジニア

トラブルシューティング

問題ソリューション

CloudWatch Logs の送信先が作成されていないか、非アクティブです。

以下を確認してください。

  1. ログアーカイブアカウントで、送信先ポリシーに以下が含まれていることを確認します。

    • 正しいソースアカウントプリンシパル。

    • 正しいアクション (logs:PutSubscriptionFilter)。

    • 有効な送信先の ARN。

  2. Firehose ストリームが存在し、アクティブであることを確認します。

  3. 送信先にアタッチされている IAM ロールに Firehose のアクセス許可があることを確認します。

サブスクリプションフィルターが失敗した、または保留中のステータスのままです。

以下をチェックしてください:

  1. アプリケーションアカウントで、IAM ロールに次のものがあることを確認します。

    • PutSubscriptionFilter を呼び出すアクセス許可。

    • CloudWatch Logs との信頼関係。

  2. 送信先の ARN が正しいことを確認します。

  3. 特定のエラーメッセージについては、CloudWatch Logs を確認してください。

Firehose 配信ストリームに受信レコードが表示されません。

以下について確認します。

  1. Firehose IAM ロールに次のものがあることを確認します。

    • Amazon S3 への書き込みアクセス許可。

    • 暗号化が有効になっている場合の AWS KMS キーへのアクセス。

  2. 以下の CloudWatch メトリクスを確認します。

    • IncomingRecords

    • DeliveryToS3.Records

  3. バッファ設定と配信設定を確認します。

関連リソース