更新のロールバックを続ける
UPDATE_ROLLBACK_FAILED
が更新時にすべての変更をロールバックできない場合、スタックは AWS CloudFormation 状態になります。例えば、CloudFormation の外部で削除された古いデータベースのインスタンスにロールバックを開始するスタックがある場合などです。CloudFormation にはデータベースが削除されたことがわからないため、データベースインスタンスがまだ存在する前提でそれにロールバックしようとし、更新のロールバックが失敗します。
スタックが UPDATE_ROLLBACK_FAILED
状態の場合、動作状態 (UPDATE_ROLLBACK_COMPLETE
) までロールバックを続けることができます。UPDATE_ROLLBACK_FAILED
状態のスタックを更新することはできません。ただし、ロールバックを続けることができる場合、スタックを元の設定に戻し、その後再度更新を試みることができます。
ほとんどの場合、スタックのロールバックを続けるには、更新のロールバックが失敗する原因となるエラーを修正する必要があります。詳細については、「」を参照してください。それ以外の場合(たとえば、スタック操作のタイムアウト)では、変更を加えずに更新のロールバックを続けることができます。
注記
ネストされたスタックを使用する場合には、親スタックをロールバックすると、すべての子スタックも同じような転送を試みます。
更新のロールバックを続けるには (コンソール)
https://console.aws.amazon.com/cloudformation
で AWS CloudFormation コンソール を開きます。 -
更新するスタックを選択し、[Stack actions (スタックアクション)]、[更新のロールバックの続行] の順に選択します。
に関連するエラーのトラブルシューティング の解決策でも解決できなかった場合は、高度なオプションを使用して、CloudFormation が正常にロールバックできないリソースをスキップできます。スキップするリソースの論理 ID を検索して入力する必要があります。更新の転送中ではなく、
UpdateRollback
中にUPDATE_FAILED
状態になったリソースのみを指定します。警告
CloudFormation は指定されたリソースのステータスを
UPDATE_COMPLETE
に設定し、引き続きスタックをロールバックします。ロールバックが完了したら、スキップされたリソースのステータスはスタックテンプレートのリソースのステータスと一致しません。別のスタックの更新を実行する前に、スタックまたはリソースを更新して、整合性を取る必要があります。そうしないと、以降のスタックの更新が失敗して、スタックが回復不可能になる可能性があります。スタックを正常にロールバックするために必要なリソースの最小数を指定します。たとえば、あるリソース更新が失敗したために、それに依存するリソースが失敗することがあります。この場合、依存リソースをスキップする必要はない可能性があります。
ネストされたスタックの一部であるリソースをスキップするには、次の形式を使用します:
。NestedStackName
.ResourceLogicalID
ResourcesToSkip
リストでスタックリソース (Type: AWS::CloudFormation::Stack
) の論理 ID を指定する場合、対応する組み込みスタックは以下のいずれかの状態である必要があります:DELETE_IN_PROGRESS
、DELETE_COMPLETE
、またはDELETE_FAILED
。
更新のロールバックを続けるには (AWS CLI)
-
ロールバックを続けるスタックの ID を指定するために、
aws cloudformation continue-update-rollback
コマンドでstack-name
オプションを使用します。
ResourcesToSkip
を使用してネストされたスタックの階層を復元する
次の図に示しているのは、UPDATE_ROLLBACK_FAILED
状態のネストされたスタック階層です。この例では、WebInfra
ルートスタックには 2 つのネストされたスタック: WebInfra-Compute
と WebInfra-Storage
があり、そこにはネストされたスタックが 1 つ以上含まれています。
注記
この例でスタック名は単純にするために切り捨てられています。子スタック名は通常 CloudFormation によって生成され、一意のランダムな文字列を含んでいるため、実際の名前はユーザーフレンドリーではない可能性があります。
continue-update-rollback
を使用してルートスタックを操作可能な状態にするには、resources-to-skip
パラメータを使用して、ロールバックに失敗したリソースをスキップする必要があります。この例では、resources-to-skip
には以下の項目が含まれます。
myCustom
WebInfra-Compute-Asg.myAsg
WebInfra-Compute-LB.myLoadBalancer
WebInfra-Storage.DB
次の例は、完全な AWS CLI コマンドを示しています。
$
aws cloudformation continue-update-rollback --stack-name WebInfra \
--resources-to-skip myCustom WebInfra-Compute-Asg.myAsg WebInfra-Compute-LB.myLoadBalancer WebInfra-Storage.DB
形式を使用してネストされたスタックからリソースを指定しましたが、myCustom などのルートスタックのリソースでは、論理 ID のみを指定しました。NestedStackName
.ResourceLogicalID
ネストされたスタックのスタック名の検索
スタック ID または Amazon リソースネーム (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 を見つけることもできます。