CloudFormation のスタックが赤くなり、状態に ROLLBACK や FAILED と出た。どこが原因か、そのまま再実行してよいのか、コンソールで手直ししてよいのか分からない。この記事は、コードの書き方ではなく「失敗したあとに何をするか」の順番を扱います。
この記事の結論
- 原因はスタックの状態の名前ではなく、イベントの中の最初の失敗の「状態の理由（Status reason）」にあります。最後の行ではなく、時系列の古い側から読みます。
- よくある原因は、権限の不足・値や名前の誤り・クォータの超過・リソースの安定待ちの時間切れ・EC2 からのシグナルが届かないことです。
- 更新に失敗すると自動でロールバックします。ロールバック自体が失敗（UPDATE_ROLLBACK_FAILED）したら、原因を直してから「ロールバックを続行」します。コンソールなどでの手動変更が原因のことが多いです。
- どうしても戻せないリソースはスキップできますが、テンプレートと実体がずれるので、次の更新の前に揃えます。
- 削除に失敗（DELETE_FAILED）したら、中身を空にする・権限・終了保護を見て、最後の手段としてリソースを残して消します。予防は変更セット・ロールバックトリガー・コンソールで直接触らないことです。
スタックが失敗したら最初に何を見るのか｜イベントの「最初の失敗」と状態の理由
スタックの状態（たとえば UPDATE_ROLLBACK_COMPLETE や DELETE_FAILED）は、結果の名前にすぎません。なぜそうなったかは、スタックのイベントに1行ずつ記録されています。
読み方は3つです。
- スタックの状態を見て、作成・更新・削除のどれで止まったかを知る
- イベントを時系列の古い側から読み、最初に失敗したリソースを探す
- その行の「状態の理由」を読む。ここに原因が書かれている
イベントの最後の行はロールバックの結果であることが多く、原因ではありません。最初の失敗が1つあり、残りはその連鎖で失敗やロールバックが並んでいる、と考えると読みやすくなります。
READ THE EVENTS失敗の読み方
原因は最後の行ではなく、最初の失敗にある
-
状態を見る
作成・更新・削除のどこか
-
古い側から読む
イベントを時系列で
-
最初の失敗
状態の理由を読む
-
原因を分ける
権限・値・上限・待ち
-
直して進める
再実行か続行
CHECK 1ここまでの確認
スタックが失敗したとき、原因を探す最初の場所はどこ?
答えと解説
答え: 2. イベントのうち、時系列で最初に出た失敗の「状態の理由」
最後の行はロールバックの結果であることが多く、原因ではありません。古い側から読み、最初の失敗の理由を探します。「スタックが失敗したら最初に何を見るのか」を読み直してください。
作成・更新で失敗する典型的な原因は何か｜権限・値・クォータ・安定待ち・シグナル
状態の理由を読むと、原因はたいてい次のどれかに分かれます。分け方を先に知っておくと、理由の文を読むときの手がかりになります。
| 原因の種類 | 状態の理由で見るもの | 直し方の向き |
|---|---|---|
| 権限の不足 | 操作を許可されていない、という趣旨の文 | 実行するロールの権限を直す |
| 値や名前の誤り | 不正な値、すでに同じ名前がある、という趣旨の文 | パラメータとテンプレートを直す |
| クォータの超過 | 上限に達した、という趣旨の文 | 上限を引き上げるか、数を減らす |
| 安定待ちの時間切れ | リソースが目的の状態にならなかった、という趣旨の文 | そのリソース側の状態と依存を調べる |
| シグナルが届かない | 待っていた成功の通知が来なかった | 通知を送る側を直す |
最初の3つは、再実行しても同じ結果になります。理由を読まずに再実行を繰り返すと、時間だけが過ぎます。
待っている相手から応答が来ないとき
最後の2つは「待つ仕組み」が絡みます。
EC2 インスタンスの起動後に、ユーザーデータでアプリを入れる場合を考えます。インスタンスが起動した時点でリソースを「作成完了」とすると、アプリの準備はまだ終わっていないかもしれません。そこで CreationPolicy を設定し、インスタンス側が準備を終えた時点で cfn-signal で成功を知らせます。時間内にシグナルが届かないと、CloudFormation は作成を失敗として扱います。失敗したときは、インスタンスの中のセットアップが終わっていたか、シグナルが送られたか、を疑います。
カスタムリソースも同じ型です。Lambda 関数を使ったカスタムリソースは、CloudFormation から渡される署名付き URL（ResponseURL）へ、成功か失敗の応答を返す必要があります。応答が無いと、スタックは CREATE_IN_PROGRESS のまま待ち続け、最後にタイムアウトで失敗します。この場合は CloudFormation の側ではなく、関数が応答を返しているかを調べます。
CHECK 2ここまでの確認
UPDATE_ROLLBACK_FAILED になる主な原因として、公式が挙げるものはどれ?
答えと解説
答え: 2. スタックの外で行われた変更（削除など）で、実体が CloudFormation の想定と合わなくなった
CloudFormation は削除済みのリソースがまだ在るものとして元に戻そうとし、そこで失敗します。原因を直してからロールバックを続行します。「ロールバックとは何か」の章を読み直してください。
ロールバックとは何か｜更新失敗で元に戻る動きと、失敗したときの続行・スキップ
スタックの更新に失敗すると、CloudFormation は更新前の状態へ自動で戻します。これがロールバックです。戻しきれば、スタックは更新前の姿のまま残り、直して再挑戦できます。
困るのは、ロールバック自体が失敗したときです。状態は UPDATE_ROLLBACK_FAILED になり、そのままでは新しい更新も受け付けません。公式が挙げる主な原因は、スタックの外で行った変更です。たとえばコンソールでリソースを削除してしまうと、CloudFormation は「まだ在るもの」として元に戻そうとし、実体と合わずに失敗します。
対処は順番で考えます。
- イベントを読み、ロールバックが失敗したリソースと理由を特定する
- 理由の原因を直す（消したリソースを戻す、権限を直す、など）
- 「ロールバックの続行」を実行する
どうしても戻せないリソースは、続行のときにスキップできます。ただしスキップしたリソースは、テンプレートの定義と実体がずれたままになります。そのまま次の更新に進むと別の失敗の元になるので、更新の前に実体をテンプレートへ合わせるか、テンプレートの側を実体に合わせます。
TWO ROADS更新失敗のあと
ロールバックが終わったか、失敗したかで道が分かれる
ロールバック完了
- 更新前の状態に戻っているスタックは使える
- 理由を直して再挑戦同じ更新をやり直す
ロールバック失敗
- 原因を直してから続行手動変更の跡が多い
- 戻せないものはスキップ実体とテンプレートがずれる
操作の画面そのものは改定で変わるため、ここでは書きません。最新の手順は公式のトラブルシューティングを開いてください。
CHECK 3ここまでの確認
中身が残っている S3 バケットを含むスタックの削除が失敗したとき、まず何をする?
答えと解説
答え: 2. バケットの中身を空にしてから、もう一度削除する
中身を空にしないと消せないリソースがあります。原因を直さずに再実行しても同じ結果になります。「削除に失敗したときはどうするのか」を読み直してください。
削除に失敗したときはどうするのか｜空にする・終了保護・リソースを残して消す
スタックの削除が失敗すると DELETE_FAILED になります。見る場所は、更新のときと同じく、イベントの最初の失敗の理由です。代表的な原因と直し方は次のとおりです。
| 原因 | 考え方 | 直し方 |
|---|---|---|
| 中身が残っている S3 バケット | 空にしないと消せないリソースがある | 中身を空にして、もう一度削除する |
| 権限の不足 | 削除を実行する側の権限が足りない | ロールの権限を直して再実行する |
| 終了保護が有効 | 削除の操作そのものを失敗させる設定 | 意図した削除なら、保護を外してから実行する |
| 他のスタックが参照している | エクスポートをインポート中は元を消せない | 参照している側を先に直す |
終了保護は「誤って消す事故」を防ぐ設定なので、失敗は仕様どおりの動きです。理由に終了保護とあれば、本当に消してよいかを確認してから外します。
それでも消えないリソースがあるときは、最後の手段として、そのリソースを残したままスタックだけを削除できます。残したリソースはスタックの管理から外れるので、あとで手で片づける対象として控えておきます。
削除時の扱いは、事前にテンプレートで決めておくこともできます。DeletionPolicy を Snapshot にすると、RDS などでは削除の前にスナップショットが残ります。「消えたあとにも残したいもの」は、削除に失敗してから考えるより、作るときに決めておく方が安全です。
CHECK 4ここまでの確認
本番スタックの更新で、適用する前に影響を見たいときに使うのはどれ?
答えと解説
答え: 1. 変更セット
変更セットは更新前のプレビューです。終了保護は削除操作を止める設定で、役割が違います。「失敗を減らす運用」の章を読み直してください。
失敗を減らす運用｜変更セットで先に見る、ロールバックトリガーで止める、コンソールで直接触らない
失敗への対応を覚えるより、起きにくくする方が楽です。予防は3段で考えます。
PREVENT予防の3段
失敗は前・最中・平時の3段で減らす
-
更新前
変更セットで影響を先に見る
置き換えの有無を確認
-
更新中
ロールバックトリガーで止める
アラームが ALARM で戻す
-
平時
ドリフト検出で手動変更を見つける
定義と実体の差を出す
- 更新の前: 変更セット。 適用前に、どのリソースが変更され、置き換え（作り直し）になるかをプレビューします。データベースのように作り直しで困るものがあるかを、実行前に確認できます。
- 更新の最中と後: ロールバックトリガー。 CloudWatch のアラームを指定しておくと、更新中や更新後の監視時間にアラームが ALARM になった時点で、CloudFormation が更新をロールバックします。監視時間は 0〜180 分で、アラームは最大 5 つまで指定できます。エラー率のようなアプリ側の異常を、スタックの失敗として扱えます。
- 平時: ドリフト検出。 コンソールでの手動変更は、ロールバック失敗の主な原因です。ドリフト検出を実行すると、テンプレートの定義と実際の設定の差が、プロパティ単位で分かります。
事故そのものを減らす手段もあります。スタックポリシーで重要なリソースの置き換えや削除を拒否しておくと、テンプレートの誤った変更が本番のデータベースに届くのを止められます。
どれも「スタックで作ったものは、スタックの外から変えない」という前提の上に成り立ちます。障害対応で急ぎコンソールを触ったなら、あとでテンプレートへ反映するか、元に戻すところまでを作業に含めます。変更セットとドリフト検出の細かい使い方は、cloudformation-toha に任せます。
READ ALSO — プロフェッショナル向け・段4 設計
AWS CloudFormation とは何か｜変更セット・ドリフト・StackSets で基盤をコードで持つ設計の入口
失敗対応の手順書にまとめる｜状態ごとの「見る・直す・次の一手」の表
最後に、状態ごとの対応を1枚にまとめます。チームの手順書にそのまま写せる形です。
| 状態 | まず見るもの | 直す | 次の一手 |
|---|---|---|---|
| 作成や更新の失敗 | イベントの最初の失敗の理由 | 権限・値・クォータ・待つ相手を直す | 直してから再実行する |
| 更新のロールバックが完了 | 失敗の理由 | 同上 | 更新前の状態に戻っているので、再挑戦する |
| UPDATE_ROLLBACK_FAILED | ロールバックが失敗したリソース | 手動変更の跡や権限を直す | ロールバックを続行する。戻せないものだけスキップする |
| DELETE_FAILED | 削除が失敗したリソースの理由 | 空にする・権限・終了保護・参照を見る | 再削除する。最後の手段はリソースを残して消す |
| スキップのあと | 実体とテンプレートの差 | 実体かテンプレートを合わせる | 次の更新の前に差を解消する |
Cloudory 執筆者（AWS 認定 全冠）
失敗した直後は、画面の赤い状態に目が行きます。状態の名前ではなく、イベントの古い側から最初の失敗を読む。この1つを手順書の1行目に置いておけば、そのあとの判断（直す・続ける・残す）は表のとおりに進められます。
READ ALSO — 学習中向け・段2 構成
IaC とは何か｜手作業との違いと宣言型、CloudFormation・CDK・Terraform の位置づけ
参照ソース
- AWS CloudFormation ユーザーガイド｜トラブルシューティング — 失敗時の確認手順（イベントと状態の理由）、DELETE_FAILED・UPDATE_ROLLBACK_FAILED の原因と対処、ロールバックの続行とリソースのスキップの根拠に使用
- AWS CloudFormation ユーザーガイド｜ロールバックトリガー — CloudWatch アラームによるロールバック、監視時間とアラーム数の上限の根拠に使用
