更新のロールバックを続ける - AWS CloudFormation
ResourcesToSkip を使用してネストされたスタックの階層を復元する

更新のロールバックを続ける

AWS CloudFormation が更新時にすべての変更をロールバックできない場合、スタックは UPDATE_ROLLBACK_FAILED 状態になります。たとえば、AWS CloudFormation の外部で削除された古いデータベースのインスタンスのロールバックを開始するスタックがある場合などです。AWS CloudFormation にはデータベースが削除されたことがわからないため、データベースインスタンスがまだ存在する前提でそれにロールバックしようとし、更新のロールバックが失敗します。

スタックが UPDATE_ROLLBACK_FAILED 状態の場合、動作状態 (UPDATE_ROLLBACK_COMPLETE) までロールバックを続けることができます。UPDATE_ROLLBACK_FAILED 状態のスタックを更新することはできません。ただし、ロールバックを続けることができる場合、スタックを元の設定に戻し、その後再度更新を試みることができます。

ほとんどの場合、スタックのロールバックを続けるには、更新のロールバックが失敗する原因となるエラーを修正する必要があります。それ以外の場合(たとえば、スタック操作のタイムアウト)では、変更を加えずに更新のロールバックを続けることができます。

注記

ネストされたスタックを使用する場合には、親スタックをロールバックすると、すべての子スタックも同じような転送を試みます。

更新のロールバックを続けるには (コンソール)

  1. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。

  2. 更新するスタックを選択し、[Stack actions (スタックアクション)]、[更新のロールバックの続行] の順に選択します。

    トラブルシューティングガイドの解決策でも解決できなかった場合は、高度なオプションを使用して、AWS CloudFormation が正常にロールバックできないリソースをスキップできます。スキップするリソースの論理 ID を検索して入力する必要があります。更新の転送中ではなく、UpdateRollback 中に UPDATE_FAILED 状態になったリソースのみを指定します。

    警告

    AWS CloudFormation は指定されたリソースのステータスを UPDATE_COMPLETE に設定し、引き続きスタックをロールバックします。ロールバックが完了したら、スキップされたリソースのステータスはスタックテンプレートのリソースのステータスと一致しません。別のスタックの更新を実行する前に、スタックまたはリソースを更新して、整合性を取る必要があります。そうしないと、以降のスタックの更新が失敗して、スタックが回復不可能になる可能性があります。

    スタックを正常にロールバックするために必要なリソースの最小数を指定します。たとえば、あるリソース更新が失敗したために、それに依存するリソースが失敗することがあります。この場合、依存リソースをスキップする必要はない可能性があります。

    ネストされたスタックの一部であるリソースをスキップするには、次の形式を使用します: NestedStackName.ResourceLogicalID。ResourcesToSkip リストでスタックリソース (Type: AWS::CloudFormation::Stack) の論理 ID を指定する場合、対応する組み込みスタックは以下のいずれかの状態である必要があります: DELETE_IN_PROGRESS、DELETE_COMPLETE、または DELETE_FAILED。

更新のロールバックを続けるには (AWS CLI)

ResourcesToSkip を使用してネストされたスタックの階層を復元する

次の図に示しているのは、UPDATE_ROLLBACK_FAILED 状態のネストされたスタック階層です。この例では、WebInfra ルートスタックには 2 つのネストされたスタック: WebInfra-Compute と WebInfra-Storage があり、そこにはネストされたスタックが 1 つ以上含まれています。

3 レベルのネストされたスタック階層を示す図です。
注記

この例でスタック名は単純にするために切り捨てられています。子スタック名は通常 AWS CloudFormation によって生成され、一意のランダムな文字列を含んでいるため、実際の名前はユーザーフレンドリーではない可能性があります。

continue-update-rollback を使用してルートスタックを操作可能な状態にするには、resources-to-skip パラメータを使用して、ロールバックに失敗したリソースをスキップする必要があります。この例では、resources-to-skip には以下の項目が含まれます。

  1. myCustom

  2. WebInfra-Compute-Asg.myAsg

  3. WebInfra-Compute-LB.myLoadBalancer

  4. WebInfra-Storage.DB

次の例は、完全な CLI コマンドを示しています。

PROMPT> aws cloudformation continue-update-rollback --stack-name WebInfra --resources-to-skip myCustom WebInfra-Compute-Asg.myAsg WebInfra-Compute-LB.myLoadBalancer WebInfra-Storage.DB

NestedStackName.ResourceLogicalID 形式を使用してネストされたスタックからリソースを指定しましたが、myCustom などのルートスタックのリソースでは、論理 ID のみを指定したことに注意してください。

ネストされたスタックのスタック名の検索

スタック 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 です。

AWS CloudFormation コンソールでは、[リソース] タブ、または [イベント] タブのスタックリソースの [論理 ID] 列で論理 ID を見つけることもできます。