Hey everyone! I have a multi-account AWS architecture with lots of resources that need to be provisioned dynamically. Most of my infra is in CloudFormation and I’m going to be migrating it all over to Pulumi. Need to do it as quickly as possible, so I would love some advice up front. Most specifically: 1. There’s a set of resources I need to deploy many instances of on demand. If I organize them into components and deploy instances of them with the Automation API, does that add those resources to the state so they can be redeployed if I rip down the whole architecture? 2. What Pulumi tooling is available to manage many AWS accounts? Think account-per-tenant provisioning 3. Is there a repository of examples of components?

1. Automation API follows the same paradigm as using the CLI. You declare resources within your stack definition (your pulumi program) and then you provision or destroy instances of that stack. Components are just logical groupings of resources, and are themselves a resource. They are deployed the same way any other resource is deployed. When you declare a component in your pulumi program, it will be part of your pulumi state the same way any other resource would be. 2. I would come up with some way to pass in account information via stack configuration. In your pulumi program you would declare an

Aws.Provider

to target the account based on configuration, and you would pass that provider instance to all resources that you want to be provisioned into that account. If you need to provision to multiple accounts within the same pulumi program, than you would want to use multiple instances of

Aws.Provider

. 3. There is a repo for traditional CLI program examples and for Automation API examples.

@bored-oyster-3147 This is incredibly helpful thank you so much! I think this is all I need to get started now 👍

Since you have a client-per-account setup I would be wary of any setup that means you have more than 1 client within a single pulumi stack. I would try to keep my pulumi stacks client-specific. If you have shared infrastructure that your client-specific infrastructure needs to reference I would pull that out into a separate pulumi project so it is provisioned independently of your client-specific infra

That makes sense! Thank you

Well thinking about that more I guess it depends, because if that were the case you would need to provision each client independently for sweeping updates and there are probably scenarios where that isn't desireable, like if you are expecting to make frequent changes to all clients. But it's worth keeping in mind that if your clients are in the same stack you will have a headache if you ever need to provision one of those clients differently than the rest.

I think if I can abstract sets of resources from the client accounts into reusable components with appropriate inputs, I can define separate stacks for each client and handle some of the resource updates centrally. Need to test that out a bit though since I’m relatively new here

Definitely. That's where Automation API can bring this together, because you could have your clients in separate stacks and Automation could help you iterate through the stacks programmatically if for instance you want to run “pulumi up” on every client stack.

And that would pull changes from the updated components? Super powerful

Oh if you have a component package I suspect you'll need to update the version referencing that package and next time you pulumi up it will see your changes.