🏢 オフィス退去時の書類整理でたとえると超わかりやすい!
EC2終了 = オフィスを閉鎖して退去すること
オフィスを閉める前に、重要な書類(ログ)を必ず倉庫(S3)に移さないと永久に失われます。
でも、
「明日閉鎖します」と言われても
書類整理が間に合わないかも...
「今すぐ出て行け!」と言われたら
何も持ち出せません。
この問題を解決する
5つの戦略
を完全解説します✨
どの方法が
確実
で
実用的
か、シナリオ別に徹底比較!
🏢 オフィス退去の書類整理戦略
あなたの会社は、プロジェクト終了後にオフィスを閉鎖することになりました。
オフィス内には過去1年分の重要な業務記録(ログファイル)が保管されています。
問題:
オフィス閉鎖(EC2終了)と同時に、そこにある全ての書類は処分されます。
倉庫(S3)に移動しておかないと、永久に失われます。
でも、退去のタイミングは予測できないことも...
• 計画的な閉鎖: 「来週の金曜日に退去します」
• 突然の閉鎖: 「今日中に出て行ってください!」
• 緊急の閉鎖: 「今すぐ退去!」(火災、強制退去など)
→ 書類が作成されるたびに、即座に倉庫へコピー。最も確実!
戦略2: 退去通知を受けて移動(ライフサイクルフック)
→ 「明日退去です」という通知を受けて、猶予時間内に移動作業
戦略3: 閉鎖イベントを検知して緊急移動(EventBridge + Lambda)
→ 退去が始まった瞬間に検知して、外部から救出作業を実施
戦略4: 退去時に自動実行(シャットダウンスクリプト)
→ ドアを閉める直前に自動で書類を送信する仕組み
戦略5: 定期的に移動(スケジュールバックアップ)
→ 毎日自動で倉庫へコピー。退去時は最新分だけ残る
🎯 5つの退避方法 - 完全解説
オフィスが突然閉鎖されても、全ての書類は既に倉庫に保管済み。
例: 社員が報告書を書くたびに、同時に本社の倉庫にもコピーが自動送信される。
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のインストール 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
• コンプライアンス 要件がある場合
• 突然の終了 にも対応が必要
• 長期保存 が必要なログ
• 複数インスタンス のログを集約したい
→ 最も推奨される方法です!
「あと1時間で退去です。それまでに書類を整理してください」という猶予期間。
例: ビル管理会社から「19:00に施錠します」と18:00に連絡が入り、1時間で片付ける。
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 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 )
• スケールイン時 のログ保存
• 大容量ログ (数GB以上)の転送
• CloudWatch Logsのコスト を抑えたい
• 計画的な終了 が多い環境
→ Auto Scaling環境では非常に有効!
社員が退去した後でも、外部から遠隔で書類を取り出せる仕組み。
例: ビル管理会社が「このオフィス閉鎖開始」と察知し、即座に重要書類回収チームを派遣。
shutting-down
)を監視
2. インスタンスが stopping または shutting-down 状態になったらLambdaトリガー
3. Lambda関数がRun Commandでログ退避を実行
4. または、EBSスナップショットを即座に作成
注意:
terminated
状態では遅すぎる。
shutting-down
や
stopping
を検知する必要がある。
- 汎用性: あらゆる終了パターンに対応
- 手動終了も検知: コンソールからの終了も対応
- 自動化: 人手不要で実行
- 柔軟性: スナップショット作成など他の処理も可能
- タイミング問題: 状態変化検知からLambda起動まで数秒のラグ
- 処理時間制限: Lambdaは最大15分。大量ログには不向き
- 確実性: インスタンスが即座に停止すると間に合わない可能性
-
強制終了:
terminated状態では手遅れ
# 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程度)の即座転送
→ メインの方法ではなく、保険として使用
最後の人が退出すると、センサーが反応して自動で倉庫へ書類を送る。
例: 退出時に自動でシュレッダーが動くように、ログ送信スクリプトが動く仕組み。
2. OSがシャットダウン開始すると自動実行
3. スクリプトでログファイルをtar.gz化してS3へアップロード
4. 完了後、OSがシャットダウンを継続
設定場所:
• systemd:
/etc/systemd/system/log-backup.service
• 古いシステム:
/etc/rc0.d/
(シャットダウン時実行)
- シンプル: 追加のAWSサービス不要
- 無料: AWS料金なし(S3ストレージ除く)
- 確実な起動: OS標準機能で実行保証
- あらゆる終了に対応: 再起動・シャットダウン両方
- 時間制限: OSのシャットダウンタイムアウト(通常90秒)
- 強制終了は不可: 電源断、クラッシュには無力
- 大容量は困難: タイムアウトで中断される可能性
- エラー処理困難: 失敗時のリトライなし
- 監視不可: 実行状況の可視化が難しい
# /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
Linuxのシャットダウンプロセスは、各サービスに通常90秒の猶予を与えます。
これを超えると強制終了(SIGKILL)されます。
大容量ログは不可:
• 1GBのログを90秒でアップロードするには約90Mbpsの速度が必要
• ネットワーク遅延や圧縮時間も考慮すると、実質的には数百MB程度が限界
→ 小〜中容量のログ専用
• 小容量ログ (数十〜数百MB)
• シンプルさ重視 (複雑な設定を避けたい)
• 予算制約 (追加コストなし)
• 開発・テスト環境
→ シンプルだが制約が多い。本番環境では非推奨
突然の閉鎖が起きても、最悪でも1日分の書類を失うだけで済む。
例: 毎晩23:00に自動で今日の報告書を本社へ送信。明日急に閉鎖されても昨日までの分は安全。
2. または、 EventBridge (CloudWatch Events) で定期実行
3. ログファイルを圧縮してS3へアップロード
4. 前回バックアップ以降の 差分のみ を転送(rsyncやaws s3 sync使用)
5. EC2終了時は、最後のバックアップ〜終了までの分だけ失われる
データ損失: バックアップ間隔分のログが失われる可能性(1時間毎なら最大1時間分)
- シンプル: cronやEventBridgeで簡単に実装
- 低コスト: 追加のAWSサービスほぼ不要
- 柔軟性: バックアップ頻度を自由に調整
- 大容量対応: 時間制限なく大量ログも可能
- 軽量: リアルタイム転送より負荷が低い
- データ損失: 最後のバックアップ以降のログは失われる
- 完全性なし: 100%の保証はない
- 頻度とコスト: 頻繁にすると転送コスト増加
- 遅延: リアルタイムではない
# /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
1. 定期バックアップ (この方法)で大部分を保存
2. シャットダウンスクリプト (方法4)で最後の差分を保存
この組み合わせで、データ損失を最小限にできます!
例: 1時間毎に定期バックアップ + シャットダウン時に最後の1時間分を保存
→ ほぼ完全なログ保存が低コストで実現
• 多少のデータ損失は許容 できる環境
• 大容量ログ の定期バックアップ
• 開発・ステージング環境
• 方法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%以上の信頼性 を実現
対象: 全てのアプリケーションログ、システムログ
メリット: どんな終了パターンでも99%のログは既に保存済み
コスト: 中程度(でも最も確実)
対象: CloudWatch Logsでカバーしきれない一時ファイル、大容量データ
メリット: 猶予時間内に確実に転送完了
適用条件: Auto Scalingを使用している場合のみ
対象: アクセスログなど容量の大きいログ
頻度: 1時間毎または1日毎
メリット: コストを抑えつつ、ほぼ全てのログを保存
対象: 定期バックアップの最後の差分
メリット: ほぼ0コストで最後のチャンス
制約: 90秒タイムアウトがあるため小容量のみ
対象: ディスク全体のスナップショット
用途: 災害復旧、フォレンジック調査
トリガー: shutting-down状態検知時
🎯 この多層防御でデータ損失率 0.1% 以下を実現
通常時:
第1防衛線(CloudWatch Logs)で99%カバー
計画的終了:
第2防衛線(ライフサイクルフック)で100%カバー
突然の終了:
第3+4防衛線(定期+シャットダウン)でカバー
最悪のケース:
第5防衛線(EBS Snapshot)で復旧可能
💡 ベストプラクティス
• 必ず 方法1(CloudWatch Logs) を採用
• Auto Scaling使用時は 方法2(ライフサイクルフック) を追加
• 多層防御戦略で99.9%以上の信頼性を確保
ステージング環境:
• 方法5(定期バックアップ) + 方法4(シャットダウンスクリプト) の組み合わせ
• コストを抑えつつ、実用的な信頼性を維持
開発環境:
• 方法5(定期バックアップ) のみで十分
• または手動バックアップも選択肢
• CloudWatch Logsが最適。コストも気にならない
中容量(100MB〜1GB/日):
• CloudWatch Logs + 定期バックアップ併用
• 重要ログはCloudWatch、アクセスログは定期保存
大容量(1GB〜/日):
• 定期バックアップ(1時間毎)+ ライフサイクルフック
• CloudWatch Logsはエラーログのみに限定してコスト削減
•
AmazonS3FullAccess
または特定バケットへの書き込み権限
•
CloudWatchAgentServerPolicy
(CloudWatch Logs使用時)
•
AmazonSSMManagedInstanceCore
(Run Command使用時)
セキュリティ:
• 最小権限の原則に従う
• S3バケットポリシーでEC2からのみ書き込み許可
• バケット暗号化(SSE-S3またはSSE-KMS)を有効化
• tar.gz形式で圧縮(70-90%削減)
• S3転送時間とストレージコストの両方を削減
ファイル命名規則:
•
logs-{instance-id}-{timestamp}.tar.gz
• インスタンスIDと日時を含めて識別容易に
S3ストレージクラス:
• 直近30日: S3 Standard(頻繁アクセス)
• 30-90日: S3 Standard-IA(低頻度アクセス)
• 90日以降: S3 Glacier(アーカイブ)
• ライフサイクルルールで自動移行設定
• CloudWatch Logs Agentのステータス監視
• S3バケットへのアップロード成功率
• Lambda関数のエラー率(ライフサイクルフック使用時)
• ログファイルサイズの急増検知
アラート設定:
• ログ転送失敗時にSNS通知
• ライフサイクルフックのタイムアウト検知
• S3バケットの容量監視
定期確認:
• 月次でログ退避の成功率をレビュー
• 四半期でリストアテスト実施
本番環境に導入する前に、必ず開発環境で全ての手法をテストしましょう。
特に、意図的に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% 以下を実現!
ログは
トラブルシューティング
、
監査
、
コンプライアンス
の生命線。
「失ってから気付く」では遅い!
今すぐ確実な退避戦略を実装しましょう 🎉