What is a cloud asset inventory?
A cloud asset inventory is a continuously updated record of every resource running across an organisation's cloud accounts — compute, storage, databases, networks, identities and managed services — with where each one lives, who owns it, and how it connects to other resources. It is built by discovery through provider APIs, not by manual entry.
Why a cloud asset inventory matters
Every other cloud discipline starts with the same question: what do we actually run? Security cannot protect a database nobody knows exists. Finance cannot allocate the cost of a cluster with no owner. A recovery plan cannot bring back a dependency it never listed.
In a data centre the answer changed slowly — servers arrived on a loading dock. In the cloud, a resource is one API call away, and so is its disappearance. Inventories that were accurate on Monday are wrong by Friday unless something keeps them current.
That is why the major control frameworks put inventory first. Asset inventory is the opening control in the CIS Critical Security Controls, and Asset Management is the first category of the Identify function in the NIST Cybersecurity Framework.
How is a cloud asset inventory built?
A modern inventory is discovered, not declared:
- Connect — a read-only credential in each cloud account, subscription or project.
- Enumerate — call the provider's APIs across every region and service to list what exists.
- Normalise — give every resource a stable identity, type, account, region, state and tags, so the same resource is not counted twice under different names.
- Relate — record the relationships between resources: what runs inside what, what attaches to what, what can reach what.
- Repeat — re-run on a schedule or on change events, and record when each resource was last seen so deleted resources drop out instead of lingering.
What should a cloud asset inventory include?
| Field | Why it matters |
|---|---|
| Provider, account, region | Where the resource lives and who is billed for it |
| Type and service | What it is — a VM, a bucket, a managed database, a role |
| State and last seen | Whether it still exists, and how current the record is |
| Tags and owner | Who is responsible for it |
| Relationships | What it depends on and what depends on it |
| Configuration | The settings security and recovery decisions are made from |
Cloud asset inventory vs CMDB
A configuration management database (CMDB) is the system of record for IT services and their configuration items, usually maintained through change processes and reconciliation. A cloud asset inventory is the discovered truth of what the provider says exists right now.
They are complementary, not competing. The common failure is treating a CMDB populated by hand or by periodic import as if it were current. In the cloud, the CMDB is most useful when it is fed from discovery, not reconciled against it once a quarter.
Why relationships matter as much as the list
A flat list answers "how many databases do we have?". It does not answer "what breaks if this subnet goes away?", "which roles can read this bucket?" or "which application pays for this volume?". Those questions are about edges, not rows — which is why mature inventories store resources as a graph.
Common gaps
- Shadow resources created outside the provisioning pipeline, which never appear in infrastructure-as-code state.
- Orphaned resources — unattached volumes, old snapshots, idle load balancers — that outlive the workload they served.
- Unowned resources with no tag or account mapping, which nobody will patch, pay for or recover.
- Stale records that stay in the inventory after the resource is deleted, because nothing checks when it was last seen.
Next steps
- How Onam Estate builds the estate of record — continuous discovery and relationships across your connected clouds
- What is CSPM? — what security does with the inventory
- What is cloud cost allocation? — what finance does with it
Frequently asked questions
What is the difference between a cloud asset inventory and a CMDB?
A CMDB is a system of record for IT services and configuration items, typically maintained through change processes. A cloud asset inventory is discovered from provider APIs and reflects what exists right now. The strongest setups feed the CMDB from discovery rather than reconciling the two by hand.
How often should a cloud asset inventory be updated?
Continuously, or as close to it as the provider APIs allow. Cloud resources are created and deleted in minutes, so an inventory refreshed monthly is mostly a historical document. Recording when each resource was last seen is what lets deleted resources drop out.
Does a cloud asset inventory need agents?
No. Cloud resources are described by the provider's control-plane APIs, so a read-only credential is enough to enumerate them. Agents are only needed to see inside a workload — installed packages, running processes — which is a different question from what exists.
Why do asset inventories need relationships, not just a list?
Because most real questions are about connections: what an application depends on, what can reach a database, which team pays for a volume. A list of resources cannot answer those; a graph of resources and the edges between them can.