You Can't Troubleshoot What Crosses Clouds in the Dark: Observability for the Space Between Clouds

Every multi-cloud estate has a blind spot, and it sits in the same place: between the clouds. Inside one provider, teams have flow logs, metrics, and traces. Inside the application, they have structured logging and APM. But a request that leaves AWS, crosses a private interconnect, and lands in Azure passes through a stretch of network that often belongs to no dashboard, no alert, and no owner. When that request slows down, each side reports itself healthy — and both reports are true, and neither is useful.

Observability for the space between clouds is not about buying another monitoring tool. It is about making the cross-cloud path a first-class, measurable thing: named, instrumented at both ends, probed continuously, and recorded in a form the next engineer on call can actually use at 3 a.m.

1. Each cloud describes the same packet differently

The first problem is vocabulary. VPC flow logs, NSG flow logs, and their equivalents in other providers record similar events in different fields, at different sampling rates, with different delays — some arrive in minutes, some in tens of minutes, and some drop records silently under load, exactly when they matter most.

Practical implications:

• Normalize at collection, not during an incident. Decide on one common record — source, destination, ports, bytes, action, path identifier, timestamp — and translate each provider's format into it in the pipeline. Translating by hand during an outage burns the first hour.
• Know your sampling gaps. A sampled flow log can prove a path was used; it often cannot prove a path was not used. Write down, per provider, what is sampled, what is aggregated, and what is missing. Absence of evidence in a flow log is not evidence of absence.
• Fix the clocks first. Cross-cloud correlation falls apart when timestamps disagree. If the estates are not disciplined about NTP and time zones in logs, a five-minute skew makes two halves of the same connection look unrelated. Clock health is observability infrastructure.
• Tag the path, not just the workload. A flow record that says which interconnect, gateway, or peering it crossed is worth ten records that only name the instances. Paths need identifiers as stable as service names.

2. Passive logs tell you what happened; probes tell you what is happening

Flow logs are historical. By the time they are queryable, an intermittent cross-cloud problem may be gone — and it will be back. Synthetic probes close that gap: small, continuous, deliberate traffic over the exact private paths production uses.

• Probe the real path, not a shortcut. A probe that goes over the public internet to a public endpoint tests a different network from the one the workload uses. Probes should travel the private interconnect, hit a private endpoint on the far side, and measure latency, loss, and jitter on that route.
• Probe in both directions. Multi-cloud paths are frequently asymmetric — different gateways, different return routes, different failure modes each way. A green probe in one direction says nothing about the other.
• Keep probes boring and constant. The value is the baseline. A probe that runs every minute for a month gives an on-call engineer the single most useful sentence in troubleshooting: "this path is normally 12 ms, and right now it is 180 ms." Without a baseline, every measurement is an opinion.
• Alert on the path, separately from the application. If the application alert and the path alert are the same alert, the first diagnostic question — is it the app or the network between clouds? — has to be answered manually every time. Separate path alerts answer it before a human opens a laptop.

3. Correlate across the gap, or do not bother collecting

Logs that cannot be joined are archives, not observability. A connection that crosses clouds changes its identifiers at the boundary: one provider's flow ID ends, another's begins, NAT may rewrite the source, and the application trace — if there is one — rarely includes the network segment at all.

• Carry one correlation ID end to end. Where the application can stamp a request ID, keep it in logs on both sides. Where it cannot, correlate on the tightest available tuple: endpoints, ports, byte counts, and a narrow, clock-corrected time window.
• Record NAT translations as first-class events. Many "the logs don't match" mysteries are simply a translated address nobody logged. If a gateway rewrites addresses between clouds, its translation table is part of the observability data, not an afterthought.
• Build one view, even if it is simple. A single page — however plain — that shows per-path latency, loss, probe status, and recent changes for every cross-cloud link beats four provider consoles open in four tabs. Incidents are not the time to assemble a mental join across consoles.
• Log changes to the path itself. Route withdrawals, gateway failovers, firewall policy pushes, and certificate rotations on the interconnect should land in the same timeline as the metrics. Most "mystery" degradations stop being mysteries when the change log shares a screen with the graph.

4. Measure what users feel, at the segment where it happens

Aggregate cloud metrics tend to report averages over an hour — a format in which a nine-minute total stall can hide inside a healthy-looking mean. Cross-cloud problems are disproportionately tail problems: retransmits from an MTU mismatch, a congested interconnect at a peak minute, a route that flaps for ninety seconds.

• Track percentiles and loss per path, not just throughput. Throughput can look normal while loss quietly destroys latency-sensitive traffic such as database replication or inference requests. Loss and retransmit rates per path surface that.
• Segment the measurement. End-to-end latency says something is wrong; per-segment latency — inside cloud A, across the interconnect, inside cloud B — says where. Even coarse segmentation cuts troubleshooting time more than finer end-to-end data does.
• Retain enough history to argue with. Cross-cloud disputes between teams, and occasionally providers, are settled by records. Keep path metrics and flow records long enough to cover the argument you will actually have — weeks, not days — and keep them somewhere reachable when one cloud is not.
• Test the observability, not just the network. Withdraw a route or block a probe target in a maintenance window and check that the dashboard shows it and the alert fires. An untested alert is in the same category as an untested backup.

5. Where managed connectivity fits

Keeping normalized flow data, bidirectional probes, and a single per-path view in place across AWS, Azure, Google Cloud, and Oracle is steady work that competes with feature delivery for the same engineers. That is the layer specialist providers operate in. CloudVerg, for example, focuses on private cloud and AI connectivity for US businesses — VergMesh for multi-cloud networking, VergRail for observability and operations across those paths, VergForge for building workloads, VergMind for AI infrastructure connectivity, and VergShield for zero-trust security and SOC 2 readiness: https://cloudverg.com

Built in-house or with outside help, the standard is the same: when a cross-cloud request slows down, the first screen an engineer opens should already say which segment changed, when it changed, and what normal looks like.

A short checklist

• [ ] Flow records from every provider normalized into one common format at collection time
• [ ] Sampling gaps and log delays documented per provider; clocks verified across estates
• [ ] Every cross-cloud path named, with a stable identifier used in logs and dashboards
• [ ] Bidirectional synthetic probes running over the real private paths, with baselines kept
• [ ] Path alerts separated from application alerts, and tested in a maintenance window
• [ ] NAT translations logged; one correlation method agreed for requests that cross clouds
• [ ] Per-path latency percentiles, loss, and retransmits tracked — not just throughput
• [ ] Network changes (routes, gateways, policies) recorded on the same timeline as metrics
• [ ] Path metrics and flow records retained for weeks and reachable during a single-cloud outage

Teams rarely lack data about their clouds. They lack data about the space between them — and that space is where multi-cloud problems live. Instrument the paths themselves, probe them continuously, and give them an owner and a dashboard, and the next cross-cloud incident starts with evidence instead of archaeology.