Assume role accesskeyId / token rotation

Everytime you assume a role, a new Access Key, Secret and Access Token is generated. You can name the session name however you wish either with the same or different tokens.

https://aws.amazon.com/blogs/security/easily-control-naming-individual-iam-role-sessions/

Which region are you checking the cloudtrail events in?

Below 👇 are the Facts:

1. Every new AssumeRole call generates a new AccessKeyId —>always.
2. RoleSessionName is not unique —> it can be reused across multiple AssumeRole calls.
3. You can see multiple different AccessKeyIds associated with the same RoleSessionName if: a) The role was assumed again (same session name reused). b) The client/tool automatically re-assumed the role before expiry.
4. STS doesn't enforce unique session names, so logs may appear as if it's the same session when it’s actually a new one.

Cross Check

1. Check CloudTrail for AssumeRole events. If there's a new event between the two AccessKeyIds (even if RoleSessionName is the same), that proves it’s a new session.
2. Look at timestamps and source IP/user agent fields to see if the session was refreshed by a tool or automation.

The AssumeRole call could've been made in a different region. If you have a multi-region trail set up in CloudTrail, you could scan the logs for matching events in all regions. If not, you can query CloudTrail events in each region separately. In particular, you might find an event in us-east-1, which hosts global instances of most AWS services.

You are correct in your understanding that to obtain a new temporary access key ID, a call to STS (or ARS for some internal AWS services, but it shows as an STS event in logs) to obtain the temporary credentials must occur and should appear in CloudTrail logs. However, what someone wrote about the access key ID being guaranteed to be unique is not correct. For temporary credentials issued by STS, which have the prefix ASIA, only the combination of access key ID and secret key and session token is guaranteed to be unique. This is explicitly stated in documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-prefixes

ASIA: Temporary (AWS STS) access key IDs use this prefix, but are unique only in combination with the secret access key and the session token.