AWSアカウントを移行するとき、アプリケーションだけでなく、障害調査に必要なログも残しておきたいものです。ただし、CloudWatch Logsの「過去ログを持ち出すこと」と「これから発生するログを集約すること」では、選ぶ機能が異なります。
まず過去ログはS3へのエクスポートで保全し、今後のログは集約の仕組みを別に設計すると、移行計画を整理しやすくなります。CloudWatch Logsへの再投入にはログの日時に制約があるため、古いログをすべて元の日時のまま戻せるわけではありません。
最初に決めるのは「移行先で何をしたいか」
| 目的 | 検討する方法 | 注意点 |
|---|---|---|
| 既存ログを残し、必要なときに参照したい | S3へのエクスポート | ファイルの保存先や検索方法を決める |
| 最近のログを移行先CloudWatch Logsへ登録したい | エクスポート後にPutLogEventsで再投入 | イベント日時・保持期間の制約と実装がある |
| 今後のログを組織内の別アカウントに集約したい | CloudWatch Logsのクロスアカウント・クロスリージョン集約 | ルール作成前の過去ログは集約されない |
例えば、旧アカウントに1年前からのログがあり、新アカウントで今後の監視を始めるなら、過去分の保管と切替後の収集を二つの作業に分けます。移行先のロググループを作るだけでは、過去の履歴は引き継がれません。
過去ログは、まずS3にエクスポートする
CloudWatch Logsは同一アカウントだけでなく、別アカウントのS3バケットにもログをエクスポートできます。出力先の権限を整え、対象のロググループと期間を指定して処理します。詳しくはAWS公式のS3エクスポート仕様を確認してください。
保管目的なら、S3に出力したデータを無理にCloudWatch Logsへ戻す必要はありません。ファイルの取り出し方法や検索方法、保存期間を決めておけば、アカウント切替と履歴保管を切り離せます。
- 残すロググループ、必要な期間、移行後の閲覧担当者を整理する。
- 出力先バケットのアクセス権限と暗号化設定を確認する。
- ロググループや期間ごとにプレフィックスを分けてエクスポートする。
- 出力の完了とファイルの内容を確認してから、旧環境の保持方針を変更する。
ログはエクスポート可能になるまで最大12時間かかることがあります。切替直後の実行だけで直前のログまで取得できたと判断せず、遅延を考慮して最終確認を行います。エクスポートファイル内の時刻順も保証されないため、再処理する場合は並べ替えが必要です。
再投入するなら「14日より古いログ」に注意する
移行先CloudWatch Logsに登録する場合は、S3のファイルを読み取り、イベントへ変換してPutLogEventsを呼び出す処理が必要です。これはロググループの所有アカウントを変更する操作ではなく、新しいログストリームへの書き込みです。
PutLogEventsは14日より古いイベント、または移行先ロググループの保持期間より古いイベントを拒否します。例えば、1年前のログを元のイベント日時のまま投入する構成は成立しません。保持期間を長くしても、14日の制約はなくなりません。
日時を現在に置き換えると、CloudWatch上の時系列が元の発生時刻と異なります。障害発生時の前後関係を追いたいなら、安易に日時を書き換えるのではなく、元の日時を保ったS3保管を優先して検討します。
再投入対象が条件内でも、バッチ内のイベントは日時順に並べ、1バッチの時間幅を24時間以内に収める必要があります。HTTP 200でも一部のイベントが拒否されることがあるため、レスポンスのrejectedLogEventsInfoを確認します。仕様はPutLogEvents APIリファレンスに記載されています。
今後のログは、組織内の集約機能を検討する
今後発生するログを中央アカウントへ継続的にコピーする用途には、CloudWatch Logsの集約機能があります。AWS Organizationsの同じ組織にある送信元・送信先アカウントを対象にルールを設定します。
ただし、対象になるのは集約ルールを作成した後に送信元へ到着する新しいログです。既存ログの一括移行とは役割が違います。組織の管理アカウントまたは委任管理者による設定、信頼されたアクセス、暗号化キーの権限なども確認します。詳細はクロスアカウント・クロスリージョンのログ集約を参照してください。
移行計画では「過去分をエクスポートする期間」と「集約を開始する時刻」を記録します。切替の境界で抜けや重複がないか、具体的なログイベントを選んで照合すると確認しやすくなります。
旧アカウントを閉じる前に確認すること
- 必要な過去ログが、移行先の担当者の権限で参照できるか。
- 切替後の新しいログが、想定したアカウントとリージョンへ届いているか。
- ロググループの保持期間、暗号化、アラームなどを別途確認したか。
- 元のログの日時と、書き込み先で扱う日時を混同していないか。
ログ移行は「コピーできた」で完了ではなく、移行後に必要な調査ができる状態まで確認します。過去の履歴を守る作業と日々の監視をつなぐ作業を分けると、それぞれの確認事項が明確になります。
関連する記事
- CloudWatchメトリクスの長期保存について：ログとメトリクスでは保存の仕組みが異なります。
- ALBの応答時間をアクセスログで確認する方法：保存したログで何を分析するかを考える際の参考になります。
