AWS CDKスタックの分割基準

Question

尋ねたいこと

AWS CDKのスタック分割基準について、
1リソース1スタックで作成することのデメリットは何でしょうか。
補足情報記載のページには、スタック分割基準が以下の通り説明されていましたが、
1リソース1スタックで作成したほうが、管理も容易で可読性が高いと考えています。
#####スタック分割基準

• デプロイのライフサイクル
• 影響範囲
• 関係者分離
• CloudFormationの制約

補足情報

AWS DevDay Online Japan に「AWS CDK はどう使いこなすのか、初期開発から運用までのノウハウ」というタイトルで登壇しました #AWSDevDay

Answer 1

1リソース1スタックで作成することのデメリットですが、まず管理が大変になると思います。（初っ端から主の意見と反対のこと言ってすみません）
例えばアプリ用のネットワーク構築のため以下のリソースをデプロイすると考えましょう。

• VPC
• セキュリティグループ
• ALB
• サブネット
• ElasticIP
• NAT Gateway

1つのAWSアカウントにそれぞれ一つのみリソースがある状態だったら問題ないかもしれません。
しかし以下の状態になってくると問題が顕著に現れます

• SSHするための踏み台サーバー用のネットワークを追加したい
• オンプレミスとつなぐためのネットワークを追加したい
• 本番環境やテスト環境など複数の環境を複製したい
• ネットワークの構成を変更したい

となったとき以下の問題が発生します。

• 特定の環境に構築したリソースがどれかを調べなければならない
• 順番にStackを作成・デプロイしなければならない
• 設定を変えるために1つ1つのスタックを更新しなければならない

ほかにもたくさんあるかと思います。

また可読性についてもせっかくのCDKですし、ソースコードの設計次第でいくらでも可読性の向上が図れるかなと思います。
例えばCodePipelineを作り、CodeBuildはクライアントとサーバーで2つ必要とする場合、以下のようなファイルを作ります
bin/cdk.ts
lib/stack.ts
lib/pipeline.ts
lib/codebuild.ts
codebuild.tsはRoleやイメージは固定、プロジェクト名は固定値+suffixとしておき、pipeline.tsから
new CodeBuild({suffix:'client',buildspec:'./client.yml'})
といった感じにできるかと思います

またCDKだけでなくCloudformationテンプレートもAWS::Include transformとaws cloudformation packageコマンドでリソースをファイルごとに定義させることができ比較的可読性を向上させることができます
https://dev.classmethod.jp/articles/cloudformation-fn-include/

1リソース1スタックではなく、複数リソース1スタック＋1リソース1ファイルと言う考えが最もスッキリする考えかなと思いました。