【入門編】CloudFormationスタックのロールバック失敗(Rollback Completeの罠)からの手動復旧とスタック削除の完全手順 – インフラ構成管理(IaC)活用バイブル

プロフェッショナルな現場において、CloudFormation(CFn)は「宣言的インフラの聖域」です。しかし、その聖域にも魔物が棲んでいます。スタックが「ROLLBACK_FAILED」の状態で凍りつき、コンソールから何をしても動かなくなるあの絶望的な瞬間。

今日は、そんな「スタックの死」に直面したとき、どのようにしてその呪縛を解き、再びインフラを正常な状態へ導くか。現場で震えるほど役に立つ、外科手術レベルの復旧術を伝授します。

—

なぜ「ロールバック失敗」が起きるのか?

まず、この現象の正体を理解しましょう。CFnは、リソースの作成や更新が失敗したとき、自動的に「以前の状態に戻そう」とします。これをロールバックと呼びます。

しかし、手動でリソースを変更してしまったり、IAMの権限が途中で剥奪されたりすると、CFnはこの「戻す作業」すら失敗し、スタックは身動きが取れなくなります。これが「ROLLBACK_FAILED」の正体です。

—

究極の復旧手順:外科的手術のステップ

焦ってコンソールを連打してはいけません。スタックがデッドロック状態にあるときは、以下の手順で冷静に対処します。

1. 犯人を特定する

まず、どのリソースが「死因」なのかを突き止めます。CLIでスタックのイベントを詳細に追いましょう。

スタックのイベントを直近から追いかける
aws cloudformation describe-stack-events –stack-name <スタック名> –query ‘StackEvents[0:10]’

ここで`ROLLBACK_FAILED`の原因となっているリソースの論理IDを特定します。

2. 「ContinueUpdateRollback」という名の特効薬

スタックがまだ「ROLLBACK_FAILED」であれば、CFnには「もう一度ロールバックを試みろ、ただし今回はこのリソースを無視していい」と指示する強力なコマンドがあります。

失敗したリソースを特定し、それを「スキップ(除去)」してロールバックを続行する
aws cloudformation continue-update-rollback \
–stack-name <スタック名> \
–resources-to-skip <論理ID1> <論理ID2>

このコマンドは、いわば「負傷兵を置き去りにして撤退する」判断です。これを実行することで、スタックは再び正常な状態(ROLLBACK_COMPLETE)まで遷移できるようになります。

3. 手動でのリソース切り離し(最終手段)

どうしてもロールバックが完了しない場合、クラウド上のリソースとCFnの紐付けを強制的に断ち切る必要があります。

  • AWSコンソールでの手順:

1. スタックの削除を選択し、「削除オプション」で「保持(Retain)」を選択します。
2. これにより、CFnの管理下からは外れますが、AWS上に残った実リソースは破壊されません。
3. あとは手動で実リソースを削除(あるいはリネーム)し、スタックを空の状態で削除します。

—

これが「最強のHelloWorld」だ

CloudFormationに慣れていない方は、まず「冪等性(べきとうせい)」の概念を体感するために、以下のシンプルなテンプレートを試してください。

`infra.yaml`(HelloWorld)

AWSTemplateFormatVersion: ‘2010-09-09’
Description: SREの第一歩 – 冪等性を理解するS3バケット

Resources:
MyS3Bucket:
Type: ‘AWS::S3::Bucket’
Properties:
# バケット名は全世界で一意である必要があるため、環境や日付を付与する設計が現場の定石
BucketName: !Sub ‘my-s3-bucket-unique-${AWS::AccountId}’

実行コマンド:

スタックの作成
aws cloudformation deploy –template-file infra.yaml –stack-name my-first-stack

動作確認:何度実行してもエラーにならない(これが冪等性)
aws cloudformation deploy –template-file infra.yaml –stack-name my-first-stack

このコマンドを2回実行してみてください。2回目は「No changes to deploy」と返ってきます。これが「何度実行しても同じ結果になる」という、インフラ自動化の神髄です。

—

先輩からの一言

「スタックが壊れた!」とパニックになるのは、あなたが真剣にインフラに向き合っている証拠です。でも、大丈夫。クラウドの世界では、コードで定義されたものは必ずコードで修正できます。

もし今回のようなスタックのフリーズに出会ったら、まずは「そのリソースをスタックから切り離せるか?」を考えてみてください。それができれば、どんな巨大なシステムも、あなたの手元で完全にコントロールできるようになります。

インフラ管理は、破壊と創造の繰り返しです。そのプロセスを恐れず、むしろ楽しんでください。それが、一流のSREへの近道ですよ。

タイトルとURLをコピーしました