この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
最近CDKでStackSetsを使うことにハマっている鈴木(純)です。よく以下のブログの感じでCDKからStackSetsを展開してます。
CDKから展開するのとっても便利なのですが、エラーになったとき何が原因か分からないことがあったので、事象と解決法を書いておきます。
事象
CDKでStackSetsを展開すると、こんなエラーが返されることがあります。
Resource handler returned message: "Stack set operation was unexpectedly stopped or failed"これだけだと何が原因かわからない…
おそらくStackSetsから展開したスタックインスタンスでエラーが発生したためなのですが、コンソールで確認するとStackSets内のスタックインスタンスは何も残っていないため調査ができませんでした。
原因
なぜ何も残っていない状態なのか確認してみると、StackSetsに展開したスタックインスタンスはCloudFormationのロールバック機能によって削除されていました。
[すべてのスタックリソースをロールバック] オプションは、スタックステータスが CREATE_FAILED または UPDATE_FAILED の場合に、テンプレートで指定されたすべてのリソースをロールバックします。 引用：AWS CloudFormation スタックオプションの設定 - AWS CloudFormation
そのため、原因はCloudFormationのデフォルトであるロールバック設定にあるため、このオプションを変更してあげる必要があります。
解決方法
CloudFormationは前述のようにデフォルトではロールバックを行うのですが、アップデートで正常に作成されたリソースの状態を維持しながら、失敗したリソースの確認ができるようになりました。
[アップデート]CloudFormationにロールバック前にプロビジョニングエラーをトラブルシューティングするオプションが導入されました | DevelopersIO
このオプションをCDK側で利用する場合は、タイトル通り-no-rollbackというオプションをデプロイコマンドに付けることで設定が可能です。(短縮すると-Rでも可)
参考：aws-cdk/README.md at main · aws/aws-cdk
$ cdk deploy --no-rollback
$ cdk deploy -Rこのオプションをつけて、さきほど失敗したStackSetsの展開してみます。するとStackSetsを展開するスタックには、ロールバックが停止されている旨のメッセージが表示されました。
StackSetsのスタックインスタンスを確認してみると、ロールバックされていない状態を確認できます。「状況の理由」からcapabilities: ['CAPABILITY_NAMED_IAM']を設定していないことが原因と判断できました。
おわりに
ちょっとした小ネタですが、CDKからStackSetsを触ると陥りがちなところだと思います。同じところで躓いた人のためになれば幸いです。
3
