💾 EC2終了前ログ退避設計

確実にログをS3へ保存する5つの方法とベストプラクティス

🏢 オフィス退去時の書類整理でたとえると超わかりやすい!

EC2終了 = オフィスを閉鎖して退去すること

オフィスを閉める前に、重要な書類(ログ)を必ず倉庫(S3)に移さないと永久に失われます。

でも、 「明日閉鎖します」と言われても 書類整理が間に合わないかも...
「今すぐ出て行け!」と言われたら 何も持ち出せません。

この問題を解決する 5つの戦略 を完全解説します✨

どの方法が 確実 実用的 か、シナリオ別に徹底比較!

🏢 オフィス退去の書類整理戦略

📦 問題: EC2終了でログが消える
シナリオ:
あなたの会社は、プロジェクト終了後にオフィスを閉鎖することになりました。
オフィス内には過去1年分の重要な業務記録(ログファイル)が保管されています。

問題:
オフィス閉鎖(EC2終了)と同時に、そこにある全ての書類は処分されます。
倉庫(S3)に移動しておかないと、永久に失われます。

でも、退去のタイミングは予測できないことも...
• 計画的な閉鎖: 「来週の金曜日に退去します」
• 突然の閉鎖: 「今日中に出て行ってください!」
• 緊急の閉鎖: 「今すぐ退去!」(火災、強制退去など)
💡 解決策: 5つの書類移動戦略
戦略1: 毎日倉庫に送る(CloudWatch Logs)
→ 書類が作成されるたびに、即座に倉庫へコピー。最も確実!

戦略2: 退去通知を受けて移動(ライフサイクルフック)
→ 「明日退去です」という通知を受けて、猶予時間内に移動作業

戦略3: 閉鎖イベントを検知して緊急移動(EventBridge + Lambda)
→ 退去が始まった瞬間に検知して、外部から救出作業を実施

戦略4: 退去時に自動実行(シャットダウンスクリプト)
→ ドアを閉める直前に自動で書類を送信する仕組み

戦略5: 定期的に移動(スケジュールバックアップ)
→ 毎日自動で倉庫へコピー。退去時は最新分だけ残る

🎯 5つの退避方法 - 完全解説

🏆
方法1: CloudWatch Logs + S3エクスポート
リアルタイム転送方式(最も確実・推奨)
信頼性: ⭐⭐⭐⭐⭐ (最高) 複雑さ: ⭐⭐☆☆☆ (簡単) コスト: ⭐⭐⭐☆☆ (中)
🏢 オフィスのたとえ
書類が作成されるたびに、 即座にコピーを倉庫へ送信 する自動システム。
オフィスが突然閉鎖されても、全ての書類は既に倉庫に保管済み。

例: 社員が報告書を書くたびに、同時に本社の倉庫にもコピーが自動送信される。
⚙️ 仕組み
1. CloudWatch Logs Agent をEC2にインストール
2. ログファイルをリアルタイムでCloudWatch Logsに送信
3. CloudWatch LogsからS3へ自動エクスポート(Kinesis Data Firehose使用)
4. EC2が終了しても、ログは既にS3に保存済み

または:
• CloudWatch Logs Insightsで定期エクスポート設定
• S3へのサブスクリプションフィルター設定
メリット
  • 最高の信頼性: リアルタイム転送でデータ損失なし
  • 突然の終了にも対応: 既にS3にあるので安心
  • 監視機能: CloudWatch Alarmで異常検知
  • 検索可能: CloudWatch Logs Insightsで分析
  • 一元管理: 複数EC2のログを集約
⚠️ デメリット
  • コスト: CloudWatch Logsの料金が発生(データ転送量に応じて)
  • セットアップ: エージェントのインストールと設定が必要
  • 遅延: リアルタイムだが数秒〜数分の遅延あり
CloudWatch Logs Agent 設定例 (Amazon Linux 2)
# CloudWatch Logs Agentのインストール
sudo yum install -y amazon-cloudwatch-agent

