Suppose I create a role with AssumeRolePolicyDocument allowing an AWS service (e.g. s3.amazonaws.com) to assume the role - do I need to in some way tell the service to assume the role, or will it automatically assume the role if it needs a permission that the role grants?

The motivation for this question is S3 Inventory, where according to the docs the S3 principal is what's accessing resources: https://docs.aws.amazon.com/AmazonS3/latest/userguide/configure-inventory.html

  • any feedback on our answers?
    – jdog
    Jul 12, 2022 at 20:45
  • 1
    It seems like the answer is that there is no implicit assumption of a role Jul 12, 2022 at 23:18

2 Answers 2


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 ABC from XYZ, it effectively is just ABC.

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.

Example Tutorial

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 \
"arn:aws:iam::123456789012:role/example-role" \
--role-session-name AWSCLI-Session

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.

  • The motivation for this question is S3 Inventory, where according to the docs the S3 principal is what's accessing resources: docs.aws.amazon.com/AmazonS3/latest/userguide/… May 31, 2022 at 0:53
  • Ah, interesting. I stand to learn something good here too then =). Thanks for clarifying! May 31, 2022 at 1:56
  • 2
    @SimonHardman could you please update the question with this information on how you're using S3? I think it significantly changes the context. May 31, 2022 at 7:07

There is a variety of ways how different services access an S3 bucket. What John Humphreys answer describes is the scenario where the access is performed by some user controlled code running in the same AWS account. Some other access patterns include:

  • Delivering content through Cloudfront: There is something called an "Origin Access Identity" - a sort of Cloudfront specific role that can access the S3 bucket. This role cannot be assigned any policies itself, so you have to use the S3 bucket policy as an overlapping security layer to allow the policy access to the bucket (on top of any other access that exists). An additional example would be a certain Wordpress plugin I have worked with that in the past required the S3 bucket and objects to be public. In this case the policy would have to be configured to be "nothing but the Origin Access Identity"

  • You could imagine a SaaS service that delivers something to your bucket, but without wanting to be restricted to how they do that. They may use EC2 now, but want to be free to deliver the data later by using Lambda or even S3 bucket replication. In this case, you would set up a policy that allows anything in the other AWS account to have write access to your bucket.

  • Some AWS Services have a default named role, for example if you use EC2 Lifecycle Manager, a role is created in your account called AWSDataLifecycleManagerDefaultRole. For this role to use a KMS key, the key needs to have a policy to allow access for this role.

  • While I have not used S3 inventory myself, if you look at the example policy linked from the service description: https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-use-case-9

            "Version": "2012-10-17",
            "Statement": [
                  "Sid": "InventoryAndAnalyticsExamplePolicy",
                  "Effect": "Allow",
                  "Principal": {
                      "Service": "s3.amazonaws.com"
                  "Action": "s3:PutObject",
                  "Resource": [
                  "Condition": {
                      "ArnLike": {
                          "aws:SourceArn": "arn:aws:s3:::sourcebucket"
                      "StringEquals": {
                          "aws:SourceAccount": "111122223333",
                          "s3:x-amz-acl": "bucket-owner-full-control"

In this case the policy allows the S3 service itself (in some undefined capacity) to write to your target bucket and it could even be an inventory of an S3 bucket in another account.

So, the S3 service does not "pick the right role", it operates without a specific(ally known) role.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.