I found an unexpected behavior yesterday while porting some Pulumi code over to a set of new AWS accounts. As part of porting the code over to the new accounts, I switched from using

AWS_PROFILE

in the environment (set via

.envrc

and

direnv

) to specifying the AWS profile in a Pulumi configuration value (i.e.,

pulumi config set aws:profile <name>

). This worked for everything except a Pulumi program that sets up VPC peering between VPCs in two different regions. The error it returned was related to the AWS provider that operates in the “destination” region (one provider operates in the “source” region to set up peering-related objects, and a second provider operates in the “destination” region to set up the corresponding objects on the other side of the connection). Is this expected behavior? I haven’t dug deep into fixing it yet, but I’m guessing there’s something about the way I’m setting up the destination provider that isn’t working with/respecting the

aws:profile

configuration value. (All this is written in Go, hence why I’m posting here.)

@salmon-account-74572 we recently removed the

aws:profile

config variable because it was causing more trouble for shared stacks than value: https://github.com/pulumi/pulumi-aws/pull/1909 long story short, you'll need to use the env var now

Hmm…that’s a shame, because allowing the profile to be stored as part of the stack makes it easy for me to “port” a stack among/between multiple AWS accounts with different profiles. However, given that we are working with full-featured programming languages here, I can see a path forward (based on the comment in the PR) to pull from either the config value or the environment variable.