# 設定ファイル作成 (/opt/aws/amazon-cloudwatch-agent/etc/config.json)
{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/application.log",
            "log_group_name": "/aws/ec2/myapp",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

# エージェント起動
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json
🎯 推奨シナリオ
本番環境 のログ管理
コンプライアンス 要件がある場合
突然の終了 にも対応が必要
長期保存 が必要なログ
複数インスタンス のログを集約したい

→ 最も推奨される方法です!
🔔
方法2: Auto Scaling ライフサイクルフック
猶予時間付き退避方式(Auto Scaling環境向け)
信頼性: ⭐⭐⭐⭐☆ (高) 複雑さ: ⭐⭐⭐☆☆ (中) コスト: ⭐⭐☆☆☆ (低)
🏢 オフィスのたとえ
オフィス閉鎖の 1時間前に通知 が来て、その間に書類を倉庫へ移動。
「あと1時間で退去です。それまでに書類を整理してください」という猶予期間。

例: ビル管理会社から「19:00に施錠します」と18:00に連絡が入り、1時間で片付ける。
⚙️ 仕組み
1. Auto Scaling Group でライフサイクルフックを設定
2. インスタンス終了時に TERMINATING:WAIT 状態で一時停止(最大2時間)
3. EventBridge(旧CloudWatch Events)がフックをトリガー
4. Lambda関数が起動し、Run Commandでログ退避スクリプトを実行
5. 完了後、ライフサイクルフックを完了させてインスタンス終了

重要: Auto Scalingでスケールインする場合に有効
メリット
  • 猶予時間: 最大2時間の処理時間を確保
  • 確実な実行: 終了前に必ず実行される
  • 大容量対応: 大量のログも余裕を持って転送
  • 自動化: 手動操作不要
  • 低コスト: CloudWatch Logs不要
⚠️ デメリット
  • Auto Scaling限定: スタンドアロンEC2では使えない
  • 手動終了は不可: コンソールからの終了には対応しない
  • 複雑な設定: Lambda、EventBridge、IAM設定が必要
  • タイムアウト: 2時間を超える処理は不可
ライフサイクルフック設定例(AWS CLI)
# ライフサイクルフックの作成
aws autoscaling put-lifecycle-hook \
  --lifecycle-hook-name log-backup-hook \
  --auto-scaling-group-name my-asg \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --default-result CONTINUE \
  --heartbeat-timeout 3600 \
  --notification-target-arn arn:aws:sns:region:account:topic

# Lambda関数(Python)でログをS3へアップロード
import boto3
import json

def lambda_handler(event, context):
    ssm = boto3.client('ssm')
    asg = boto3.client('autoscaling')
    
    instance_id = event['detail']['EC2InstanceId']
    
    # Run Commandでログ退避スクリプト実行
    response = ssm.send_command(
        InstanceIds=[instance_id],
        DocumentName='AWS-RunShellScript',
        Parameters={
            'commands': [
                'tar -czf /tmp/logs-$(date +%Y%m%d-%H%M%S).tar.gz /var/log/',
                'aws s3 cp /tmp/logs-*.tar.gz s3://my-bucket/logs/'
            ]
        }
    )
    
    # ライフサイクルフックを完了
    asg.complete_lifecycle_action(
        LifecycleHookName='log-backup-hook',
        AutoScalingGroupName='my-asg',
        LifecycleActionResult='CONTINUE',
        InstanceId=instance_id
    )
🎯 推奨シナリオ
Auto Scaling を使用している環境
スケールイン時 のログ保存
大容量ログ (数GB以上)の転送
CloudWatch Logsのコスト を抑えたい
計画的な終了 が多い環境

→ Auto Scaling環境では非常に有効!
方法3: EventBridge + Lambda (EC2終了イベント検知)
イベント駆動救出方式(外部からの介入)
信頼性: ⭐⭐⭐☆☆ (中) 複雑さ: ⭐⭐⭐☆☆ (中) コスト: ⭐⭐☆☆☆ (低)
🏢 オフィスのたとえ
オフィスが閉鎖され始めた瞬間に、 外部の救出隊 が駆けつけて書類を回収。
社員が退去した後でも、外部から遠隔で書類を取り出せる仕組み。

例: ビル管理会社が「このオフィス閉鎖開始」と察知し、即座に重要書類回収チームを派遣。
⚙️ 仕組み
1. EventBridgeでEC2状態変化イベント( shutting-down )を監視
2. インスタンスが stopping または shutting-down 状態になったらLambdaトリガー
3. Lambda関数がRun Commandでログ退避を実行
4. または、EBSスナップショットを即座に作成

注意: terminated 状態では遅すぎる。 shutting-down stopping を検知する必要がある。
メリット
  • 汎用性: あらゆる終了パターンに対応
  • 手動終了も検知: コンソールからの終了も対応
  • 自動化: 人手不要で実行
  • 柔軟性: スナップショット作成など他の処理も可能
⚠️ デメリット
  • タイミング問題: 状態変化検知からLambda起動まで数秒のラグ
  • 処理時間制限: Lambdaは最大15分。大量ログには不向き
  • 確実性: インスタンスが即座に停止すると間に合わない可能性
  • 強制終了: terminated 状態では手遅れ
EventBridge ルール設定例
# EventBridge ルール(イベントパターン)
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["shutting-down", "stopping"]
  }
}

