Updated 25 Oct 2026 • 7 mins read
Cloud Asset Inventory
A cloud asset inventory is the single list of everything running across every account and provider, with an owner and a cost on each, and most estates do not have one: native inventories stop at their provider and carry neither. This walkthrough shows how Opslyft's Atlas builds that inventory across AWS, Azure, GCP, and OCI and what it finds.
A cloud asset inventory is the one thing every on-premises IT department had and almost no cloud estate does: a single list of everything running, with what it is, where it is, who owns it, and what it costs. The cloud replaced it with convenience. Forty AWS accounts, a dozen Azure subscriptions, two hundred GCP projects, and an OCI tenancy each have an inventory of their own, scoped to themselves, carrying neither the owner nor the monthly cost of anything in them, and reconcilable to one another only by hand. The result is that the question which should be the easiest in infrastructure, what are we running and who is responsible for it, has no answer, and the proof-of-concept project on the secondary cloud bills for two years because nobody had a list it was on.
This page is a walkthrough of how Opslyft's Atlas builds that inventory across AWS, Azure, GCP, and OCI, with Kubernetes and Snowflake alongside, puts an owner and a cost on every resource, and uses it to find the forgotten, the orphaned, and the unowned continuously. It is the foundation under Opslyft's cost governance, and the Cloud CMDB that our walkthroughs of safe rightsizing and governance policies build on.
The short answer: A cloud asset inventory is a single, live list of every resource across every account, subscription, project, and provider, with an owner and a cost on each. Native tools do not provide it: AWS Config, Azure Resource Graph, Google Cloud Asset Inventory, and OCI's inventory each stop at their provider and their scope and carry neither ownership nor monthly cost per item. Opslyft's Atlas connects read-only to AWS, Azure, GCP, and OCI, plus Kubernetes clusters and Snowflake, and keeps one inventory in which every resource has an owner (from tags where present, inferred from account structure, naming, and relationships where not), a cost, a compliance status, and a change history. Forgotten resources, the unowned project, the orphaned volume, the subscription a contractor created, are flagged continuously, priced, and routed to an owner as a ticket; the same inventory is what makes allocation, rightsizing, anomaly root cause, and governance safe to act on. A leading fintech reached 95 percent visibility across a $40 million GCP estate this way.
Why Native Inventories Stop Short
| Tool | Scope | Owner on each item | Cost on each item | Across providers |
|---|---|---|---|---|
| AWS Config | One account and region at a time; aggregators span accounts within an organization | Tags only | No | No |
| Azure Resource Graph | Subscriptions and management groups | Tags only | No | No |
| Google Cloud Asset Inventory | Projects, folders, organization | Labels only | No | No |
| OCI inventory | Compartments within a tenancy | Tags only | No | No |
| Opslyft Atlas | Every connected account, subscription, project, tenancy, cluster, and warehouse | Tags plus inferred ownership | Yes, monthly cost per resource | Yes |
Each native tool is good within its scope, and the scope is the problem. An estate is not one provider's resources; it is everything the company pays for, and the questions asked of an inventory, what does this cost and who do I ask, are the two columns the native tools lack.
What Goes Missing Without One
- Projects and subscriptions nobody owns. Created for a proof of concept, a migration, a contractor, or a sandbox, and still running after the person left. On GCP and Azure especially, where project and subscription creation is easy, these are usually the largest first finding.
- Orphans inside owned accounts. Volumes, addresses, snapshots, load balancers, and gateways left behind by resources that were deleted, inside accounts that are otherwise managed.
- Resources with an owner who left. Tagged correctly, to someone who is no longer there, so the tag is worse than nothing: it answers the question wrongly.
- Clusters and warehouses outside the cloud inventory. Kubernetes workloads and Snowflake warehouses are resources too, and no cloud inventory lists them.
- Compliance drift. The public bucket, the unencrypted disk, the resource outside the approved region: a security finding and a cost finding on the same item, found twice by two teams or not at all.
How Opslyft Solves It
Step 1: Connect every provider, read-only
Atlas connects to AWS accounts and organizational units, Azure subscriptions and management groups, GCP projects and folders, and OCI tenancies with read-only access, plus Kubernetes clusters through their metrics and Snowflake through its account usage views, and builds one inventory of every resource across all of them, normalized so that an EC2 instance, an Azure VM, a GCE instance, an OCI compute instance, a Kubernetes namespace, and a Snowflake warehouse are rows in the same list with the same columns.
Step 2: Every resource gets an owner
Ownership is read from tags and labels where they exist and inferred where they do not, from account, subscription, and project structure, naming conventions, Kubernetes namespaces, and resource relationships, through the same rules Dimension Studio uses for allocation. Atlas tracks ownership in real time so nothing runs without an owner, and resources whose owner cannot be inferred are flagged rather than hidden, which is how allocation coverage typically rises from around 60 percent to 95 percent or higher within 30 days.
Step 3: Every resource gets a cost
Billing data is joined to the inventory so each resource carries its monthly cost, which is the column that turns a list into a priority: 1,400 unattached volumes sorted by cost is a plan, the same 1,400 as a list is a chore. For Kubernetes, node cost is allocated to namespaces; for Snowflake, credits are converted to dollars per warehouse.
Step 4: The forgotten are flagged continuously
Atlas flags resources with no recent activity, no surviving parent, no owner anyone recognizes, or an owner who has left, across every provider, as they occur rather than at the next audit, and its recommendations weigh purpose and criticality so a quiet production resource and an abandoned test resource get different advice. Compliance status is tracked on each item, so the public bucket is a cost finding and a security finding in one place.
Step 5: Change history explains how it happened
Every modification is recorded: when the instance was terminated and the volume stayed, when the project was created and by whom, when the owner's account was deactivated. A cost movement traces to the change that caused it, and the fix is the template or process that created the orphan, which is what stops the next one.
Step 6: Findings become tickets, and the inventory feeds everything else
Tickets routes each finding to its owner, or to the team that inherits an unowned resource, as an assigned item in Jira, ServiceNow, or Asana with the cost and the recommended action, tracked to closure. Monitor uses the inventory's change history to explain anomalies, rightsizing uses its purpose and criticality, governance policies evaluate against it, chargeback traces every line to it, and Iris answers which accounts and projects have the most unowned resources in plain English. The inventory is not a report; it is the foundation the rest of the platform runs on.
A Worked Example
A company runs 52 AWS accounts, 18 Azure subscriptions, 140 GCP projects, and an OCI tenancy, with four EKS and GKE clusters and Snowflake. Four inventories exist, one per provider, none with cost or owner on anything, and the last attempt to build a master list in a spreadsheet took a quarter and was wrong by the time it was finished.
Atlas inventories 61,000 resources across all four providers within a day of read-only connection. Tags cover 58 percent of spend; inferred ownership from account structure and naming takes it to 93 percent in the first week. The findings: 31 GCP projects and 4 Azure subscriptions with no active owner and no deployment in six months, $47,000 a month; 2,100 orphaned volumes, addresses, snapshots, and load balancers across AWS and Azure, $19,000; 410 resources tagged to people who have left, reassigned to their teams; two Kubernetes namespaces and one Snowflake warehouse with no owner, $11,000; and 60 resources out of compliance with the region and encryption policy. Tickets go to the teams that own or inherit each item; the unowned projects are reviewed and 26 are decommissioned within a month. Monthly spend falls by about $64,000 from resources nobody was using, the master list exists and stays current, and the next unowned project is a ticket the week it is created.
Proof: a leading fintech, 95 percent visibility across $40 million on GCP. A leading fintech running a $40 million GCP estate across more than two hundred projects could not say which teams and products its spend belonged to. With Opslyft's inventory and ownership inference across project structure, allocation coverage reached 95 percent and unattributed cloud cost fell by 75 percent, giving finance a complete picture of what was running and who was responsible for it. Read the full story: How a leading fintech achieved a 75 percent reduction in unattributed cloud costs
The same inventory across six platforms gave Disprz 100 percent automated attribution, and surfaced the idle resources behind Purplle's $200,000 first month.
Use Opslyft If
- You run dozens of accounts, subscriptions, or projects and nobody has one list of what is running.
- Native inventories exist per provider and carry neither owner nor cost.
- Unowned projects, subscriptions, and resources are found by accident, usually on the invoice.
- Resources are tagged to people who have left.
- Kubernetes and Snowflake sit outside every inventory you have.
- Cost and security teams find the same unmanaged resources separately.
- You want the inventory to drive allocation, rightsizing, anomalies, and governance, not only cleanup.
If you run one provider and a handful of accounts that one team knows, its native inventory and a tag policy will serve. The platform earns its place when the estate is larger than anyone can hold in their head.
The Bottom Line
A cloud asset inventory is not a list of resources; it is a list of resources with an owner and a cost on each, across every provider, kept current. That is the thing the native tools do not provide and the thing every other cost and governance practice depends on, because a finding without an owner is never acted on and a resource without a cost is never prioritized. Opslyft's Atlas is that inventory across AWS, Azure, GCP, OCI, Kubernetes, and Snowflake, and the forgotten projects, orphaned resources, and departed owners it surfaces are the first month's savings and the foundation of everything after. It is what Opslyft's cost governance is built on; the AWS-specific cleanup it enables is in our walkthrough of finding unused AWS resources.
FAQs
A cloud asset inventory is a single, current list of every resource running across an organization's cloud accounts, subscriptions, and projects, with what each one is, where it is, who owns it, and what it costs. It is the cloud equivalent of the configuration management database (CMDB) that on-premises IT ran for decades, and most cloud estates lost it: each cloud has its own inventory service per account, none has cost on each item, and none spans providers.
Because each provider's inventory is scoped to that provider and to one account or subscription at a time: AWS Config per account and region, Azure Resource Graph per subscription, Google Cloud Asset Inventory per project or organization, OCI's own. None carries the owner or the monthly cost on each resource, none normalizes across providers, and an estate with forty accounts on three clouds has no single list of what is running or who is responsible for it.
Three things: ownership, since a resource's tags are often missing and no native inventory infers an owner from structure; cost, since inventories list resources and bills list charges and nothing joins them per item; and the estate, since each tool stops at its provider and its scope. The result is a list that cannot say what a resource costs or who to ask about it, which is the information needed to act.
Atlas connects read-only to every account, subscription, and project on AWS, Azure, GCP, and OCI, plus Kubernetes clusters and Snowflake, and keeps one live inventory of every resource with an owner, a cost, and a compliance status on each, inferring ownership from tags, account structure, naming, and relationships where tags are missing. A change history records every modification, so forgotten resources are found and the change that orphaned them is known.
By having everything in one list with an owner and a cost. Forgotten resources are the ones with no recent activity, no surviving parent, no owner anyone recognizes, or an owner who left: the proof-of-concept project on the secondary cloud, the subscription a contractor created, the volume left behind by a terminated instance. Atlas flags them continuously, prices them, and routes each to an owner as a ticket.
It is the foundation for most of Opslyft. Allocation needs an owner on every resource; rightsizing needs purpose and criticality; anomaly root cause needs change history; governance policies need something to evaluate against; chargeback needs every line traceable to a resource. The inventory is what makes each of those safe to act on, which is why Opslyft calls it a Cloud CMDB rather than a list.
Resources across connected accounts appear within hours of read-only connection, with idle and orphaned items flagged on day one. Ownership inference and allocation coverage build over the first days as account structure and metadata are mapped; coverage typically reaches 95 percent within 30 days. A leading fintech reached 95 percent visibility across a $40 million GCP estate of more than two hundred projects.