困ったこと
CloudFormationスタックの削除を行っていたところ、とあるスタックがUPDATE_ROLLBACK_FAILED状態から抜け出せなくなってしまいました。
この状態になると、スタックの更新も削除もできなくなり、非常に厄介な状況に陥ります。
丸ごと消したいだけなのに〜という悲痛な思いと共にCloudformationと向き合うことにならないよう、こちらに記事を残します。
UPDATE_ROLLBACK_FAILEDとは
CloudFormationスタックの更新が失敗した際、自動的にロールバック（以前の状態に戻す）処理が実行されます。しかし、このロールバック自体も失敗するとUPDATE_ROLLBACK_FAILED状態になります。
よくある原因としては、以下が挙げられます。
- リソースが手動削除された: ロールバック対象のリソースが既に手動で削除されている
- IAM権限不足: ロールバックに必要な権限が不足している
- リソースの状態変更: ロールバック中に対象リソースの状態が変わった
- 循環依存: 複数のスタック間でExport/Importが相互参照している
私の場合は、「1. リソースが手動削除された」と「4. 循環依存」がダブルでのしかかってきましたｗ
実は先に手動で削除してしまったリソースがありそれが原因で詰まってしまったのですが、さらにそれを参照していた別のスタックも削除に失敗するという、非常に面倒な状況になってしまったのです。
手動削除してしまったケースでは、以下のエラーメッセージが表示されていました。
Resource handler returned message: "The security group 'sg-xxxxxxx'
does not exist (Service: Ec2, Status Code: 400, Request ID: xxx)"
(HandlerErrorCode: NotFound)
上記では、SecurityGroupが既に存在しないため、ロールバックが失敗しています。
解決方法
以下のCLIコマンドで助かりました...。
（CLIはローカルで設定してもいいですし、Cloudshellから実行するのも早いです）
ステップ1: 失敗したリソースを特定
まず、UPDATE_ROLLBACK中に失敗したリソースを確認します。
※テーブル形式で出力
aws cloudformation describe-stack-events \
--stack-name sample-stack-01 \
--max-items 100 \
--query 'StackEvents[?ResourceStatus==`UPDATE_ROLLBACK_FAILED`].[Timestamp,LogicalResourceId,ResourceType,ResourceStatusReason]' \
--output table
LogicalResourceId列に表示されるIDが、次のステップで使用する値になります
また、ResourceStatusReason列で失敗の原因を確認できます。
ステップ2: 失敗したリソースでロールバックを続行
ステップ1で確認したLogicalResourceIdを指定して、そのリソースをスキップしながらロールバックを続行させます。
aws cloudformation continue-update-rollback \
--stack-name sample-stack-01 \
--resources-to-skip <LogicalResourceId1> <LogicalResourceId2>
複数のリソースがある場合は、スペース区切りで指定します。
また、指定したリソースがUPDATE_ROLLBACK中に失敗していないものの場合、以下のエラーメッセージが表示されました。必ず失敗したリソースを正しく指定してください。
Only the resources failed during UpdateRollback are allowed to be skipped
ちなみに、スタックがUPDATE_ROLLBACK_FAILED状態ではない場合は以下のメッセージが返されます。
RollbackUpdatedStack cannot be called from current stack status
※全く同じ名前のリソースをAWS管理コンソールから手動で作成することで、
一時的にCloudformationスタックでの参照先でエラーがなくなり、
うまくいく、という方法で解決するケースもありました。
（かなり荒技だと思いますが...）
参考
AWS公式にも同じ対処法がありました。