Amazon CloudWatch からテレメトリデータを取得する：ログ編

Amazon CloudWatch Logs は AWS 環境におけるログ管理の中心的なサービスとして、様々なソースからのログデータを収集、監視、分析する機能を提供しています。一方で、長期保存のコスト最適化やサードパーティのログ分析ツールとの連携など、様々な理由からログデータを CloudWatch Logs から他の場所に転送する必要が生じることがあります。

本記事では、CloudWatch Logs からログを転送する必要が生じるユースケースと、AWS が提供する3つの転送方法について詳細に説明します。それぞれの方法の特徴、制限事項、そして適用シナリオについて解説していきます。

本記事ではログの取得方法について解説します。メトリクスの取得については Amazon CloudWatch からテレメトリデータを取得する：メトリクス編をご参照ください。

はじめに

ログの取り出し方法を説明する前に、まず AWS 上で稼働するサービスのログ発行の特徴について解説します。
AWS 環境では、図1に示すようにログの収集経路が大きく2つあります。

1. AWS マネージドサービスが発行するログ
   ALB、Amazon Route 53、Amazon S3、Amazon RDS、AWS Lambda など、多くのマネージドサービスは標準で Amazon CloudWatch にログを送信します。この方法ではログ収集のためのコードや特別な処理を組む必要がないため、実装工数が少なくて済むというメリットがあります。
   ただし、一部のサービスは CloudWatch ではなく Amazon S3 や Amazon Data Firehose に直接ログを送信する場合があります。利用するサービスのログ出力先は、こちらのドキュメントにまとめられています。
2. OS レイヤーや独自アプリケーションのログ
   EC2 の OS ログや、開発したアプリケーション内部のログなどは、デフォルトでは自動収集されません。
   収集するには設定が必要であり、最も簡単な方法は Amazon CloudWatch エージェント（統合エージェント）を導入し、CloudWatch に送信する構成です。

では、次に Amazon CloudWatch に収集されたログを取り出す手段について解説していきます。

図1. AWS におけるログの種類

CloudWatch Logs からログを転送する方法

ここから本ブログの主題であるログを転送するため3つの方法をご紹介します。

1 : サブスクリプションフィルターを用いる方法

サブスクリプションフィルターとは、CloudWatch Logs に記録されたログをリアルタイムに他のサービスに配信をする仕組みです。名前の通りフィルターなので、特定のパターンにマッチするものだけを配信や、すべてのログの配信が可能です。配信先は「Amazon Kinesis Data Streams」「Amazon Data Firehose」「AWS Lambda」「Amazon OpenSearch Service」が選択可能で、ロググループレベルで設定する方法と、アカウントレベルで設定する方法があります。アカウントレベルで設定すれば、ロググループ一つずつにサブスクリプションフィルターを設定する必要がないという利点があります。

フィルターの種類に悩まれる方も多いかと思いますが、まずは、Amazon Data Firehose の検討から進めることをおすすめします。Amazon Data Firehose の配信先には Amazon S3 をはじめとする AWS サービスや、サードパーティの監視ソリューションに直接配信も可能です。詳細については、ドキュメントをご覧ください。

2 : CloudWatch のエクスポート機能

エクスポートとは、CloudWatch Logs のログデータを Amazon S3にエクスポートする機能です。「単一のロググループ」「開始日時（ミリ秒単位）」「終了日時（ミリ秒単位）」を指定し、エクスポートタスクを CLI や AWS Systems Manager 経由で作成し、非同期で実行します。ログデータのエクスポートが開始されるまで最大 12 時間かかる場合があり、またエクスポートタスクは 24 時間でタイムアウトするため、タスクが失敗する場合はエクスポート指定区間を短くする必要があります。また、アカウントごとにアクティブなエクスポートタスクは 1 つだけというクォータがあり、複数のロググループを並列でエクスポートできない点に注意が必要です。

3 : API を用いる方法

API を経由の取得を正確に理解するために、CloudWatch Logs のログデータの格納方法とその名称を整理しましょう。

ロググループ
├── ログストリーム1
│   ├── ログイベント1
│   ├── ログイベント2
│   └── ログイベント3
├── ログストリーム2
│   ├── ログイベント1
│   └── ログイベント2
└── ログストリーム3
    └── ログイベント1

CloudWatch Logs は、ロググループ、ログストリーム、ログイベントの３層構造でログデータを管理します。

