tomoki10

極力既存ユーザの移行負担を減らす案を書いてみます。 - cdk deploy時のパラメータ指定について - `env=dev`などでパラメータ指定する方式にする - `env`の指定がなければcdk.jsonの既存パラメータを使う（これで既存のユーザはリソースの再作成不要） - ConstructのIDについて - ConstructIDも指定があればenvの値をつける - 指定がなければそのままのConstructIDを使う 以下は例としてDDBのテーブルについて記載します。env指定がなければ空文字で`Table`のまま、`env=dev`などであれば`devTable`をIDとして使う。同一アカウント内ではenvの部分を人やシステムごとに分けて使う。 https://github.com/aws-samples/generative-ai-use-cases-jp/blob/6b6efec7a3e081b3e818ac948a5420bf229a0bfd/packages/cdk/lib/construct/database.ts#L12 ``` const table = new ddb.Table(this, `{env}Table`, { ```

@tbrand ご確認ありがとうございます！ 1つのAWSアカウントに対して複数のCDKアプリを作成できることを想定しています。以下の画像のApp部分を1つのアカウントに対して複数作るような想定です。 今はbin/lib配下のソースがApp1つ前提で構築されているので、上記のような構成は難しいと考えています。 参考：[Boost your infrastructure with the AWS CDK](https://aws.amazon.com/blogs/aws/boost-your-infrastructure-with-cdk/) 

>CDK の App を分けたとして、Stack 名 (Stack の id) の変更は必要という理解で正しいでしょうか？ はい、StackにわたすIDに引数から値を渡すなどの変更が必要になります。以下が例です。 ```ts const generativeAiUseCasesStack = new GenerativeAiUseCasesStack( app, `GenerativeAiUseCasesStack${env}`, ``` >それに加え、Stack の id を変更した場合、Construct の id は変更ない (被っていても問題ない) という理解はあっていますでしょうか？ はい、同じように名前をハードコードしている部分やL1 Constructが主に問題になる認識です！以下の部分などです。...