AWSでログ管理を効率化！cron から CloudWatch/Firehose への移行メリット・比較・手順を解説

はじめに

多くのシステムにおいて、EC2インスタンスのログ管理は重要な運用タスクの一つです。
従来 cron ジョブでログの転送や圧縮を行うことは一般的でした。
しかし cron 運用には設定管理の煩雑さやエラー発生時の追跡困難さなど見過ごせない課題が潜んでいます。
AWSはこれらの運用上のボトルネックを解消するマネージドサービスを提供します！
この記事では、cron を用いた従来のログ管理における課題を、Amazon CloudWatch Logs と Amazon Data Firehose を活用してどのように解決できるか、そのメリットと具体的な移行手順を解説します。

既存の cron 設定と課題

例えば以下のような cron 設定でサーバーログを管理しているケースを考えます。

このような cron 運用は一見シンプルですが実運用では以下のような課題に直面しやすく管理コストの増大や障害対応の遅れにつながる可能性があります。これらの課題は後の手順で示すAWSの仕組みによって解消を目指します。

• 設定管理の複雑化とミスの温床:
  • サーバー台数が増えると各サーバーへの cron 設定や自作スクリプトの配布 更新作業は非常に煩雑になります。設定漏れやバージョンの不整合といったヒューマンエラーが発生しやすい状態です。AWSサービスでは設定の一元管理が可能となりこの問題を解決します。
• 不安定なエラーハンドリング:
  • スクリプトの実行失敗時や転送エラーが発生してもその検知や原因特定が容易ではありません。エラー通知の仕組みも自前で作り込む必要があり障害発生時の対応が後手に回りがちです。AWSのマネージドサービスは監視と通知の仕組みを提供しこの課題に対処します。
• リアルタイム分析の障壁:
  • cron はスケジュール実行のためログ発生から収集 転送までに必ずタイムラグが生じます。これによりインシデント発生時の迅速な状況把握やリアルタイムでのログ分析が困難になります。CloudWatch Agent によるリアルタイム転送はこのギャップを埋めます。
• スケーラビリティの限界:
  • ログ量が急増した場合やサーバー構成が頻繁に変わる環境では cron ジョブの実行時間やサーバーリソースへの影響を都度考慮しスクリプトや設定の見直しが必要になります。AWSのマネージドサービスはスケーラビリティを考慮して設計されており柔軟に対応できます。
• 属人化とブラックボックス化のリスク:
  • スクリプトの内容や cron 設定の詳細が特定の担当者しか把握していない状況は運用リスクとなります。担当者の不在時に問題が発生すると対応が困難になりがちです。AWSの標準的なサービスを利用することで管理プロセスが標準化され属人化リスクを低減できます。

AWSサービスへの移行メリット: cron の課題をこう解決する

これらの cron 運用における課題は CloudWatch Logs、Amazon Data Firehose といったAWSサービスを利用することで効果的に解決できます。具体的なメリットとそれがどの課題を解決するのかを表にまとめます。

このようにAWSサービスへ移行することは単にログを転送する仕組みを変えるだけでなくcron 運用が抱える根本的な課題を解決しより堅牢で効率的なログ管理体制を構築することにつながります。特に運用負荷の軽減リアルタイム性の向上ログの一元管理と分析基盤の強化は大きなメリットです！

導入手順

今回は例として Apache のアクセスログを CloudWatch Logs 経由で Amazon Data Firehose を使用しS3へ転送する手順を示します。

検証の前提:

• 検証対象EC2インスタンスを作成していること。
• ログ転送先S3バケットを作成していること。

1. 準備フェーズ: IAMロールの設定

CloudWatch Agent や Amazon Data Firehoseが他のAWSサービスへアクセスするために適切なIAMロールが必要です。

• EC2インスタンス用IAMロール:
• 対象EC2インスタンスにアタッチするIAMロール(インスタンスプロファイル)へCloudWatchAgentServerPolicy管理ポリシーをアタッチします。これにより AgentはCloudWatch Logs へログを書き込めます。
  
• IAMロールへのポリシーアタッチが完了しました。
• Amazon Data Firehose 用IAMロール:
• Firehose が S3バケットへ書き込むためのIAMロールを新規作成します。
• 信頼関係でfirehose.amazonaws.comを信頼する設定にします。
• S3への書き込み権限をアタッチします。今回は便宜上、S3へのフルアクセスを許可しますが、最小権限の原則に従い設定してください。
  
  
• CloudWatch Logs サブスクリプションフィルター用IAMロール:
• CloudWatch Logs が Amazon Data Firehose ストリームへ出力するためのIAMロールを新規作成します。
• カスタム信頼ポリシーを以下の内容で作成します。

  {
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "Statement1",
          "Effect": "Allow",
          "Principal": {"Service": "logs.ap-northeast-1.amazonaws.com"},
          "Action": "sts:AssumeRole",
          "Condition": { 
                 "StringLike": { 
                     "aws:SourceArn": "arn:aws:logs:ap-northeast-1:(アカウントID):*"
                 } 
             }
      }
  ]
  }
  

  
  

2. ログ転送: CloudWatch Agent の導入と設定

対象のEC2インスタンスへ CloudWatch Agent を導入しログファイルを CloudWatch Logs へ転送する設定を行います。

• Agent のインストール:
• OSに応じて適切な手順で CloudWatch Agent をEC2インスタンスへインストールします。

  [root@ip-10-0-1-55 ~]# sudo yum install amazon-cloudwatch-agent
  --- 省略 ---
  Installed:
  amazon-cloudwatch-agent-1.300052.1-1.amzn2023.x86_64
  
  Complete!
  [root@ip-10-0-1-55 ~]#
  

