Hey all. I’m working in a multi-account environment, and trying to deploy from a CI runner in a build account to one of several target accounts (say develop, staging, production). I’m trying to move away from using AWS profiles due to general problems with support for EC2InstanceMetadata and the need to drop that config into the environment. CDKv2 Bootstrap creates lookup and deployment roles in the target environments, so I figured I could

--trust

the build account and set IAM to allow the CI runner to assume these roles. All good so far. However, when I set

--role-arn

and

--region

during SST deployment it still tries to deploy into the build account - which figures. So I tried setting the stack

env

which in CDK allows me to specify the target account and region (which I can do based on stage name). This fails thusly:

Error: Do not set the "env" prop while initializing "teams" stack ({"region":"eu-west-2","account":"<redacted>"}). Use the "AWS_PROFILE" environment variable and "--region" CLI option instead.

That looks like a different behaviour from stock CDK (I presume for some good reason). Am I at a dead end? Could be that I’ve misunderstood the purpose of CDK bootstrapping as I’m trying to use it for the first time, but it makes it look like I have to use AWS_PROFILE in practice, rather than assuming a bootstrapped role in the target account.

Hey @Edward Asquith, I don’t have a good answer for this at the moment, we need to change the behavior for SST to support multi-account apps.

In fairness the behaviour of SST does seem broadly in line with CDK. The only real difference is that CDK allows you to specify an account per Stack - but that doesn’t inherently solve anything as you’ll still need to be in a suitable assumed role. It’s frustrating to need to write credential files out in CI tasks, but that’s basically how things are for all similar tools. A bit of a cookbook for cross-account deployment in CI systems in the docs would be great, though - since multi-account environments are pretty much the standard. AWS have written a few articles about it for CDK, but it’s heavily oriented around CDK Pipelines and glosses over a lot of extra necessary steps.