AWS CDKでのスタック分割の考え方

Q5. スタックを分割する基準やルールでおすすめはありますか？

まず、必要のない限りはスタックを分割しないことをおすすめします。スタックを分けると、スタック間の結合やスタックの役割など考えることが増えて複雑化しがちです。最初は1つのスタックからはじめて、CloudFormation のリソース数制限などで問題が発生しそうであれば分割を検討するくらいでも十分な場合も多いかと思います。

※DeepL翻訳

デプロイメント要件に応じて、アプリケーションを複数のスタックに分割する

アプリケーションに必要なスタックの数には、厳密な決まりはありません。通常は、デプロイメントパターンに基づいて決定することになるでしょう。以下のガイドラインを覚えておいてください。

通常、できるだけ多くのリソースを同じスタックに置く方が簡単なので、分離したいことが分かっている場合を除き、一緒に置いてください。

ステートフルリソース（データベースなど）をステートレスリソースとは別のスタックに置くことを検討する。これにより、ステートフル・スタックの終了保護をオンにし、データ損失のリスクなしにステートレス・スタックの複数のコピーを自由に破棄または作成できます。

ステートフルリソースは、コンストラクトのリネームに対してより敏感です。リネームはリソースの置き換えにつながるので、移動したりリネームしたりする可能性のあるコンストラクトの内部にネストしないのが賢明です（キャッシュのように状態が失われたときに再構築できる場合は別です）。これは、ステートフルなリソースを独自のスタックに配置するもう一つの良い理由です。

ステートフルとステートレスで分けるくらいでいいのではないか