Resource Ownership Detection: Who Created This Resource?
An untagged resource still has a history. The first human who created it and the last one who changed it are a direct route to an owner.
Resource ownership detection is the practice of working out who is responsible for a cloud resource from evidence, rather than from a tag someone may or may not have set. The evidence is the control-plane audit log: every create and modify call carries the identity of the caller. The hard parts are telling people from automation, resolving an opaque principal to a person, and knowing whether that person is still around to ask.
Reading identity out of audit logs
Audit logs record callers in provider-specific shapes. In AWS CloudTrail, the userIdentity element carries a type such as Root, IAMUser, AssumedRole (temporary credentials obtained through STS AssumeRole, which includes EC2 instance roles and cross-account access), FederatedUser, or AWSService. An AssumedRole caller is a role session, so the person, if there is one, has to be recovered from the session name. Azure Activity Log and Google Cloud Audit Logs record the caller of each operation in their own formats.
Retention bounds what can be found. CloudTrail event history covers 90 days of management events and Azure Activity Log keeps 90 days; Microsoft points out that resource creator information is only available in the activity log, which is a reason to route it somewhere with longer retention. A resource created before your retained history begins has no discoverable creator unless you kept older logs.
How ZopNight derives ownership
ZopNight derives who created and who last modified each resource by analysing CloudTrail, GCP Logging, and Azure Activity Log events. The caller principal is extracted from each audit event and resolved: AWS ARNs, including IAM user paths and SSO assumed-role sessions carrying an email, Azure caller IDs, and GCP principal emails. The earliest human caller is taken as the creator and the latest human caller as the last writer. Automation is recorded with a flag that marks whether the caller is human, so a CI role that touched the resource yesterday does not displace the engineer who created it.
A separate daily identity sync fetches the organization’s cloud identities, such as IAM users, SSO users, Azure AD members, and Google Workspace members. At read time each owner gets a status: Active when the identity is still present, Departed when it is absent, and Unknown when identity data is unavailable. The resource detail panel shows creator and last write with the caller, operation, timestamp, and a coloured status dot.
Using it
- Departed owners first. A resource whose creator and last writer have both left is the clearest candidate for review, because nobody is left to object or explain.
- Confirm, then tag. Treat a detected owner as a lead. Once confirmed, record the owner as a tag or a team assignment so attribution no longer depends on log history; see cloud tagging best practices.
- Mind the gaps. Resources created by pipelines under a shared role resolve to automation, not a person. For those, the pipeline’s repository is the owner record.
Ownership detection is built on activity log sync, and is most useful alongside cloud sprawl cleanup and cost allocation.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
How does ZopNight tell a person from automation?
Each caller carries a flag marking whether it is human. Creator is the earliest human caller and last writer is the latest human caller, so automation roles do not overwrite the owner.
What does Departed mean?
The caller's identity is no longer present in the organization's synced cloud identities, such as IAM, SSO, Azure AD, or Google Workspace users.
Why is there no creator for an old resource?
Creators come from audit logs, and providers retain limited history by default. CloudTrail event history covers 90 days and Azure Activity Log keeps 90 days, so older creations are only visible if you kept the logs.