AWS Step Functions を使用した EC2 自動バックアップ・パッチ・復元システムの設計と実装

フェイス・ソリューション・テクノロジーズ株式会社IS本部OSユニットのimaiです。
今回は、AWS Step Functions を使用して EC2インスタンスの自動バックアップ、パッチ適用、失敗時の自動復元を行うシステムの設計と実装について詳しく解説します。CloudFormation を使用した Infrastructure as Code の実装例も含まれています。

はじめに

EC2インスタンスへのパッチ適用は、セキュリティとシステムの安定性を保つために不可欠な作業です。しかし、パッチ適用は常にリスクを伴います。パッチ適用後にアプリケーションが動作しなくなる、システムが起動しなくなるといった問題が発生する可能性があるからです。

この記事では、そのようなリスクを最小限に抑えるための自動化システムを AWS Step Functions で構築する方法を解説します。
システムの特徴は以下の通りです：

自動バックアップ: パッチ適用前に現在の状態をバックアップ
安全なパッチ適用: バックアップ後にパッチを適用
自動復元: パッチ適用失敗時に自動的に元の状態に復元
完全自動化: 人間の介入なしで安全な運用を実現

システム全体像

解決する課題

運用における課題

パッチ適用のリスク: システムが動作しなくなる可能性
問題発生時の対応困難: 手動での復旧に時間がかかる
運用負荷: 定期的なパッチ適用作業の負担

システムのワークフロー

システムは以下の5つのフェーズで構成されています：

1. EC2停止 – 整合性のあるバックアップを取得するため

2. バックアップ取得 – AWS Backup を使用して現在の状態を保存

3. EC2起動 – バックアップ完了後にインスタンスを起動

4. パッチ適用 – AWS Systems Manager を使用してパッチを適用

5. 自動復元 – パッチ適用失敗時にバックアップから復元

AWS Step Functions の基本

Step Functions とは

AWS Step Functions は、複数の AWS サービスを順序立てて実行し、1つのワークフローとして管理できるサーバーレスなワークフローエンジンです。

Step Functions の特徴

視覚的: ワークフローが図で表示され、実行状況が一目で分かる
信頼性: 自動リトライ機能とエラーハンドリング機能を内蔵
サーバーレス: インフラ管理不要で、使用量に応じた課金

ステートマシンの構成要素

Step Functions は「States（状態）」をつなげて処理を実現します。
主要なステートタイプは以下の通りです：

ステートタイプ	用途
Task	API呼び出し、Lambda実行
Wait	待機時間の制御
Choice	条件分岐
Parallel	並列実行

ワークフロー設計の詳細

フェーズ1: EC2停止

バックアップを取得する前に、EC2インスタンスを安全に停止します。

StopEC2Instance:
Type: Task
Resource: arn:aws:states:::aws-sdk:ec2:stopInstances
Parameters:
InstanceIds: [${InstanceIdToken}]
ResultPath: $.InstanceResult
Next: WaitForStop

処理フロー:

Task: ec2:stopInstances APIを呼び出し
Wait: 30秒待機（停止処理の完了を待つ）
Choice: 状態をチェックして分岐
- 「stopped」→ 次のフェーズへ
- 「stopping」や「running」→ 再実行
- その他 → エラー通知

フェーズ2: バックアップ取得

AWS Backup を使用して現在の状態をバックアップします。

StartEC2BackupJob:
Type: Task
Parameters:
BackupVaultName: ${BackupVaultNameToken}
IamRoleArn: ${BackupStartBackupJobIamRoleArn}
ResourceArn.$: >-
States.Format('arn:aws:ec2:{}:{}:instance/{}',
'${AWSRegionToken}', '${AWSAccountIdToken}',
$.InstanceResult.InstanceId)
Resource: arn:aws:states:::aws-sdk:backup:startBackupJob
Next: WaitForBackupProgress

ポーリングパターン:

バックアップは非同期処理のため、完了まで待つ必要があります。
以下のパターンで実装します：

Wait: 60秒待機
Task: backup:listBackupJobs で状態確認
Choice: 状態判定
- 「RUNNING」→ 再待機
- 「COMPLETED」→ 次のフェーズへ
- 「FAILED」→ エラー通知

フェーズ3: EC2起動

バックアップ完了後にインスタンスを起動します。
起動は2段階でチェックします：

重要: インスタンス状態が「running」でも、SSMが利用可能になるまで時間がかかります。システム状態が「ok」になるまで待つ必要があります。

状態	Instance	System	SSM
起動直後	running	initializing	❌
完全起動	running	ok	✓

フェーズ4: パッチ適用

AWS Systems Manager を使用してパッチを適用します。

RunPatchBaseline:
Type: Task
Parameters:
DocumentName: AWS-RunPatchBaseline
Parameters:
Operation:
- Install
Targets:
- Key: InstanceIds
Values.$: States.Array($.InstanceResult.InstanceId)
Resource: arn:aws:states:::aws-sdk:ssm:sendCommand
Next: WaitForPatchCommand