ログイベントは、モニタリングされているアプリケーションまたはリソースによって記録されたアクティビティのレコードで、タイムスタンプと生のイベントメッセージの 2 つのプロパティを持ちます。

ログストリームは、同じソースを共有する一連のログイベントで、モニタリングされているアプリケーションインスタンスやリソースから送信された順序でイベントを表します。ストリームの分割単位は送信元のサービスによって異なります（例：EC2 ではインスタンスごと、Lambda では関数の実行ごと）。

ロググループは、保持、監視、アクセス制御について同じ設定を共有するログストリームのグループを定義し、各ログストリームは必ず 1 つのロググループに属する必要があります。

AWS マネージドサービスがログを自動生成する場合は、この構造を深く意識する必要はありません。しかし、API 経由でログデータを取得する際には、この 3 層構造を意識する必要があります。

では、改めてCloudWatch Logs が提供している、ログを取り出す API を紹介いたします。

• GetLogEvents
  • 指定したログストリームからログイベントを一覧表示する API です。すべてのログイベントを一覧表示したり、時間範囲を使用してフィルタリングが可能です。
  • この API の主な用途は、特定のログストリームからのログイベント取得です。そのため、ロググループ全体を指定したログの取得はできません。
• FilterLogEvents
  • 複数のロググループやログストリームにわたってログを検索・フィルタリングできます。より高度な検索機能を提供する API です。
  • この API の主な用途は、複数のロググループを対象にしたログイベントの取得です。
• StartLiveTail
  • リアルタイムにログを取得できる API です。マネジメントコンソール経由で利用できる Live Tail を API 経由で利用できます。tail -f コマンドのようにリアルタイムでログをストリーミング取得することが可能です。
  • この API の主な用途は、リアルタイムに CloudWatch Logs へ取り込まれたログの確認です。

これらの API には多くの制限があるため、使用する際にはそれらを意識する必要があります。

まず、GetLogEvents と FilterLogEvents には共通して「最大 1 MB のログイベント、または最大 10,000 件のログイベント」のみが含まれるという制限が存在しています。いずれかの制限を超えるような場合は、nextToken が返却されます。
大量のログデータを取得する際は、このページング機能を使用する必要があります。具体的には、API レスポンスに含まれる nextToken を次のリクエストのパラメータとして指定し、nextToken の出力が空になるまで繰り返し API を呼び出します。これにより、制限を超えるログデータを段階的に取得できます。以下の表は、この制限がどのように適用されるかを示した例です。パターン 1 のように両方の制限内に収まる場合は 1 回で取得が完了しますが、パターン 2〜4 のようにいずれかの制限を超える場合は、nextToken が返却され、ページングが必要になります。

ただし、nextToken が空であるからといって、すべてのログを取り出したことを保証していません。たとえば、直近のログは API での取得が終了した後に CloudWatch Logs に登録される可能性があるからです。そのため、リアルタイムに近いログを継続的に取得したい場合は、定期的に API を呼び出すか、StartLiveTail API の使用を検討してください。

また、これらの API には呼び出し数に関してもクォータが存在します。2026 年 1 月現在、バージニア北部リージョンであっても、GetLogEvents/FilterLogEvents は 1 秒あたり 25 リクエストの制限があるため、同時に呼び出しが想定される場合は注意が必要です。

ログの取り出しが必要となるユースケース

CloudWatch Logs からログを取り出す手段について理解できたところで、次に実際の活用場面を見ていきましょう。以下では、ログの取り出しが必要となる代表的なユースケースを 3 つご紹介します。

ユースケース① 長期保存要件のあるログのコスト最適化

【活用する方法：サブスクリプションフィルター、エクスポート機能】

多くの組織では、コンプライアンスやガバナンス要件に基づいて、ログデータを 5 年や 7 年といった長期間保存する必要があります。このような場合、保存コストの最適化が重要な課題となります。

CloudWatch Logs では、アクセス頻度に応じて 2 つのストレージクラスを選択できます。標準ストレージクラスの保存料金は、東京リージョンで USD 0.033/GB（月額）です。一方、アクセス頻度の低いログには Infrequent Access (IA) ストレージクラスを利用でき、保存料金は USD 0.011/GB（月額）と、標準ストレージクラスの約 3 分の 1 のコストで保存できます。ただし、IA ストレージクラスではデータスキャン料金（USD 0.0055/GB）が発生するため、頻繁にクエリを実行するログには適していません。また、IA ストレージクラスのログは S3 へのエクスポート機能を利用できない点にも注意が必要です。

