How to find who created an AWS resource
The short answer
Look up the resource's creation event in AWS CloudTrail and read the userIdentity field, which records the IAM user or role that made the API call. CloudTrail's console event history only covers the last 90 days, so for older resources you need to query the logs your trail archives to S3 — usually with Athena.
Somebody created it. AWS recorded that. The problem is only that the record expires from the easy place to look.
The short version
Every resource in your account was created by an API call, and CloudTrail logged that
call along with the identity that made it. Find the event, read userIdentity, and you
have your answer.
Within the last 90 days
CloudTrail keeps 90 days of management events in Event history, queryable in the console or the CLI without any setup. Look up events by resource name:
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=ResourceName,AttributeValue=i-0abc123def456 \
--max-results 5The field you want is userIdentity. What you get back depends on how the call was made:
| userIdentity type | What it means |
|---|---|
IAMUser | A named human, or a long-lived access key belonging to one |
AssumedRole | Someone or something assumed a role — the arn shows which |
AWSService | Another AWS service made the call on something’s behalf |
AssumedRole is the common and least helpful case: it tells you a CI pipeline or an
SSO role created the resource, not which person was driving. The sessionContext often
carries a session name that maps back to a user, and for SSO sessions that name is
frequently the person’s identity.
Older than 90 days
Event history is gone, but if you configured a trail to deliver logs to S3, the record is still there. Query it with Athena.
TODO — drop in the working Athena table definition and the query you use, along with the partition projection settings. This is the part people search for and cannot find written down clearly.
What to do when the answer is “a role”
TODO — expand: correlating role sessions with your identity provider, the tags CI systems should be stamping at creation time, and why fixing this forwards is cheaper than archaeology.
Doing it forwards instead
Tracing ownership backwards works, but it is archaeology, and it gets harder every month. The durable fix is that new resources arrive tagged: the creation event triggers a policy, the policy resolves the owner from the calling identity, and the tags are applied before anyone has to go looking. Everything created from that point on answers this question by itself.