# Lambda関数(Python)
def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    ssm = boto3.client('ssm')
    
    instance_id = event['detail']['instance-id']
    state = event['detail']['state']
    
    if state == 'shutting-down':
        # 緊急: EBSスナップショット作成
        volumes = ec2.describe_volumes(
            Filters=[{'Name': 'attachment.instance-id', 'Values': [instance_id]}]
        )
        for volume in volumes['Volumes']:
            ec2.create_snapshot(
                VolumeId=volume['VolumeId'],
                Description=f'Emergency backup before termination'
            )
⚠️ 重要な注意点
この方法の最大の弱点:

terminated状態では手遅れ: インスタンスは既に停止済み
shutting-downでも時間切れの可能性: 数秒で終了することも
強制終了には無力: 即座の終了では間に合わない

→ 他の方法との併用が推奨されます
🎯 推奨シナリオ
補助的な手段 として他の方法と併用
スナップショット作成 など短時間処理
通知送信 など軽量な処理
小容量ログ (数MB程度)の即座転送

→ メインの方法ではなく、保険として使用
🔧
方法4: シャットダウンスクリプト (systemd / rc.local)
OS標準機能による退避(シンプル)
信頼性: ⭐⭐☆☆☆ (低) 複雑さ: ⭐☆☆☆☆ (簡単) コスト: ⭐☆☆☆☆ (無料)
🏢 オフィスのたとえ
ドアを閉める直前に、 自動で書類を送信する装置 を設置。
最後の人が退出すると、センサーが反応して自動で倉庫へ書類を送る。

例: 退出時に自動でシュレッダーが動くように、ログ送信スクリプトが動く仕組み。
⚙️ 仕組み
1. systemdサービスで シャットダウン時実行 スクリプトを登録
2. OSがシャットダウン開始すると自動実行
3. スクリプトでログファイルをtar.gz化してS3へアップロード
4. 完了後、OSがシャットダウンを継続

設定場所:
• systemd: /etc/systemd/system/log-backup.service
• 古いシステム: /etc/rc0.d/ (シャットダウン時実行)
メリット
  • シンプル: 追加のAWSサービス不要
  • 無料: AWS料金なし(S3ストレージ除く)
  • 確実な起動: OS標準機能で実行保証
  • あらゆる終了に対応: 再起動・シャットダウン両方
⚠️ デメリット
  • 時間制限: OSのシャットダウンタイムアウト(通常90秒)
  • 強制終了は不可: 電源断、クラッシュには無力
  • 大容量は困難: タイムアウトで中断される可能性
  • エラー処理困難: 失敗時のリトライなし
  • 監視不可: 実行状況の可視化が難しい
systemd シャットダウンサービス設定例
# /etc/systemd/system/log-backup.service
[Unit]
Description=Backup logs to S3 before shutdown
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-logs.sh
TimeoutStartSec=90
RemainAfterExit=yes

[Install]
WantedBy=halt.target reboot.target shutdown.target

# /usr/local/bin/backup-logs.sh
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
INSTANCE_ID=$(ec2-metadata --instance-id | cut -d " " -f 2)
LOG_FILE="/tmp/logs-${INSTANCE_ID}-${TIMESTAMP}.tar.gz"

# ログファイルを圧縮
tar -czf ${LOG_FILE} /var/log/application/ 2>/dev/null

# S3にアップロード
aws s3 cp ${LOG_FILE} s3://my-bucket/logs/ --region ap-northeast-1

# 一時ファイル削除
rm -f ${LOG_FILE}

# サービス有効化
sudo systemctl enable log-backup.service
⚠️ 致命的な制約
90秒のタイムアウト:
Linuxのシャットダウンプロセスは、各サービスに通常90秒の猶予を与えます。
これを超えると強制終了(SIGKILL)されます。

大容量ログは不可:
• 1GBのログを90秒でアップロードするには約90Mbpsの速度が必要
• ネットワーク遅延や圧縮時間も考慮すると、実質的には数百MB程度が限界

