All our infrastructure (jenkins master and slaves) are all on AWS EC2, but under different account. Each Slave is under different EC2 account as well.

The Jenkins master is using an dedicated Jenkins IAM user with AWS_KEY_ID and each slave is using a role which allows the Master accounts' Jenkins user to assume to.

Thus in the Jenkins credential is defined as shown in "credential definition.jpg" and in the configuration, when defining a new cloud for the Slave, it can select the credential that has been defined above. 

When this was firstly setup, the slave can be launched successfully. 

However, after several hours, the slave cannot be launched any more. When manually launching a new slave manually using this Cloud account, sometimes there are nil response from Jenkins, sometimes it shows error about Expired credential. 

Under this situation, if I am going back to Jenkins configuration and change the cloud using a different static credential, click "apply" and then change the credential back to the above credential, and "apply" again, then I am able to manually launch a new slave successfully.

I am guessing the Jenkins credential is stored by Jenkins server when the configuration is setup. However, that credential Jenkins get at that time has a expiry time. When the credential expires, Jenkins does not use the role to generate new credentials. Thus launching a new slave will fail. However, when  I switch the credential and switch the role based credential back again, Jenkins will require new credentials again and the launching will be successful again.

However, due to the new temporary credential has an expiry, the slave launch will still fail after several hours.

What I am expecting is as long as the IAM role has been set by the credential, Jenkins will always use the role to generate new temporary credentials before launching every new slave, rather than only remember the temporary credential for the role statically and use it forever.

Notice this role is different from the executing role of the slave instance. It is only the role that Jenkins server uses to find out basic EC2 information about the cloud account that the slave uses.

I observed this behavior on EC2 plugin 1.21, and upgraded the plugin to 1.23 and it still exists.