multi-cloud asset inventory

every resource in every cloud you run — and how they connect.

disco asks every service in every account itself, so it finds what aws resource explorer, azure resource graph, and google cloud asset inventory miss — then records what connects to what.

You grant a role, not a key. A first scan takes about five minutes with nothing to install, and 3 cloud accounts are free, with no card.

an inventory summary of 4,940 resources, broken down by type, region and account, with aws, azure and google cloud types in the same list and 54% tagging coverage
4,940 resources from three clouds, counted by type, region and account in one view.

~300 aws services ~150 azure services ~40 gcp services

Approximate, and never final: no cloud is fully covered yet — disco measures its own gap and closes it. what disco reads in each cloud.

who asks, and what disco shows them

team the question what disco shows
security & compliance what did this security group allow in june?
  • every version of every resource, from every scan
  • a tamper-evident log of what was done in disco, mapped to soc 2 and iso 27001 controls on export
  • service limits with change history, including the ceilings only the provider moves
  • sso (oidc and saml), with read-only auditor and compliance-admin roles
incident response what can this compromised role reach?
  • a scan you can run during the incident — one aws account in five to six minutes
  • everything a compromised role can reach, grouped by how many steps away
  • trust between two accounts resolves to the real resource on the far side
  • see who is signed in, and sign them out
cost & chargeback what did each account actually cost?
  • cost allocation in FOCUS 1.4 — each billing line matched to the resource it paid for
  • what each account cost, with the unmatched shown as its own number
  • tag coverage rate, and untagged filters on the inventory itself
  • service limits per account and region, total or rate, so headroom is a number

a console shows one account at a time.

one inventory across every account you didn't set up

A bill shows service names, not things you can point at. Rebuilding the picture by hand is a week of somebody's time, it is out of date when it lands, and the next account starts over.

blast radius: what breaks if i change this?

Open any resource and see everything it reaches, grouped by how many steps away each thing is. Each connection is labeled with what it actually is — 11 kinds, worked out after the scan, not guessed from names. all 11, and what each one means.

a diagram of one security group at the center of a ring of the fourteen resources one step away from it, each labeled with its type — network interfaces, other security groups, an iam role, a log group, a snapshot — and each connection drawn as an arrow showing which way it runs
one security group, one step out: every resource one hop away, and which way each connection runs. The depth control is the ring count.

the inventory is the audit evidence

A scan stores the resource itself — tags, configuration, the provider's own attributes — and keeps every version from every scan. So the record answers questions asked afterwards: what this security group allowed in june, which accounts had public buckets then, when that role first appeared.

Service limits too, including the ceilings only the provider can move, and does, without telling anyone.

a service limit that cannot be raised on request, showing 80,000 write units superseded and 40,000 current
80,000 write units, halved to 40,000. The old value is still on file.

four steps, and none of them is handing over a key.

  1. a role, not a key

    A cloudformation stack on aws, lighthouse on azure, workload identity federation on google cloud. We keep your account number and a record of what you granted — never a password or a key.

  2. ask each service, then join it up

    disco asks each service what it holds, then works out how those things connect. If your own policies block something, that part is reported as a gap and the scan carries on.

  3. filter, then follow the connections

    Filter by cloud, account, region, service, type, what the provider created rather than your team, or what nobody tagged — or search for a name you half remember. Open anything and follow its connections outward, in either direction.

  4. an api and a message when something changes

    A rest api of 79 operations with an openapi spec your tools can read. Slack, or a signed call to a service of your own, every time a scan finishes.

a scan takes a few minutes. nothing to install.

the part of disco that reaches into your cloud is open source.

Run it against your own account before you talk to us: no signup, nothing sent anywhere, mit licensed.

No analytics, no third-party trackers, no ad tech — machine-readable at an address you can fetch right now, and a test fails our build if any of it is ever switched off.

connect one account. in about five minutes, the list and everything it connects to.

3 cloud accounts, unlimited seats, no card. what pro costs, and what counts as a cloud account.