→ 小〜中容量のログ専用
🎯 推奨シナリオ
小規模環境 (数台のEC2)
小容量ログ (数十〜数百MB)
シンプルさ重視 (複雑な設定を避けたい)
予算制約 (追加コストなし)
開発・テスト環境

→ シンプルだが制約が多い。本番環境では非推奨
📅
方法5: 定期バックアップ + 差分取得
スケジュール方式(最小限の損失)
信頼性: ⭐⭐⭐☆☆ (中) 複雑さ: ⭐⭐☆☆☆ (簡単) コスト: ⭐☆☆☆☆ (無料)
🏢 オフィスのたとえ
毎日定時 に、その日の書類を倉庫へ自動送信。
突然の閉鎖が起きても、最悪でも1日分の書類を失うだけで済む。

例: 毎晩23:00に自動で今日の報告書を本社へ送信。明日急に閉鎖されても昨日までの分は安全。
⚙️ 仕組み
1. cron で定期的(1時間毎、1日毎など)にバックアップスクリプトを実行
2. または、 EventBridge (CloudWatch Events) で定期実行
3. ログファイルを圧縮してS3へアップロード
4. 前回バックアップ以降の 差分のみ を転送(rsyncやaws s3 sync使用)
5. EC2終了時は、最後のバックアップ〜終了までの分だけ失われる

データ損失: バックアップ間隔分のログが失われる可能性(1時間毎なら最大1時間分)
メリット
  • シンプル: cronやEventBridgeで簡単に実装
  • 低コスト: 追加のAWSサービスほぼ不要
  • 柔軟性: バックアップ頻度を自由に調整
  • 大容量対応: 時間制限なく大量ログも可能
  • 軽量: リアルタイム転送より負荷が低い
⚠️ デメリット
  • データ損失: 最後のバックアップ以降のログは失われる
  • 完全性なし: 100%の保証はない
  • 頻度とコスト: 頻繁にすると転送コスト増加
  • 遅延: リアルタイムではない
cron設定による定期バックアップ例
# /etc/cron.d/log-backup
# 1時間ごとにログをS3へバックアップ
0 * * * * root /usr/local/bin/hourly-log-backup.sh

# /usr/local/bin/hourly-log-backup.sh
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d-%H%M)
INSTANCE_ID=$(ec2-metadata --instance-id | cut -d " " -f 2)

# 差分のみを同期(効率的)
aws s3 sync /var/log/application/ \
  s3://my-bucket/logs/${INSTANCE_ID}/ \
  --exclude "*" \
  --include "*.log" \
  --region ap-northeast-1