成否判定:

ResponseCode = 0: 成功 → 完了通知
ResponseCode ≠ 0: 失敗 → 復元フェーズへ

フェーズ5: 自動復元

パッチ適用失敗時に、バックアップから自動復元します。

復元の流れ:

backup:listRecoveryPointsByBackupVault – 復旧ポイント取得
backup:getRecoveryPointRestoreMetadata – 復元メタデータ取得
backup:startRestoreJob – 復元ジョブ開始
sns:publish – 通知送信

エラーハンドリング戦略

システムは4種類のエラーシナリオに対応しています：

フェーズ	エラー時の動作
EC2停止	即座に終了 → SNS通知
バックアップ	即座に終了 → SNS通知
EC2起動	即座に終了 → SNS通知
パッチ適用	自動復元 → SNS通知

Choice ステートによる分岐

条件に応じて処理を分岐させる Choice ステートの実装例：

CheckStopStatus:
Type: Choice
Choices:
- Or:
- Variable: $.InstanceResult.CurrentState
StringEquals: pending
- Variable: $.InstanceResult.CurrentState
StringEquals: running
- Variable: $.InstanceResult.CurrentState
StringEquals: stopping
Next: StopEC2Instance
- Variable: $.InstanceResult.CurrentState
StringEquals: stopped
Next: StartEC2BackupJob
Default: NotifyStopFailed

重要: Choice ステートでは必ず Default 分岐を設定してください。想定外の状態でワークフローが止まることを防げます。

CloudFormation での実装

Infrastructure as Code のメリット

再現性: 同じ環境を何度でも確実に構築
バージョン管理: Git で変更履歴を管理
自動化: CI/CD パイプラインに組み込み可能
ドキュメント: コードが仕様書となる

主要リソースの構成

CloudFormation テンプレートには以下のリソースが含まれています：

Step Functions ステートマシン – メインのワークフロー
AWS Backup バックアップボールト – バックアップの保存
EC2 インスタンス – 対象となるインスタンス
SNS トピック – 通知用
IAM ロール – 各サービスに必要な権限
VPC 関連リソース – ネットワーク構成

デプロイ方法

aws cloudformation create-stack \
--stack-name ec2-backup-patch-restore \
--template-body file://stepfunctions-ec2-backup-patch-restore.yaml \
--capabilities CAPABILITY_NAMED_IAM

設計のポイント

1. フェーズ分割

大きな処理を小さな状態に分解し、各状態は単一責任を持たせます。
これにより：

テストしやすくなる
デバッグしやすくなる
可視化しやすくなる
監視しやすくなる

2. ポーリングパターン

非同期処理の完了を待つ標準的なパターンです。Wait → Task → Choice のサイクルで実装します。

Task → Wait → Task → Choice
↑ ↓
└── ループバック ───┘

3. データフロー管理

Step Functions では各ステート間でデータを渡していきます。
重要なポイント：

ResultPath: 結果の格納場所を制御
ResultSelector: 必要なデータのみを抽出
データサイズ制限: 256KB まで

4. IAM ロール設計

最小権限の原則に従い、必要最小限の権限のみを付与します：

サービス	権限	制限
EC2	Stop/Start/Describe	特定インスタンス
Backup	Start/Describe	タグ付きリソース
SSM/SNS	SendCommand/Publish	条件付き

運用とモニタリング

CloudWatch Logs

Step Functions の実行履歴は CloudWatch Logs に記録されます。トラブルシューティング時に重要な情報源となります。

SNS 通知

すべてのエラーケースで SNS 通知を送信します。
通知先は以下のように設定できます：

メール
SMS
Slack（Lambda 経由）
Microsoft Teams（Lambda 経由）

コスト監視

Step Functions の料金は状態遷移回数に基づきます。Standard タイプでは状態遷移1回あたり 0.025ドル（約2.5円）です。

拡張のアイデア

機能拡張

複数インスタンス: Map ステートで並列処理
スケジュール実行: EventBridge で定期実行
承認フロー: Task Token で承認待ち

運用強化

通知の充実: Slack/Teams 連携
テスト環境: ステージング環境での事前テスト
監視の強化: カスタムメトリクス

まとめ

本記事では、AWS Step Functions を使用した EC2 自動バックアップ・パッチ・復元システムの設計と実装について詳しく解説しました。

学んだポイント

Step Functions の基本概念 – ステートマシンとステートの役割
ワークフロー設計 – フェーズ分割とポーリングパターン
エラーハンドリング – すべてのケースに対応する設計
Infrastructure as Code – CloudFormation での実装

このシステムをベースに、要件に応じて機能を拡張していくことで、より堅牢で運用しやすい自動化システムを構築できます。

次のステップ

学習リソース: AWS StepFunctions 公式ドキュメント、StepFunctions Workshop
実践: 小さなワークフローから始めて、徐々に複雑なものに挑戦
コミュニティ: AWS re:Post、Serverless Land Patterns

Step Functions の柔軟性を活かして、最適なワークフローを構築してみてください！