Cloud Discovery Tools: Six Ways to Find What Is Running in Your Cloud

Cloud discovery tools build an inventory of the resources running in your cloud accounts by reading the provider APIs, so you can see what exists without relying on documentation, tags, or Terraform state. They fall into six groups: the provider's own inventory services, open-source query tools, graph tools, cloud security platforms, CMDB discovery, and discovery built around infrastructure as code.

The groups answer different questions. A tool that is excellent at "what can reach this database?" may have nothing to say about "which of these resources has no code behind it?" This guide describes each approach, what it is good and bad at, and how to pick one by starting from the question you need answered.

One note on terminology. "Cloud discovery" is also the name of a feature in Microsoft Defender for Cloud Apps that finds SaaS applications in use by analyzing traffic logs. That is shadow IT discovery. This guide is about cloud resource discovery: finding the virtual machines, databases, buckets, networks, and identities inside your AWS, Azure, Google Cloud, or Oracle Cloud accounts.

What a cloud discovery tool does

Every tool in this space does some version of three jobs, and the differences between tools are differences in how far each job goes.

• Enumerate. List every resource in every account, subscription, project, and region. This sounds simple and is where most gaps hide: an account nobody enrolled, a region nobody uses, a resource type the tool does not support.

• Enrich. Attach context to each resource: its configuration, tags, owner, cost, what it depends on, and what depends on it. A list of 4,000 resource IDs is an inventory. It becomes useful when you can ask which of them are public, unowned, or unmanaged.

• Keep current. Refresh on a schedule or from change events, and record when each resource was last seen. An inventory without a timestamp is a historical document.

The six approaches

1. Provider inventory services

Each cloud ships its own inventory. AWS has Resource Explorer for search across regions and accounts, and AWS Config for recording configuration and its history. Azure has Resource Graph, queried with Kusto Query Language across subscriptions. Google Cloud has Cloud Asset Inventory. All four are read from the command line:

# AWS: every EC2 instance the index knows about
aws resource-explorer-2 search --query-string "resourcetype:ec2:instance"

# Azure: resource count by type, across subscriptions
az graph query -q "Resources | summarize count() by type | order by count_ desc"

# Google Cloud: every Compute Engine instance in an organization
gcloud asset search-all-resources \
  --scope=organizations/123456789012 \
  --asset-types=compute.googleapis.com/Instance

Good at: being authoritative and close to free. There is nothing to install, and the data comes from the same control plane that runs the resources.

Weak at: anything beyond one cloud. Each service covers its own provider, supports a published list of resource types that is never the full catalog, and has no idea whether a resource is managed by code. Resource Explorer must be turned on with an aggregator index before cross-region search works, and AWS Config charges for each configuration item it records.

2. Open-source query tools

Steampipe and CloudQuery let you treat cloud APIs as tables. Steampipe, from Turbot, runs SQL against the live APIs and returns the answer directly. CloudQuery syncs cloud configuration into a database or warehouse you choose, where you query it later. Both cover many providers through plugins.

-- Steampipe: EC2 instances with no owner tag
select instance_id, instance_type, region
from aws_ec2_instance
where tags ->> 'owner' is null;

Good at: ad hoc questions across clouds, by engineers who are comfortable with SQL. The same query style works for AWS, Azure, Google Cloud, Kubernetes, and SaaS tools, and results drop into dashboards or scripts.

Weak at: being a product. You run it, schedule it, manage its credentials, and write the queries. The output is tables, so relationships between resources are joins you write yourself. Check the licensing before building on either: Steampipe is published under AGPL 3.0, and CloudQuery keeps its command-line tool and SDK open source while many of its provider plugins follow an open-core or paid model.

3. Graph tools

Cartography, a Cloud Native Computing Foundation sandbox project that began at Lyft, pulls assets from cloud accounts, Kubernetes, and SaaS services into a Neo4j graph. Resources become nodes and their relationships become edges, so a question such as "which roles can reach this bucket, and who can assume them?" is a graph query, not a chain of joins.

