Prerequisites
Everything you need to gather before connecting your first cloud account or site — most teams get from zero to a fully-discovered topology in under an hour.
Before you start
LatencyLabs connects to your cloud accounts and sites read-only — it never requires write access to your infrastructure, and no production systems are modified. Setup has three parts: granting read-only cloud access, deploying the Collector at any on-prem sites, and opening one outbound port. Most of this can be done by a single network or cloud administrator without a change window.
~1 hr
Target time to first topology view
Read-only
No write access requested from any provider
1 port
Outbound HTTPS is the only firewall change
Cloud account access
Each provider connects with a scoped, read-only credential — the exact same auth methods shown in the Integrations portal. Have the relevant credential ready before starting the connection wizard.
Amazon Web Services
Cross-account IAM role
Read-only: ec2:Describe*, directconnect:Describe*, ce:GetCostAndUsage, and VPC Flow Logs read access.
Microsoft Azure
Service principal (client credentials)
Reader role on the subscription, plus Network Contributor (read-only scope) for NSG and ExpressRoute metadata.
Google Cloud Platform
Service account (JSON key)
Viewer role on the project, plus compute.networks.list / compute.routers.list for topology discovery.
Oracle Cloud Infrastructure
API signing key
Read-only IAM policy on the tenancy: allow group LatencyLabsReaders to read virtual-network-family in tenancy.
On-prem Collector requirements
On-prem data centers, branch offices, and manufacturing sites are monitored by the Collector — a single VM appliance per site, authenticated via mutual TLS, with no cloud IAM involved. It deploys on VMware, Hyper-V, Nutanix, or bare-metal.
Supported deployment forms
- VMware vSphere — OVA import
- Microsoft Hyper-V — VHDX import
- Nutanix AHV — qcow2 image
- Bare-metal — Linux, Windows Server, or container image
Minimum resources
- 4 vCPU, 8 GB RAM, 40 GB disk (2 vCPU / 2 GB / 500 MB for bare-metal)
- Outbound-only network access (no inbound rules)
- NTP sync recommended for accurate latency timestamps
Network & firewall rules
A single outbound allow-list entry covers every connector and the Collector. Nothing needs to be opened inbound.
| Purpose | Direction | Port / Protocol | Notes |
|---|---|---|---|
| Collector → LatencyLabs ingestion | Outbound | TCP 443 | HTTPS to ingest.latencylabs.io. TLS 1.2+. No inbound firewall changes required for any provider. |
| Site-to-site connectivity test | Outbound | ICMP, TCP 443 / 80 | Used by the Collector to run latency and reachability probes between monitored sites. |
| Cloud API polling | Outbound | TCP 443 | Each cloud connector calls its provider's public API endpoints (e.g. ec2.*.amazonaws.com). |
| Dashboard access | N/A | TCP 443 | Your team's browsers connect to app.latencylabs.io — no VPN required. |
Team & roles
Setup usually involves two or three people, briefly:
Cloud / platform admin
Creates the read-only IAM role, service principal, or service account for each provider.
Security or network team
Approves the single outbound HTTPS allow-list entry for the Collector and connectors.
Site contact (per location)
Deploys the Collector VM on-site (OVA/VHDX/qcow2 import) or via existing config management.
Dashboard requirements
The dashboard runs entirely in-browser — no VPN or desktop client needed.
- Latest two versions of Chrome, Edge, Firefox, or Safari
- JavaScript enabled
- 1280px+ viewport recommended for the topology and business-impact maps
What gets discovered automatically
Once connected, LatencyLabs builds your topology without any manual mapping:
- Cloud regions and on-prem sites
- WAN links, VPNs, and direct-connect circuits
- Perimeter firewalls and security groups
- Egress cost and bandwidth baselines
Ready to connect your first data source?
Explore the interactive demo to see exactly what the connection flow looks like, or join the waitlist to get started with your own environment.