# または、圧縮してアップロード
tar -czf /tmp/logs-${TIMESTAMP}.tar.gz \
  /var/log/application/*.log

aws s3 cp /tmp/logs-${TIMESTAMP}.tar.gz \
  s3://my-bucket/logs/${INSTANCE_ID}/ \
  --region ap-northeast-1

rm -f /tmp/logs-${TIMESTAMP}.tar.gz
💡 改善アイデア
方法4と組み合わせて完全性向上:

1. 定期バックアップ (この方法)で大部分を保存
2. シャットダウンスクリプト (方法4)で最後の差分を保存

この組み合わせで、データ損失を最小限にできます!

例: 1時間毎に定期バックアップ + シャットダウン時に最後の1時間分を保存
→ ほぼ完全なログ保存が低コストで実現
🎯 推奨シナリオ
コスト重視 (CloudWatch Logsを避けたい)
多少のデータ損失は許容 できる環境
大容量ログ の定期バックアップ
開発・ステージング環境
方法4との併用 で完全性向上

→ シンプルで実用的。方法1の代替として有効

📊 5つの方法 - 徹底比較表

項目 方法1
CloudWatch Logs
方法2
ライフサイクルフック
方法3
EventBridge + Lambda
方法4
シャットダウンスクリプト
方法5
定期バックアップ
信頼性 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐☆ ⭐⭐⭐☆☆ ⭐⭐☆☆☆ ⭐⭐⭐☆☆
実装の複雑さ 中(エージェント設定) 高(複数サービス連携) 中(Lambda + EventBridge) 低(シェルスクリプトのみ) 低(cron設定のみ)
コスト 中〜高
(データ転送量)

(Lambda実行のみ)

(Lambda実行のみ)
無料
(S3ストレージ除く)
無料
(S3ストレージ除く)
データ完全性 100%
(リアルタイム)
100%
(猶予時間あり)
80-90%
(タイミング依存)
70-80%
(タイムアウトあり)
80-90%
(間隔分は損失)
突然の終了 ✅ 対応 ⚠️ Auto Scalingのみ ⚠️ タイミング次第 ❌ 困難 ❌ 未対応
大容量ログ ✅ 対応 ✅ 対応(2時間) ❌ 不可(15分制限) ❌ 不可(90秒制限) ✅ 対応
Auto Scaling ✅ 対応 ✅ 最適 ✅ 対応 ✅ 対応 ✅ 対応
手動終了 ✅ 対応 ❌ 不可 ✅ 対応 ✅ 対応 ⚠️ 差分損失
リアルタイム性 ✅ 数秒〜数分 ✅ 終了前確実 ⚠️ タイミング次第 ⚠️ シャットダウン時 ❌ 定期実行のみ
監視・可視化 ✅ CloudWatch標準 ✅ Lambda Logs ✅ Lambda Logs ❌ 困難 ⚠️ カスタム必要
推奨環境 本番環境 本番(Auto Scaling) 補助手段 開発・テスト 開発・ステージング

🏗️ 推奨アーキテクチャ: 多層防御戦略

最も確実な構成: 複数手法の組み合わせ

単一の方法に頼らず、複数の退避手段を用意することで 99.9%以上の信頼性 を実現

1 第一防衛線: CloudWatch Logs(リアルタイム転送)
役割: 通常運用時のログを全てリアルタイムでS3へ
対象: 全てのアプリケーションログ、システムログ
メリット: どんな終了パターンでも99%のログは既に保存済み
コスト: 中程度(でも最も確実)
⬇️
2 第二防衛線: ライフサイクルフック(Auto Scaling環境)
役割: スケールイン時の確実な退避
対象: CloudWatch Logsでカバーしきれない一時ファイル、大容量データ
メリット: 猶予時間内に確実に転送完了
適用条件: Auto Scalingを使用している場合のみ
⬇️
3 第三防衛線: 定期バックアップ(コスト最適化)
役割: CloudWatch Logsの補完(コスト削減のため一部ログは定期保存)
対象: アクセスログなど容量の大きいログ
頻度: 1時間毎または1日毎
メリット: コストを抑えつつ、ほぼ全てのログを保存
⬇️
4 最終防衛線: シャットダウンスクリプト(保険)
役割: 万が一の取りこぼし防止
対象: 定期バックアップの最後の差分
メリット: ほぼ0コストで最後のチャンス
制約: 90秒タイムアウトがあるため小容量のみ
⬇️
5 緊急手段: EventBridge + EBS Snapshot(最終手段)
役割: 全ての防衛線が突破された場合の最終手段
対象: ディスク全体のスナップショット
用途: 災害復旧、フォレンジック調査
トリガー: shutting-down状態検知時

🎯 この多層防御でデータ損失率 0.1% 以下を実現

通常時: 第1防衛線(CloudWatch Logs)で99%カバー
計画的終了: 第2防衛線(ライフサイクルフック)で100%カバー
突然の終了: 第3+4防衛線(定期+シャットダウン)でカバー
最悪のケース: 第5防衛線(EBS Snapshot)で復旧可能

💡 ベストプラクティス

🎯
1. 環境別に適切な方法を選択
本番環境:
• 必ず 方法1(CloudWatch Logs) を採用
• Auto Scaling使用時は 方法2(ライフサイクルフック) を追加
• 多層防御戦略で99.9%以上の信頼性を確保

ステージング環境:
方法5(定期バックアップ) + 方法4(シャットダウンスクリプト) の組み合わせ
• コストを抑えつつ、実用的な信頼性を維持

開発環境:
方法5(定期バックアップ) のみで十分
• または手動バックアップも選択肢
📏
2. ログサイズに応じた戦略
小容量(〜100MB/日):
• CloudWatch Logsが最適。コストも気にならない

中容量(100MB〜1GB/日):
• CloudWatch Logs + 定期バックアップ併用
• 重要ログはCloudWatch、アクセスログは定期保存

大容量(1GB〜/日):
• 定期バックアップ(1時間毎)+ ライフサイクルフック
• CloudWatch Logsはエラーログのみに限定してコスト削減
🔐
3. IAMロールの適切な設定
必須ポリシー:
AmazonS3FullAccess または特定バケットへの書き込み権限
CloudWatchAgentServerPolicy (CloudWatch Logs使用時)
AmazonSSMManagedInstanceCore (Run Command使用時)

セキュリティ:
• 最小権限の原則に従う
• S3バケットポリシーでEC2からのみ書き込み許可
• バケット暗号化(SSE-S3またはSSE-KMS)を有効化
📦
4. ログの圧縮と保存形式
圧縮は必須:
• tar.gz形式で圧縮(70-90%削減)
• S3転送時間とストレージコストの両方を削減

ファイル命名規則:
logs-{instance-id}-{timestamp}.tar.gz
• インスタンスIDと日時を含めて識別容易に

S3ストレージクラス:
• 直近30日: S3 Standard(頻繁アクセス)
• 30-90日: S3 Standard-IA(低頻度アクセス)
• 90日以降: S3 Glacier(アーカイブ)
• ライフサイクルルールで自動移行設定
🔔
5. 監視とアラート設定
必須の監視項目:
• CloudWatch Logs Agentのステータス監視
• S3バケットへのアップロード成功率
• Lambda関数のエラー率(ライフサイクルフック使用時)
• ログファイルサイズの急増検知

アラート設定:
• ログ転送失敗時にSNS通知
• ライフサイクルフックのタイムアウト検知
• S3バケットの容量監視

定期確認:
• 月次でログ退避の成功率をレビュー
• 四半期でリストアテスト実施
💡 実装時の重要ポイント
1. まずは小規模でテスト:
本番環境に導入する前に、必ず開発環境で全ての手法をテストしましょう。
特に、意図的にEC2を終了させて、ログが確実にS3に保存されるか確認。

2. タイムアウト値は余裕を持って:
ネットワーク遅延やS3のAPI制限を考慮し、推定時間の2〜3倍の猶予を設定。
例: 通常30秒で完了するなら、タイムアウトは90秒に設定。

3. リトライロジックを実装:
S3アップロードに失敗した場合、最低3回はリトライする仕組みを組み込む。
エクスポネンシャルバックオフ(再試行間隔を徐々に延ばす)が推奨。

4. ログローテーションとの連携:
ログファイルがローテーションされる前に退避するようスケジュール調整。
例: logrotateが毎日0:00に実行されるなら、バックアップは23:00に。

5. コスト最適化:
CloudWatch Logsは便利だがコストがかかる。重要度に応じてログを分類:
• 超重要(エラーログ、監査ログ)→ CloudWatch Logs
• 重要(アプリケーションログ)→ CloudWatch Logs + S3エクスポート
• 参考(アクセスログ)→ 定期バックアップ直接S3

6. 定期的なリストアテスト:
四半期に1回、実際にS3からログを取り出して復元できるか確認。
「バックアップは取れているが復元できない」という最悪の事態を防ぐ。

7. ドキュメント化:
ログ退避の仕組みを必ずドキュメント化。運用チームが理解できるように。
• どのログがどこに保存されるか
• 緊急時の手動バックアップ手順
• リストア手順

8. 法規制・コンプライアンス対応:
業界によっては、ログの保存期間や方法が法律で定められている場合があります。
• 金融: 7年間の保存義務
• 医療: HIPAA準拠の暗号化必須
• 個人情報: GDPR対応で削除要求への対応が必要

🎓 まとめ

🏢 オフィス退去 = EC2終了

重要な書類(ログ)を倉庫(S3)に移さないと永久に失われる。
突然の閉鎖(強制終了)にも対応できる 多層防御戦略 が鍵!

🏆
本番環境

CloudWatch Logs
+ ライフサイクルフック
信頼性99.9%以上
💰
コスト重視

定期バックアップ
+ シャットダウンスクリプト
ほぼ無料で実用的
🎯
最適解

複数手法の組み合わせ
多層防御で
データ損失を最小化

🎯 決定版の推奨構成:

第1層: CloudWatch Logs(リアルタイム転送)
第2層: ライフサイクルフック(Auto Scaling時)
第3層: 定期バックアップ(コスト最適化)
第4層: シャットダウンスクリプト(最終防衛)
第5層: EBSスナップショット(最終手段)

この 5層防御 でデータ損失率 0.1% 以下を実現!

ログは トラブルシューティング 監査 コンプライアンス の生命線。
「失ってから気付く」では遅い!
今すぐ確実な退避戦略を実装しましょう 🎉

Created by SSuzuki1063

AWS SAP Learning Resources