I didn’t realize CDK/SST could have a single App that creates two stacks, each in different regions. If that is indeed possible, is there a way to create a construct that adds another stack in a different region?

While reading The CDK Book, I was struck by this statement

In AWS CDK, you can, and should, specify the environment for every stack in the StackProps you pass to the constructor.

new cdk.Stack(this, "Stack1", new Struct { Env = new Struct {

Account = "123456789012",

Region = "eu-central-1"

}

});

I highly recommend providing this information explicitly and not using whatever credentials are currently active in your CLI to determine the target environment of your CDK stack instance. For example, suppose you have multiple CLI profiles on your machine and access to several accounts. In that case, you might deploy CDK apps into accounts of other customers, projects, or stages. This is something you definitely want to prevent.

...someone try it

I briefly looked into this while trying to determine how to manage different resources lifecycles in the same App. I wanted an RDS database that only had dev/stage/prod stages and an API that had <username>/stage/prod stages. The <username> stage of the API should always use the dev RDS stage. The problem I ran into is that each SST app requires all stacks to share the same stage name. I assume the same would be true about Accounts and Regions. @Simon Reilly and I had a discussion about this recently in this channel

ah

Yeah, I am currently experimenting with multiple SST apps to implement what I think you're describing. One is for my RDS instance and the other for my API, I deploy each independently. I'm not sure how to manage that workflow in the same SST app.

@Seth Geoghegan can your app not just make the needed adjustments based on whatever account / stage / region extra its being deployed to? We do this now with the stage and account.

@thdxr Doesn't look like it's possible see https://github.com/serverless-stack/serverless-stack/blob/master/packages/resources/src/Stack.ts#L28 it overrives the env to the root.region

ah

99% of the time yes

Also, cdk bootstrap is needed in each region you deploy to I think

But when dealing with Cloudfront for instance you have to have the ssl cert in us-east-1

Oh noice

But then again it might be because I was already bootstrapped in my "default" region

Yeah so if you look at CDK under the hood (and in our codebase as well) there are instances of creating a resource in another region

@thdxr Right…. thats how we have our Custom Resource for cross-region replica buckets setup…. but it feels like those resources are not really tightly coupled to a stack. Sort of managed by CODE that is managed by Cloudformation.

Ahhh

It's truly terrible 😢

I guess something similar could be done for generating a certificate in us-east-2?

yep I have an arn hardcoded 🤮

Well mine is pulled from the .env but still...

Someone could make a construct that does all that for you and hides the ugliness ins omething that looks normal

You got any docs on making constructs?

Perhaps use SST for your application and directly CDK for IaC that you need in other accounts or regions?

Again an option but just feels like it's another step, another set of tools and things to break or forget to do!