hello all and thanks for the amazing product! I have a general question re deploying to multiple AWS accounts In a situation where an org has multiple AWS accounts (say a dev and a prod account), what's the best way to ensure the updates happen on the correct AWS account for a given stack? For example, I'm planning to create a

develop

stack and a

production

stack to match the AWS dev and prod accounts, but I need to ensure that if one updates to the AWS account

develop-account

, the correct profile or session is used in order to not end up with either deploying resources in the wrong account or, ever worst, delete production resources (say an RDS db) FYI, at the moment, I have a small

if

statement at the beginiing of the script ensuring the AWS account is not the production account:

account_map = {
  "123456": "production",
  "234567": "develop"
}

if account_map[aws.get_account()] != aws.get_stack():
  raise RuntimeError("account number and deployment missmatch")

Any help is very appreciated!

There's multiple ways how you could do this. One option is using the

allowedAccountIds

configuration option: https://www.pulumi.com/registry/packages/aws/api-docs/provider/#allowedaccountids_yaml That way you can define the allowed account for each stack. This is essentially a built-in option of what you have right now. A more integrated option is Pulumi ESC. Using it, you can create pre-defined "environments" for every account and consume them in your pulumi stacks: https://www.pulumi.com/docs/esc/integrations/dynamic-login-credentials/aws-login/ That way, credentials are fetched on demand by pulumi and your developers do not need to worry about assuming the right roles or fetching creds. Here's how this could look like: https://www.pulumi.com/docs/esc/environments/working-with-environments/#using-environments-with-pulumi-iac

thank you so much! seems like the allowedAccountIds is the best option as a quick solution while the ESC is the better, long term option... just to clarify then, the

allowedAccountIds

is just a parameter in the

Pulumi.<stack>.yaml

right? a developer will still have to manage their own profiles? and if one edit the yaml file, they'll be able to bypass the restriction if they have the correct credentials with write access? one more thing: is the ESC/AWSLoginOIDC solution part of the team licence, or is it an enterprise feature?

You can set

allowedAccountIds

in the

Pulumi.<stack>.yaml

as well as programmatically if you're defining an explicit provider (e.g.

new aws.Provider("my-prov", { allowedAccountIds: [...] })

. And you're right, those restrictions can be bypassed by devs that have access to the AWS account. But at that point they could also just fire off regular aws cli commands. If you really want to prevent folks tampering with production accounts I'd recommend performing mutating operations only through CI/CD.

Ok perfect, thanks so much!