Good at: relationship questions, especially for security teams tracing access paths.

Weak at: the operational side. You run the sync jobs and the graph database, and the model is built for security analysis more than for day-to-day infrastructure ownership.

4. Cloud security platforms

Cloud security posture management and cloud-native application protection platforms, such as Wiz, Orca Security, and Prisma Cloud, connect to accounts without agents and build a detailed inventory as the basis for their findings. For many organizations this is the most complete inventory they own, even though inventory is not what they bought it for.

Good at: risk context. Each resource comes with its exposure, vulnerabilities, and the identities that can reach it. Cloud security posture management explained covers how these platforms work.

Weak at: serving anyone outside security. Access is often limited to the security team, the inventory is organized around findings, and the link from a resource back to the code that should manage it varies a lot by product.

5. CMDB discovery

IT service management platforms, with ServiceNow Discovery as the best-known example, populate a configuration management database with cloud resources as configuration items. The point is to connect infrastructure to the change, incident, and asset processes the rest of the organization already runs.

Good at: fitting cloud resources into existing IT governance, where a change request must reference a configuration item.

Weak at: keeping up. A CMDB models long-lived items with owners and lifecycles, and cloud resources that are created and destroyed by autoscaling or pipelines many times a day fit that model poorly. Expect modelling work and a sync delay.

6. IaC-aware discovery

The newest group compares the live inventory with infrastructure-as-code state. Each resource is classified as managed by code, unmanaged, or drifted from its code, and the tool can generate Terraform or OpenTofu for the resources that have none. ops0 and Firefly work this way.

Good at: the question the other five cannot answer: what exists that our code does not know about, and how do we bring it under code? It turns discovery from a report into a backlog.

Weak at: being a general-purpose query engine or a full security scanner. The value depends on your team using infrastructure as code, or wanting to.

In ops0, discovery scans AWS, Google Cloud, Azure, Oracle Cloud, and Kubernetes read-only across more than 230 resource types, maps dependencies between resources, grades each account, and generates Terraform or OpenTofu for the resources you select, which then go through plan, policy, and approval like any other change.

The approaches side by side

How to choose: start from the question

Most teams end up with two of these, because no single approach answers every question. Picking the first one is easier when you write down the question that is blocking you.

How to check any inventory before you trust it

An inventory that is 90 percent complete is dangerous, because the missing tenth is where the forgotten resources are. Whatever tool you choose, test it against these six failure modes.

• Resource type coverage. Ask for the list of supported types and compare it with the services you use. Newer and niche services are the usual gaps.

• Region coverage. Confirm that every enabled region is scanned, including the ones your team believes are empty.

• Account coverage. Check that a newly created account or project is enrolled automatically. If enrollment is manual, the newest accounts are the unscanned ones.

• Permission errors. A scan that lacks permission to list a service often reports zero resources, not an error. Look for the access-denied count in the scan output.

• Freshness. Every record should carry the time it was last seen. Decide how old is too old for the question you are asking.

• Stable identifiers. Each resource needs its provider ID, such as an ARN, so two tools can be reconciled and a resource can be found again.

The fastest completeness test uses a source that cannot miss anything: the bill. List spend by service for the last full month, then check that every service with spend has resources in the inventory.

aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-11-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[].[Keys[0],Metrics.UnblendedCost.Amount]' \
  --output table

A service that costs money but shows nothing in the inventory is a coverage gap, and it is a much shorter list to investigate than the whole account.

From inventory to action

Discovery is finished when every resource on the list has a decision against it, not when the list exists. For resources with no code behind them, usually the result of ClickOps, there are three choices: import it into code, delete it, or record why it stays as it is.

Importing is the common one. Generating Terraform from existing AWS resources walks through import blocks and what to review in the generated code. For resources that are already in code, Terraform drift detection covers keeping them matched to it. And if the inventory is feeding an audit, the cloud infrastructure audit checklist starts with exactly this step, because every later check samples from the inventory.