Cloud Infrastructure Inventory Template
Three documents and three sheets, including an Orphaned Resource List split by what nobody would miss and what still has something pointing at it.
Free download · No account needed
Orphaned Resource List
Every row already failed one test. This is the second one
Two outcomes, decided by Referenced By
Nothing pointing at a row means remove it this week. There is no team to negotiate with, so the saving is real the day it is deleted. A DNS record, a security group rule or a load balancer target group still pointing at it means the opposite: escalate, don't delete.
Referenced is not the same as safe
A row can be live, serving production traffic, and still have failed owner resolution. That combination is not a cleanup item. It is a security exposure that happens to be sitting in an inventory sheet instead of a ticket.
What every row carries
Resource ID, type, last owner tag, why resolution failed, what still references it, monthly cost where one exists, and a disposition. Nothing is marked safe to remove until the reference check has actually run against it.
Corrigan Analytics, a marketing analytics SaaS company, resolved every owner tag across its 34 AWS accounts against the identity provider's current group list rather than trusting the tag string. Of 6,318 resources, 5,209 resolved to a team still on the roster. The rest, 1,109 resources, 17.6 percent of the estate, either carried a tag matching nobody current or carried no tag at all, which most cost allocation work assumes away before the tag coverage math even starts.
The orphaned list only becomes useful once it is split a second time. Checked against every DNS record, security group rule, load balancer target group and IAM trust relationship in the estate, 848 of the 1,109 were referenced by nothing at all. Of those, 621 were cost-bearing at $13,617.57 a month, with no owner left to negotiate the deletion with. The other 261 were still plugged into something live. The Center for Internet Security frames that population as a standing obligation, not a one-time sweep: "enterprises cannot defend what they do not know they have."
The same join, run a third time against the DNS zone, is where a gap becomes a live security question. Of 2,140 DNS records, 43 pointed at a target that no longer exists in the register, and 19 named a reclaimable identifier type. Amazon states plainly that once an owner deletes a bucket, "the bucket name might become available again in the global namespace for anyone to re-create." Six of the 19 were still linked from a live customer page. Neither an infrastructure-as-code review nor an observability audit checks whether a DNS target still exists.
What is in the pack
Inventory Standard
The exact, repeatable orphan test: how a tag is checked against the roster and how a DNS target is checked against the register.
Ownership Model
What happens after a resource lands on the orphaned list: removed, escalated to a named owner, or cleaned up at the DNS layer first.
Infrastructure Topology
A drawn slice of the estate tracing one disbanded team to a live replica, an ex-employee's bucket and a dangling CNAME.
Resource Register
One row per resource with its ownership resolution and its criticality, the second one derived from the dependency map, not self-reported.
Orphaned Resource List
Every resource that failed resolution, ranked by monthly cost and split into safe-to-remove against still-referenced.
Dependency Map
What points at what, which is the join that turns an orphaned resource into either a saving or an exposure.
How it works
- 1
Open it in River, or download it
Edit with AI opens the pack as a private Space with the agent ready to run the joins. Download hands you three Word documents and three CSV sheets, no account needed.
- 2
Send the resource export, the DNS zone and the roster
Every account or subscription in scope, the DNS zone files for every domain, and the identity provider's current group list, pulled at the same time as the resource export.
- 3
Get the orphaned list split by what still points at it
River resolves every owner tag against the roster, then checks the orphaned list against every DNS record, security group and IAM trust relationship still referencing each row.
- 4
Escalate what is live, remove what is not
Unreferenced orphans get a deletion date and a monthly saving. Referenced orphans get a proposed owner. Dangling DNS records on a reclaimable identifier type get flagged first.
Frequently asked questions
Is this template free?
Yes, and the download needs no account, card or email. Edit with AI is the optional half that runs the joins: resolving owner tags against your roster, splitting the orphaned list by reference status, and checking the DNS zone for dangling targets.
What format are the downloaded files?
Three documents as .docx and three sheets as .csv, in one zip. Word, Pages, Google Docs, Excel, Numbers and Sheets open them with nothing to convert. The sheets carry the worked Corrigan Analytics example, so the arithmetic is visible before you replace it.
We already have a spreadsheet with an owner column. What does this add?
Whether that column is still true. An owner tag written a year ago and never re-checked passes people who have since left. That is exactly how 447 of Corrigan's 1,109 orphaned resources looked owned, until the tag was resolved against who is actually on the roster today.
How is this different from a cost allocation or tagging project?
A tagging strategy assumes the tag is honest and measures how much of the bill it reaches. This pack tests that assumption first, resolving every tag against the current roster before anything gets allocated to anyone.
Why check DNS records instead of just the resource list?
Because a resource can be gone while its DNS record survives it. Microsoft's own guidance on this exact failure calls it a standing discovery habit: review DNS records regularly to confirm every subdomain still maps to something that exists and that you own.
Does an orphaned resource always mean it is safe to delete?
No, and treating it that way is the actual risk. 261 of Corrigan's 1,109 orphaned resources were still referenced by a DNS record, a security group or a target group, meaning they were live and unpatched with nobody watching them. Those get escalated, not deleted.
Where does this fit with an infrastructure-as-code review?
An infrastructure-as-code review reads what the Terraform or CloudFormation code provisions. This pack reads the live estate directly, which includes everything nobody wrote as code at all: console-created resources, manual snapshots, and orphaned DNS records.