• CloudWatch Agent のインストールが確認できました。
• 設定ファイルの作成:
• Agent設定ファイル (/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json など) を作成します。
• logsセクションで収集対象のログファイルパス (例: /var/log/httpd/access_log) 転送先の CloudWatch Logs ロググループ名 (例: /ec2/apache/my-web-server) ログストリーム名 (例: {instance_id}) タイムスタンプ形式などを指定します。

  {
    "logs": {
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/httpd/access_log",
                        "log_group_name": "/ec2/apache/my-web-server",
                        "log_stream_name": "{instance_id}",
                        "timezone": "LOCAL"
                    }
                ]
            }
        }
    }
  }
  

• Agent の起動と確認:
• 設定ファイルを指定して CloudWatch Agent を起動または再起動します。

  [root@ip-10-0-1-55 etc]# sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s
  ****** processing amazon-cloudwatch-agent ******
  I! Trying to detect region from ec2 D! [EC2] Found active network interface I! imds retry client will retry 1 timesSuccessfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json.tmp
  Start configuration validation...
  2025/04/26 03:35:10 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json.tmp ...
  2025/04/26 03:35:10 I! Valid Json input schema.
  2025/04/26 03:35:10 Configuration validation first phase succeeded
  I! Detecting run_as_user...
  I! Trying to detect region from ec2
  D! [EC2] Found active network interface
  I! imds retry client will retry 1 times
  /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
  Configuration validation second phase succeeded
  Configuration validation succeeded
  amazon-cloudwatch-agent has already been stopped
  [root@ip-10-0-1-55 etc]# sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
  {
    "status": "running",
    "starttime": "2025-04-26T03:35:10+00:00",
    "configstatus": "configured",
    "version": "1.300052.1"
  }
  [root@ip-10-0-1-55 etc]#
  

3. ログ転送: CloudWatch Logs での確認

Agent からログが転送されているか CloudWatch Logs コンソールで確認します。

• AWSマネジメントコンソールで CloudWatch Logs を開きます。
• Agent 設定ファイルで指定したロググループ名 (例: /ec2/apache/my-web-server) を選択します。
  • ※ロググループは最初のログが送られたタイミングで作成されます。作成した適当なページへアクセスしてください。
• ログストリーム が作成されログイベントがリアルタイムで表示されることを確認します。
  
• ログデータが CloudWatch Logs へ正常に転送されていることが確認できました。
  ここでログがリアルタイムに近い形で確認・検索できることが、cron 運用に対する大きなメリットの一つです！

4. S3への配信: Amazon Data Firehose の設定と確認

CloudWatch Logs へ転送されたログを Amazon Data Firehose 経由でS3へ配信 保存する設定を行います。

• Firehose ストリームの作成:
  • Amazon Data Firehose コンソールで「Firehose ストリームを作成」を選択します。
  • ソース: Direct PUT を選択し先ほど確認したロググループを指定します。
  • 送信先: Amazon S3 を選択します。
  • ストリーム名: 任意の名前を設定します。
  • ※オプションについて:
    • 「Amazon CloudWatch Logs からソースレコードを解凍する」オンにするとAmazon Data Firehose は、宛先にデータを配信する前に、受け取った gzip 圧縮された CloudWatch Logs データを自動的に解凍します。
    • 「ログイベントからのみメッセージフィールドを抽出」オンにするとAmazon Data Firehose は、各ログイベントの JSON 構造全体ではなく、その中の message フィールドの値だけを抽出して宛先に配信します。
    • 今回はどちらもオンにして進めます。
  • IAMロール: 準備フェーズで作成した Firehose 用のIAMロールを指定します。
    
  • Firehose ストリームの設定が完了しました。
  • CloudWatch Logsサブスクリプションフィルターの設定:
  • CloudWatch Logs コンソールで対象のロググループを選択します。
  • 「サブスクリプションフィルター」タブから「 Amazon Data Firehose サブスクリプションフィルターを作成」を選択します。
  • 作成した Firehose ストリームを選択し必要に応じてフィルターパターンを設定（通常はすべて転送）します。
    
  • サブスクリプションフィルターの設定が完了しました。

5. S3へのログ転送最終確認

ここまでの手順でCloudWatch AgentからAmazon Data Firehoseまでの設定は完了しました。
最後にログデータが最終目的地であるS3バケットへ正しく転送 保存されているか確認しましょう。

S3にファイルが存在することが確認できます。

開いてみると、apache のログが出力されていることが確認できますね。

これでCloudWatch Agent → CloudWatch Logs → Amazon Data Firehose → S3 という一連のログ転送パイプラインが正常に機能していることが確認できました！

まとめ

cron を用いた従来のログ管理と CloudWatch Agent、CloudWatch Logs、Amazon Data Firehose の比較と導入手順、それによって解決される課題を解説しました。
この移行により cron 運用における設定管理の複雑さ エラー対応の遅れ スケーラビリティの懸念といった課題が解消されログ管理の運用負荷は大幅に軽減されます。
そして収集したログは Amazon Athena や Amazon OpenSearch Service などと連携させることでこれまで難しかった高度な分析や可視化も可能となります。
ぜひこの機会にAWSのマネージドサービスを活用しログ管理の課題を解決そして効率化を実現することを検討してみてください！

参考ドキュメント

CloudWatch Agent
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html

CloudWatch Logs
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/Subscriptions.html

Amazon Data Firehose
https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/what-is-this-service.html
https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/controlling-access.html