I there a way to create a single CDK/SST app that can deploy two (slightly different) stacks each stack to a different AWS account? I assume no.

Your CDK stacks are just javascript, so you can pass in environment variables which will be available to your javascript at the point of synthesising the stack. For example, let’s say your first stack needs an ElastiCache cluster but your second one doesn’t, when synthesising the second one, you can do.

DISABLE_ELASTICACHE=true sst deploy

Then in your stack, you can only add the ElastiCache construct if the environment variable is not set.

if (!process.env.DISABLE_ELASTICACHE) ...add construct

With regards to deploying to a different account, it’s probably better to control that at the credential level. I personally use Leapp to switch between accounts, but others use AWS Vault. SST or CDK itself usually isn’t really concerned with the account. It just deploys with whatever credentials you tell it to, which are tied to an account.

@Dan Van Brunt this is doable in CDK, you can specifiy different AWS account and region for each stack. It’s not currently possible with SST. Do you mind sharing your use case?

@Frank Ya, its a bit complex and might be overkill. Stack Cleanup Webhook (Github => Lambda) • when feat branches are deleted in github, this lambda goes out and tears down the associated enviroment. This can be across two AWS accounts. Sandbox (DEV envs) and Prod (RC envs) • In order for that Lambda to have permissions, I need to have already created a Role in the Sandbox account it can assume in order to delete stacks in that account. Cross-Account-Site Lambda@Edges • we have an Edge lambda that is used on all our sites both dev (AWS account 1) and prod (AWS account 2) this lambda needs access to that site’s bucket to access it’s routing file. This access is given via that site’s bucket policy. • I wasn’t sure if I could easily give a cross-account role access in a bucket policy so we create duplicate Lambda@Edge functions in both sandbox and production accounts as well as roles.

I think that seems cleaner than trying to do it in a single deployment. Much less complexity.

Hey @Dan Van Brunt, sorry I was caught up in a few meetings today. Yeah the two scenarios you laid out make sense. Supporting deploying to multiple account needs some work to be able to assume the credentials in use into other AWS accounts.