CloudFormation StackSetsの依存関係先としてControl Tower管理のStackSetsを指定したかった

CloudFormation StackSetsの依存関係先としてControl Tower管理のStackSetsを指定したかった

Control Tower環境でカスタムStackSetsをデプロイする際、StackSetsの依存関係設定がControl Tower管理のStackSetsに対して機能しませんでした。その理由と代替案を紹介します。
2026.04.30

こんにちは!クラウド事業本部の吉田です。

Control Tower環境でカスタムのCloudFormation StackSetsに自動デプロイを設定している場合、新規アカウントを作成した際Control TowerのベースラインStackSetsとカスタムStackSetsが並行して実行されます。
この並行実行がエラーに繋がることがあります。

StackSetsの依存関係設定を使えば解決できると考えて検証しましたが、Control Tower管理のStackSetsには機能しませんでした。
この記事では、依存関係設定が機能しなかった理由と、代替案として運用での回避方法やライフサイクルイベントの活用について紹介します。

Control Tower環境でのCloudFormation StackSetsの問題

Control TowerでOUにアカウントを直接作成すると、複数のStackSetsが並行して実行されます。

  • Control TowerのベースラインStackSets(AWSControlTowerBP-BASELINE-CONFIGなど)
  • 自動デプロイが設定されたカスタムStackSets

AWSControlTowerBP-BASELINE-CONFIGはConfigレコーダーを作成するStackSetsです。
カスタムStackSetsでConfig Ruleを展開している場合、Contol TowerによるConfigレコーダーの作成前にConfig RuleのStackSetsが実行されると、以下のエラーが発生します。

ResourceLogicalId:EC2EBSEncryptionByDefault, ResourceType:AWS::Config::ConfigRule,
ResourceStatusReason:Resource handler returned message: "Invalid request provided:
NoAvailableConfigurationRecorder"

Configレコーダーが存在しない状態でConfig Ruleを作成しようとしたため、NoAvailableConfigurationRecorderエラーが発生しています。

試した設定

CloudFormation StackSetsには依存関係設定の機能があります。※1
自動デプロイ設定で依存先のStackSet ARNを指定すると、依存先のスタックインスタンス作成が完了してから、そのStackSetsのスタックインスタンス作成が開始されます。

カスタムStackSetsの依存関係にAWSControlTowerBP-BASELINE-CONFIGのARNを設定し、ベースライン展開完了後にカスタムStackSetsを実行させようとしました。

screenshot 6.png

しかし、依存関係を設定したにもかかわらず、AWSControlTowerBP-BASELINE-CONFIGのスタックインスタンス作成完了前にカスタムStackSetsのスタックインスタンス作成が開始されました。

screenshot 11.png

screenshot 12.png

screenshot 13.png

依存関係設定が機能しなかった理由

答えは、マネジメントコンソールの「自動デプロイの編集」画面に記載のメッセージにありました。

依存関係スタックセットが存在しない場合、または自動デプロイが無効になっている場合は、そのスタックセットは無視されます。ただし、そのスタックセットを通じた推移的な依存関係は引き続き強制適用されます。

はい。自動デプロイの依存関係先に設定できるのは、おなじく自動デプロイを有効化しているStackSetsのみということです。

Control Tower管理のStackSets(AWSControlTowerBP-BASELINE-CONFIGなど)は、CloudFormation StackSetsの自動デプロイ機能を使用していません。
Control Towerのアカウントプロビジョニングプロセスの中で、Control Towerサービスが直接スタックインスタンスを作成する仕組みになっています。※2

また、Control Tower管理のリソースに対して変更を加えることは非推奨のため、手動で自動デプロイを有効化することもできません。

したがって、「自動デプロイの依存関係先としてControl Tower管理のStackSetsを指定することはできない」が結論となります。

代替案

大きく分けて2つのアプローチがあります。
運用で回避する方法と、ライフサイクルイベントを使って自動化する方法です。

運用での回避方法

自動デプロイ対象外OUを経由する

新規アカウントを一度自動デプロイ対象外のOUに作成します。Control Towerのベースライン展開が完了した後、自動デプロイ対象のOUにアカウントを移動させます。OUの移動によって、カスタムStackSetsの自動デプロイがトリガーされます。

この方法は追加実装が不要で、既存のStackSets設定をそのまま使えます。
ただし、手動でのOU移動が必要になるため、運用手順が増える点はデメリットです。

自動デプロイを無効化する

カスタムStackSetsの自動デプロイを無効化し、アカウント作成後に手動でスタックインスタンスを作成します。
運用はシンプルになりますが、自動化のメリットが失われます。

ライフサイクルイベントの活用

Control Towerはライフサイクルイベントを発行しています。※3
CreateManagedAccountイベントは、Account Factoryを使用して新しいアカウントを作成・プロビジョニングするためのすべてのアクションをAWS Control Towerが正常に完了したかどうかを記録するイベントです。

このイベントを契機にカスタムStackSetsのスタックインスタンスを作成することで、Configレコーダー周りのレースコンディションを回避できます。

Customizations for AWS Control Tower(CfCT)を使う

CfCTは、AWS Control Towerの機能を拡張するためのAWS公式ソリューションです。※4
ライフサイクルイベントを契機としたStackSetのデプロイを構成できます。

CfCT自体の導入と運用が必要になるため、いままでCfCTを利用していなかった環境で導入するのはハードルが高いです。

EventBridge + Lambdaで独自実装する

CreateManagedAccountイベントをEventBridgeで検知し、Lambda関数からCreateStackInstances APIを呼び出す仕組みを独自に構築します。

柔軟なカスタマイズが可能ですが、独自実装の開発と運用が必要になります。

代替案の比較

方法 追加実装 完全自動化 導入の容易さ
OU経由 不要 不可 容易
自動デプロイ無効化 不要 不可 容易
CfCT 必要 可能 中程度
EventBridge + Lambda 必要 可能 中程度

追加実装を避けたい場合はOU経由での運用を、完全自動化したい場合はCfCTまたはEventBridge + Lambdaを検討してください。

追加実装なしで始められるOU経由の運用がおすすめです。アカウント作成の頻度が高くなったり、他にもカスタマイズしたい要件が出てきた段階でCfCTの導入を検討するとよいでしょう。

さいごに

StackSetsの依存関係先として、Control Tower管理のStackSetsが設定できないことがわかりました。

要件に応じて、運用での回避(OU経由、手動デプロイ)か、ライフサイクルイベントを使った実装(CfCT、EventBridge + Lambda)を検討してください。

以上、クラウド事業本部の吉田でした!

参考資料

この記事をシェアする

関連記事