さらにコストを削減したい場合は、Amazon S3 へのエクスポートも検討できます。Amazon S3 スタンダードストレージの料金は USD 0.025/GB です。この差額は一見小さいものの、ログデータの量が増加し保存期間が長くなるにつれ、コスト差は拡大していきます。加えて Amazon S3 の場合はストレージクラスの変更が可能であり、Glacier Deep Archive を利用すると USD 0.002/GB まで料金を削減できます。

以下の表は、1 TB のログデータを 5 年間保存した場合のコスト比較例です。

この表からわかるように、アクセス頻度の低いログであれば CloudWatch Logs IA を利用することで、CloudWatch Logs 内でクエリ機能を維持しながらコストを削減できます。さらに長期保存でほとんどアクセスしないログの場合は、S3 Glacier Deep Archive を利用することで大幅なコスト削減が可能です。

また、「最初から S3 に配信する」という手段も考えられますが、その場合はログのクエリに Amazon Athena などの別の仕組みを用いる必要があります。一般的にログの検索においては、CloudWatch Logs Insights の方が高機能であるという利点があります。そのため、直近のログは CloudWatch Logs で保持してクエリを実行し、一定期間経過後に S3 にエクスポートするといったハイブリッドなアプローチも有効です。

ユースケース② サードパーティソリューションとの連携

【活用する方法：サブスクリプションフィルター】

今日の IT 業界には CloudWatch 以外にも様々な特徴を持つ監視ソリューションが多くのベンダーから提供されています。組織で既に監視ソリューションが指定されていたり、CloudWatch にはない機能が必要になった場合は、それらのサービスにログを転送する必要があります。

多くのサードパーティソリューションでは、テレメトリを収集し、直接サードパーティサービスに送信するエージェントを提供しています。ただし、AWS には CloudWatch や S3 経由でしか取得できないログが存在しています。これらは CloudWatch からの転送操作が必要です。

ユースケース③ カスタムアプリケーションからの参照

【活用する方法：API（GetLogEvents、FilterLogEvents、StartLiveTail）】

ローカルのコマンドラインで一時的にログを参照したり、LLM アプリケーションでのログ検索や独自の運用ツールでログデータを活用したいケースが考えられます。例えば、「過去 1 週間のエラーログを要約して」といった自然言語でのログ分析や、チーム独自のダッシュボードでリアルタイムログ監視を行いたい場合です。

また、障害調査時に開発者がローカル環境で柔軟にログを検索・分析したり、特定のビジネスロジックに基づいた独自のアラート機能を構築したいといったニーズもあります。さらに、既存の社内ツールやワークフローにログデータを組み込んで、より効率的な運用を実現したい場合もあるでしょう。

このユースケースでは、CloudWatch Logs API を使用してプログラムからログデータを取得します。特定のログストリームから取得する場合は GetLogEvents、複数のロググループを横断して検索する場合は FilterLogEvents、リアルタイムでログを監視する場合は StartLiveTail を使用します。これらの API を活用することで、柔軟なログ活用が可能になります。

まとめ

記事では、Amazon CloudWatch Logs からログデータを転送する 3 つの主要な方法について解説しました。

1. サブスクリプションフィルター：リアルタイムでのログ転送に適しており、サードパーティソリューションとの連携や S3 への継続的な転送に活用できます
2. エクスポート機能：過去の特定期間のログを S3 にまとめて転送する際に適しており、長期保存のためのコスト最適化に有効です
3. API（GetLogEvents、FilterLogEvents、StartLiveTail）：カスタムアプリケーションからの柔軟なログ取得に適しており、独自の運用ツールやダッシュボードの構築に活用できます

手段を選択する際は、以下の観点から総合的に判断することが重要です。

• リアルタイム性の要否
• 転送するログの量と頻度
• コストとパフォーマンスのトレードオフ
• 既存システムとの連携要件

適切な手法を選択することで、運用コストの削減と機能性の向上を両立した、効率的なログ管理戦略を実現できます。各手段の詳細については、AWS ドキュメントも併せてご参照ください。

著者

伊藤 威
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト