Hello, is there a way from reusing the credentials generated by the aws_classic provider and pass it somehow to a DynamicResource (handling aws resouces as well) ? the idea is to have a resource updating a roles' trust relationships (and use a DynamicResource for this but perhaps there's a better option) From what I understand the provider in this case is invoked for every single resource and is basically not reusable - this is not ideal as i'd like the entire program to use the same session ideally?

I don't think you can extract the credentials used from the aws provider itself. The internals of the provider may have setup the session via envvars or files and it doesn't report that back out to the engine to be used in the rest of the program.

thanks, I thought so unfortunately, i'll need to think of something

You can do https://www.pulumi.com/registry/packages/aws/api-docs/getcalleridentity/ to get your current identity. If you need to update only part of an AWS resource and there's no Pulumi resource that directly corresponds, but the AWS CLI has a call for it, use the Command provider to call the AWS CLI. It's usually a better option than a dynamic provider: https://www.pulumi.com/registry/packages/command/api-docs/local/command/

Thanks, I saw that too (the Command provider trick) but I was not convinced it was actually better, simpler perhaps, I guess that depends on the use case. I'm not really interested by the getCallerIdentity parts because our pulumi programs assume roles always, but in this particular case I simply wanted to reuse the same aws session that the provider creates - which is not possible but I can bootstrap my own) Then it's basically Command provider vs DynamicResource. thanks again for the inputs. Just curious why would you recommend Command vs DynamicResource ? simplicity?

The Command provider is better because of how dynamic providers were implemented (we actually serialize the code in a dynamic provider), which we have since conceded was a mistake. That's why they aren't in every language and will not be under the current implementation. We are working on a better design that does not require serializing the code.