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

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

Terraform を使用してエンタープライズ規模で集中ロギングを設定する

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

概要

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

このパターンは、複数の AWS アカウント および サービスからのログを一元化するためのスケーラブルで安全なフレームワークを提供し、複雑な AWS デプロイ全体でエンタープライズ規模のログ記録管理を可能にします。このソリューションは、一貫した反復可能なデプロイを確保し、手動設定を最小限に抑える HashiCorp のInfrastructure as Code (IaC) ツールである Terraform を使用して自動化されています。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 QuickSight

すべてのデータは 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 などの からのログを効率的に処理し、合理化されたプロセスを通じてログアーカイブアカウントのリージョン S3 バケットにルーティングします。

複数のアプリケーションアカウントからログを収集するための AWS 集中ロギングアーキテクチャ。

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

  1. ログフロープロセス

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

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

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

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

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

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

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

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

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

    • これらの Firehose ストリームは、データの主権要件を維持するために、ソースアプリケーションアカウント (図のリージョン A) と同じリージョンにある Log Archive アカウントの 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 集中ロギングリポジトリで入手できます。

ベストプラクティス

エピック

タスク説明必要なスキル

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ディレクトリの内容をコピーして、aft-account-customizationsリポジトリのステップ 1 で作成した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: リソースがデプロイされる環境の名前 (、proddev、 など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: リソースがデプロイされるターゲットのログアーカイブアカウントの 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 エンジニア

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

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

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

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

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

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

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. 計画された変更を確認し、プロンプトで「はい」と入力してアプリケーションに進みます。

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

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

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

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

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

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

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

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

DevOps エンジニア

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

Log Archive アカウントの Firehose ストリームがアプリケーションログを正常に処理することを検証するには：

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

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

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

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

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

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

DevOps エンジニア

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

一元化された S3 バケットがログを正しく受信して整理することを検証するには：

  1. Log Archive アカウントで、Amazon S3 コンソールを開きます。

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

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

    ログファイルはタイムスタンプ (YYYY/MM/DD/HH) 別に整理されています。

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

DevOps エンジニア

SQS キューを検証します。

SQS キューが新しいログファイルの通知を受信することを確認するには：

  1. Log Archive アカウントで、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. クリーンアップを実行します。プロンプトが表示されたら、「はい」と入力して、破棄計画を確認して実行します。

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. バッファ設定と配信設定を確認します。

関連リソース