[アップデート] AWS CloudFormation の「更新ロールバックを続ける」の高度なトラブルシューティングオプションに「強制ロールバック」が追加され、戻せないリソースをまとめてスキップできるようになりました

この What's New の URL ちょっと雑だな、と思いました。

2026.10.25

いわさです。
AWS CloudFormation のスタック更新が失敗すると、更新前の状態に戻すロールバックが実行されます。

この時に特定リソースでドリフトが発生していたりなどでロールバック自体も失敗すると、スタックは UPDATE_ROLLBACK_FAILED という状態になり、スタックの更新もキャンセルも出来ない状態になります。
その時「更新ロールバックを続ける」から原因リソースをスキップするなどで復旧操作ができるのですが、先日のアップデートで「強制ロールバック」というオプションがここに追加されました。
https://aws.amazon.com/about-aws/whats-new/2026/10/aws-cloudformation-cdk/
どこが変更点だったのかわからなかったので調べながらやってみたのですが、一通り整理できたので記事にしてみます。
 実際に確認してみる事前に UPDATE_ROLLBACK_FAILED 状態のスタック存在する状態を作っておきます。

スタック作成手順は割愛しますが、ロールバックが失敗するのは更新前の状態に戻そうとしたときに戻し先のリソースを復元できないようなケースで、公式ドキュメントでは、CloudFormation の外で削除された古いデータベースに戻そうとして失敗する例が挙げられています。

CloudFormation はそのデータベースがまだあると思って戻そうとするので、ロールバックが失敗するみたいな感じみたい。
A stack enters the UPDATE_ROLLBACK_FAILED state when CloudFormation can't roll back all changes after a failed stack update. For example, this might occur when a stack attempts to roll back to an old database that was deleted outside of CloudFormation.
https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ContinueUpdateRollback.html
スタック更新がエラーになってロールバックが始まり、そのロールバックの途中で特定リソースのロールバックに失敗して、スタックが UPDATE_ROLLBACK_FAILED で止まっています。

このUPDATE_ROLLBACK_FAILED のスタックは更新操作を受け付けないので、まずはロールバックを完了させて正常な状態に戻す必要があります。
復旧はコンソールのスタックアクションから「更新ロールバックを続ける」を選びます。
ダイアログが表示されますが、たいていの場合はこのままだとロールバック続行に失敗します。

なのでダイアログの「高度なトラブルシューティング」を開いてロールバックに失敗したリソースをスキップさせるのがよくあるやり方です。
「Skip specific resources」が従来からある方法で、スキップするリソースを自分で選ぶ方法です。

そして今回追加されたのが「Force rollback」です。これが強制ロールバックで、ロールバックに失敗したリソースを CloudFormation がまとめてスキップしてくれます。
まず強制ロールバックを使わずに、そのままロールバックを続けてみます。
原因になっているリソースの失敗は直せない前提です。

ステータスは次のように一度処理中になったのですが、また失敗になってしまいました。
UPDATE_ROLLBACK_IN_PROGRESS
UPDATE_ROLLBACK_FAILED
従来はここで「Skip specific resources」を選び、スキップするリソースを指定してとりあえずスタックロールバックを完了させていました。

先ほどのダイアログでロールバックに失敗したリソースが出てくるので、スキップしたいものにチェックを入れる感じです。
今回追加された機能では次のように強制的に失敗したリソースをスキップしてくれます。
どっちでも良いんじゃないの？って最初思ったのですが、ドキュメントを見た感じだとネストされたスタックの場合、子スタックの中で失敗したリソースはこのダイアログで選択できないようですが、強制ロールバックの場合だと
ただしネストされたスタックの場合、子スタックの中で失敗したリソースはこの一覧には出ず、対象を特定して指定する必要があるようです。

これが今回の強制ロールバックなら、ネストの全階層をまとめてスキップできるようです。なるほど。
CloudFormation skips each resource that is in the UPDATE_FAILED state because a rollback failed, including resources in nested stacks. CloudFormation sets the status of each skipped resource to UPDATE_COMPLETE with the status reason Resource skipped during UpdateRollback.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-continueupdaterollback.html#nested-stacks
強制ロールバック（Force rollback）を選んで実行した場合、今度は次のようにロールバックステータスが完了までいきました。
UPDATE_ROLLBACK_IN_PROGRESS
UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS
UPDATE_ROLLBACK_COMPLETE
スキップするリソースを自分で選ばなくても復旧できていますね。
なお、スタックのイベントを見ると、スキップされたリソースが Resource skipped during UpdateRollback という理由で UPDATE_COMPLETE に記録されていました。

スタック全体の状態理由にも、スキップしたリソースがある旨と、次の更新前にドリフト検出で状態を確認するようにというメッセージが残るみたいですね。
One or more resources were skipped during UpdateRollback. These resources were not rolled back and may have drifted from the template. Run drift detection (DetectStackDrift) to review their current state before your next update.
 さいごに本日は CloudFormation に追加された強制ロールバックを確認してみました。
ネストされたスタックとかでも試してみたのですが、これよくわからなかったです。

従来のスキップリソースを指定するやり方のほうが使いやすいような気もします。

一方で AWS CLI とか API 経由の場合だとスキップするリソースの指定がちょっと大変なので、スクリプトとかで強制的にスキップさせたい時には使えるのかもしれません。
いい感じの使い方知ってる方、教えてください。