Infrastructure Discovery: Turning Unknown Cloud State into Reviewable Code

Infrastructure discovery inspects connected cloud accounts and collects supported resources, configuration, and relationships. ops0 Discovery helps map that inventory into reviewable Terraform. Coverage and scan duration depend on permissions, regions, resource types, API limits, and the size of the account. Generating code does not by itself import state or establish that a plan is safe to apply.

Discovery replaces uncertainty with a sourced view of the resources it can inspect. Check the scope, collection time, and scan errors before using that view to plan an infrastructure change.

The Actual Problem

Cloud infrastructure is undocumented by default.

Cloud APIs let you create resources without recording the intended design in a repository. Terraform state tracks managed and imported objects. AWS Config records supported-resource configuration, relationships, and history. Discovery helps bring these different views into an infrastructure workflow.

The result: no single system has a complete, current, dependency-aware view of your infrastructure.

Manual audits don't fix this. Clicking through the AWS console for three days produces a snapshot that's already wrong by the time it's finished. Terraform import at scale is slow, brittle, and blind to relationships. Existing discovery tools list resources but stop short of explaining how they connect.

Discovery is built to solve that gap.

What Discovery Does

Discovery scans your cloud provider APIs and builds a snapshot within the configured coverage:

• Supported resources and the configuration available through the connected APIs

• Relationships and dependency direction

• Regional and cross-service connections

• Cost and metadata context

Each scan produces a point-in-time model you can diff over time, turning undocumented infrastructure into something observable, reviewable, and eventually manageable.

This isn't a compliance report or a static inventory. It's a living infrastructure graph.

Why Relationship Mapping Comes First

Most tools stop at "what exists." Discovery focuses on how things depend on each other.

Take a single EC2 instance. Discovery understands that it:

• Lives inside a specific VPC and subnet

• Depends on one or more security groups

• References IAM roles and instance profiles

• Attaches to EBS volumes

• May route traffic through other network constructs

These relationships are classified and directional (contains, uses, attached_to, routes_to, references), which enables two things most tools can't do reliably:

Correct Terraform ordering

Review generated references and explicit dependencies against the provider schema and intended ownership. A dependency map helps organize the code, but the infrastructure plan still needs review.

Real blast radius analysis

Inspect connected resources to assess the potential impact of changing a subnet, security group, or role. Configuration relationships are context for that review, not proof of every runtime dependency.

This is the difference between an inventory and an infrastructure model.

The Technical Architecture

Scanning large environments requires pagination, rate-limit handling, incremental persistence, and visibility into failures. Review the completed coverage before relying on a result.

Parallel regional scanning

Multiple regions are scanned simultaneously. If you select us-east-1, us-west-2, and eu-west-1, all three run in parallel.

Specialized scanners

Specialized scanners focus on domains such as networking, compute, databases, and identity. Check which resource types are supported for the selected provider and region.

Rate-limit aware execution

API calls are throttled intentionally to avoid AWS limits. Speed comes from parallelism, not brute force.

Incremental persistence

As each region completes, results are written immediately. Large accounts don't cause memory spikes or timeouts.

Resume by checkpoint

If a scan fails halfway through (network issues, transient API errors), it resumes from the last completed checkpoint instead of starting over. This is critical in large or unstable environments and is rare among discovery tools.

Measure collection time in your account

Record the selected regions, resource coverage, last successful scan, duration, and any skipped or failed requests. This article does not include a reproducible benchmark for a universal scan time.

What Gets Discovered

Discovery supports all major clouds:

AWS: 100+ resource types including EC2, VPC, S3, RDS, Lambda, EKS, ECS, IAM, Route53, CloudFront, and more

GCP: Supported assets available through the connected inventory APIs

Azure: Supported compute, network, storage, and platform resources in connected subscriptions

For each supported resource, inspect the available configuration, tags, metadata, region, and relationships. Collection coverage depends on the API and connected identity.

From Brownfield to Managed Code

Legacy infrastructure doesn't have to stay legacy.

Discovery can generate Terraform for selected resources. Review the code, identify any existing state or stack owner, adopt the selected objects into state, and inspect the plan before taking over management. You decide which resources belong in the workflow.

Automation reduces manual inventory and code-drafting work. Adoption effort still depends on provider coverage, dependencies, unsupported settings, and the review needed for your environment.

Why This Matters in Practice

Security

You can't secure what you can't see. Discovery surfaces forgotten databases, overly permissive security groups, and public exposure with full context.

Audits and compliance

Use the inventory and relationships as evidence with a recorded scope and collection time. Retain the policy results, change records, and historical observations needed for the actual control under review.

Operational speed

Knowing what exists and what depends on it turns risky changes into informed decisions.

Discovery Inside the ops0 Platform

Discovery is the foundation layer:

Discovery + IaC: Scan reality, generate Terraform, deploy from intent

Discovery + Resource Graph: See drift between state files and real infrastructure

Discovery + Operational Visibility: Infrastructure changes are understood with full dependency context

Visibility isn't the end goal. Control is.

The Workflow

1. 1Connect your cloud accounts (AWS, GCP, Azure)
2. 2Discovery scans automatically
3. 3Review the discovered graph and its coverage
4. 4Generate IaC for selected resources
5. 5Schedule scans and review collection failures

Keep permissions, scope, state ownership, and scan health under review.

From Chaos to Clarity

Infrastructure chaos isn't a failure of discipline; it's the default state of unmanaged systems.

Discovery replaces guessing with recorded observations and shared resource context. Use that evidence alongside the source of record and the proposed plan.

Once you know exactly what you have, the real question becomes: what do you want to do with it?