Where the application sits, how it reaches your other clouds, and the one connection that leaves your account.
The application can be deployed in AWS, Azure or Google Cloud. A lightweight collector runs in every cloud it covers — including the one hosting the hub itself, the same as any other. The diagram below shows an AWS deployment as the example — put the hub in Azure or Google Cloud instead and the shape is identical, only the labels move.
The hub runs in your account. Compute, database, web interface, authentication and scheduling all sit inside a cloud account you own — AWS, Azure or Google Cloud, your choice. The hub itself has no scanning code of its own; a collector deployed alongside it covers that account the same way collectors cover every other one.
Collectors cover every cloud. Read-only and scheduled, one runs in each cloud account — including the hub's own — enumerating and pricing resources and pushing normalized findings back to the hub. Only findings and effective costs move between clouds — raw billing exports and configuration dumps do not.
Every connection is outbound. Collectors open them, so there are no inbound ports, public listeners or inbound firewall rules to add anywhere.
One thing crosses the boundary. The hub sends a licence ID and version string to us, and gets entitlement and version information back. No resource data, no cost figures, no account identifiers. The compliance page lists every connection in full.
Want this walked through against your own environment? Email support@cloud-vex.com.
Join the waitlist