I think you may have this a little backwards.
S3 is a service that you may want to access with a role. S3 would not be accessing anything, things access s3.
So, if you made IAM role
ABC, you could set up policy to allow it to list and write to a specific S3 bucket, for example.
You could also make role
ABC assume-able by another role. In that case, you may have a server with default IAM role (instance profile)
XYZ and the assume role policy can state that
XYZ can assume
ABC, which would then let it access S3.
Any entity is just one role at a time. So, once your server assumed
XYZ, it effectively is just
You can also assume roles from IAM users - but IAM users are generally bad practice as they are very losable.
Assuming a role is a very explicit operation, you have to do it on purpose. Some programs may "seem" like they do it easily by configuration, but in reality if they are assuming a role, they are running very specific code for it, similarly to what you would do to assume the role from a command line.
Here is a decent AWS tutorial for assuming roles in a CLI to get familiar with it.
The final command looks like this:
aws sts assume-role --role-arn \
But that assumes role
arn:aws:iam::123456789012:role/example-role is set up to allow your current role (whatever it is) to assume it. Note that role assumption within an account only requires the target role to allow it, but role assumption between two AWS accounts requires the source and target role to be set upt o allow it.