No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

The Pulumi AWS provider has an assumeRole field. Create a provider for each role you need.
<https://www.pulumi.com/registry/packages/aws/api-docs/provider/#properties>

do you really have to pass this new provider to every resource you create?

Yes. Though if you're using ComponentResources, you can rely on the inheritance of providers. Child resources automatically get their parent's provider, unless overridden.

You wouldn't want a provider that can deploy to more than one region or whatever. That would allow for accidentally deploying to the wrong place. If one function's  side effect changes the region.. chaos could ensue.

am I correct in thinking a “Provider” is basically some settings on the AWS client?

doesn’t really control any business logic

Hey <@U012UJTT55M> — after using a customer provider, I’m seeing that since the provider is “changing”, it tries to recreate the resource.  Do you know of a way around this?

Yes <@U02F3866TRA>, a Pulumi provider is the API client, wrapping config values and auth, and orchestrating the CRUD actions.

When changing a provider, the resources do get destroyed, unfortunately. There are workarounds, none particularly pleasant.

You can create the new provider with the same settings as the default provider,, then export the stack, edit all the resources to use the explicit provider, and import the stack.

You can create a new stack that uses the explicit provider, import all the resources to it, and delete them from the old stack.

ah that makes sense.  A bit error prone, but that’s a good solution

I'm pretty sure that aliases don't work to alias providers, unfortunately :disappointed: