更新のロールバックを続ける
時折、CloudFormation がスタック更新のロールバックを試みるときに、更新プロセス中に行ったすべての変更をロールバックできない場合があります。これは、UPDATE_ROLLBACK_FAILED 状態と呼ばれます。例えば、CloudFormation の外部で削除された古いデータベースのインスタンスにロールバックを開始するスタックがある場合などです。CloudFormation にはデータベースが削除されたことがわからないため、データベースインスタンスがまだ存在する前提でそれにロールバックしようとし、更新のロールバックが失敗します。
UPDATE_ROLLBACK_FAILED 状態のスタックは更新できませんが、動作状態 (UPDATE_ROLLBACK_COMPLETE) にロールバックできます。スタックを元の設定に戻すと、もう一度更新を試行することができます。
ほとんどの場合、スタックのロールバックを続けるには、更新のロールバックが失敗する原因となるエラーを修正する必要があります。それ以外の場合(たとえば、スタック操作のタイムアウト)では、変更を加えずに更新のロールバックを続けることができます。
注記
ネストされたスタックを使用する場合には、親スタックをロールバックすると、すべての子スタックも同じような転送を試みます。
更新のロールバックを続けるには (コンソール)
AWS Management Console にサインインし、AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation
) を開きます。 -
画面の上部のナビゲーションバーで、スタックが所在する AWS リージョン を選択します。
-
[Stacks] ページで、更新するスタックを選択し、[スタックアクション]、[更新のロールバックの続行] の順に選択します。
エラーのトラブルシューティング の解決策でも解決できなかった場合は、高度なオプションを使用して、CloudFormation が正常にロールバックできないリソースをスキップできます。スキップするリソースの論理 ID を検索して入力する必要があります。更新の転送中ではなく、
UpdateRollback中にUPDATE_FAILED状態になったリソースのみを指定します。警告
CloudFormation は指定されたリソースのステータスを
UPDATE_COMPLETEに設定し、引き続きスタックをロールバックします。ロールバックが完了したら、スキップされたリソースのステータスはスタックテンプレートのリソースのステータスと一致しません。別のスタックの更新を実行する前に、スタックまたはリソースを更新して、整合性を取る必要があります。そうしないと、以降のスタックの更新が失敗して、スタックが回復不可能になる可能性があります。スタックを正常にロールバックするために必要なリソースの最小数を指定します。たとえば、あるリソース更新が失敗したために、それに依存するリソースが失敗することがあります。この場合、依存リソースをスキップする必要はない可能性があります。
ネストされたスタックの一部であるリソースをスキップするには、次の形式を使用します:
NestedStackName.ResourceLogicalIDResourcesToSkipリストでスタックリソース (Type: AWS::CloudFormation::Stack) の論理 ID を指定する場合、対応する組み込みスタックは以下のいずれかの状態である必要があります:DELETE_IN_PROGRESS、DELETE_COMPLETE、またはDELETE_FAILED。
更新のロールバックを続けるには (AWS CLI)
-
ロールバックを続けるスタックの ID を指定するために、continue-update-rollback コマンドで
--stack-nameオプションを使用します。
失敗した、ネストされたスタックの更新からのロールバックを続ける
複数のスタックが互いにネストされている場合、複数のネストレベル全体でリソースをスキップして、スタック階層全体を動作状態に戻す必要がある場合があります。
例えば、WebInfra というルートスタックがあり、その中に WebInfra-Compute と WebInfra-Storage の 2 つの小さなスタックが含まれているとします。これらの 2 つのスタック内にも、独自のネストされたスタックがあります。
更新中に問題が発生し、更新プロセスが失敗した場合、次の図に示すように、スタック階層全体が UPDATE_ROLLBACK_FAILED 状態になる可能性があります。
注記
この例でスタック名は単純にするために切り捨てられています。子スタック名は通常 CloudFormation によって生成され、一意のランダムな文字列を含んでいるため、実際の名前はユーザーフレンドリーではない可能性があります。
continue-update-rollback コマンドを使用してルートスタックを操作可能な状態にするには、--resources-to-skip オプションを使用して、ロールバックに失敗したリソースをスキップする必要があります。
以下の continue-update-rollback 例は、前回失敗したスタック更新からのロールバック操作を再開します。この例では、--resources-to-skip オプションには次の項目が含まれます。
-
myCustom -
WebInfra-Compute-Asg.myAsg -
WebInfra-Compute-LB.myLoadBalancer -
WebInfra-Storage.DB
ルートスタックのリソースの場合、必要なのは論理 ID を指定することだけです (例: myCustomWebInfra-Compute-Asg.myAsg
aws cloudformation continue-update-rollback --stack-nameWebInfra\ --resources-to-skipmyCustom WebInfra-Compute-Asg.myAsg WebInfra-Compute-LB.myLoadBalancer WebInfra-Storage.DB
ネストされたスタックのスタック名を検索するには
子スタックのスタック ID または Amazon リソースネーム (ARN) 内で見つけることができます。
次の ARN の例は、WebInfra-Storage-Z2VKC706XKXT という名前のスタックを参照しています。
arn:aws:cloudformation:us-east-1:123456789012:stack/WebInfra-Storage-Z2VKC706XKXT/ea9e7f90-54f7-11e6-a032-028f3d2330bd
ネストされたスタックの論理 ID を検索するには
子スタックの論理 ID は、親のテンプレート定義で検索できます。この図では、WebInfra-Storage-DB 子スタックの LogicalId は、親 WebInfra-Storage の DB です。
CloudFormation コンソールでは、[Resources] (リソース) タブ、または [Events] (イベント) タブのスタックリソースの [Logical ID] (論理 ID) 列で論理 ID を見つけることもできます。詳細については、「CloudFormation コンソールからスタック情報を表示する」を参照してください。
