How the maps are built

• From one virtual machine in each cloud region, scamper runs ICMP-echo traceroutes to one address in every routed IPv4 /24 (about 12.2 million targets). For Google Cloud IPv6, it probes one address per announced IPv6 prefix (about 254,000 targets).
• Each hop is assigned to a network: if the address is a member port on an Internet exchange's peering LAN, the member's ASN; otherwise the origin AS of its covering prefix in RouteViews for the measurement date.
• What the maps count as a peer is, strictly, a neighbor network: the first network a path enters after leaving the cloud's own networks, seen at two consecutive responding hops. It may be a settlement-free peer, a transit provider, or a customer.
• Each peer interface is placed in a city using IPInfo geolocation and, where its router hostname encodes one, CAIDA HOIHO.

Premium versus standard routing

Where a cloud hands outbound traffic to the rest of the Internet is partly a product choice. Two strategies bracket it: cold-potato routing carries traffic on the provider's own backbone as far as possible and hands it off near the destination, while hot-potato routing hands it off near the cloud region and lets other networks carry it the rest of the way. Which one a measurement used strongly shapes which neighbors and which interconnection cities a traceroute from that region can see.

• Google Cloud exposes the choice as Network Service Tiers. In the Premium Tier (the default), outbound traffic "typically routes over the Google global network to a point of presence that's as close as possible to the internet user". In the Standard Tier, it "is sent through a peering or transit network in a point of presence near the region". External IPv6 addresses are available only in the Premium Tier.
• Microsoft Azure exposes it as routing preference on a public IP. The default, the Microsoft global network, is what Microsoft describes as cold potato: egress "exits closest to the user". The Internet option is its hot-potato counterpart: traffic "exits Microsoft network in the same region". It is IPv4-only and cannot be changed after the address is created.
• Amazon Web Services has no equivalent setting for an instance's Internet traffic, and we found no AWS documentation of where EC2 egress leaves its network. Global Accelerator brings inbound traffic onto the AWS backbone at an edge location, but does not change how an instance reaches the Internet.

What these maps used. Google Cloud IPv4 was measured on the Standard Tier and Google Cloud IPv6 on the Premium Tier, because Google offers external IPv6 only there; every instance's tier was checked and recorded at launch. Azure public IPs used the default routing preference, the Microsoft global network. AWS instances used ordinary public addresses, with no option to set. So on the September Google Cloud map the IPv4-versus-IPv6 comparison also compares Standard with Premium routing, and the two cannot be separated from these data.

Our data do not yet show the difference cleanly. IPv6 neighbor sets are more uniform across regions than IPv4 ones (a median overlap between two regions of 0.91 against 0.84; the least similar IPv4 pairs all involve Johannesburg). That is consistent with Premium routing, but the address family and the 50-fold difference in target count could produce it too. Geolocating the first neighbor's interface is too unreliable to say where the hand-off happens: the link is often numbered from the cloud's own addresses, so the first hop we attribute to the neighbor can lie deeper inside it, and transit backbones geolocate poorly. Round-trip times to the first neighbor, which do not depend on geolocation, are the next check. The clean test is the same address family from the same regions on both tiers, measured side by side, which we have not yet run.

Since 2020

In 2020, Arnold et al. (Cloud Provider Connectivity in the Flat Internet, IMC 2020) counted the networks four clouds connect to, using traceroutes from inside each cloud. The table sets their neighbor sets beside these campaigns, counted the same way: distinct neighbor ASNs over all vantage points, and the organizations behind them (CAIDA AS-to-organization tables, with the cloud's own organization excluded).

Google Cloud's count is below its 2020 figure, Microsoft's is about a third higher and Amazon's is close to three times larger. These are not like-for-like measurements: vantage points, target lists and probing differ between 2020 and 2026, and between campaigns, so the ratios are not growth or decline rates. For Google Cloud in particular, the BGP view below moves far less over the same years (-9%) than the traceroute count does.

Turnover. Counted as organizations through one reference table, the 2020 and 2026 sets overlap only partly:

Google Cloud's September 2026 set retains 41.7% of the 2020 organizations, 41.7% of those in a 2023 Google run, and 41.5% of that run's non-IXP set: three reference sets, collected in different years with different tooling, agree within a point on how much survives.

Most of it happens at exchanges

A link counts as an IXP link when either end is a listed member port of an exchange's peering LAN; everything else is counted as private interconnection (PNI). Each neighbor is placed by exchange name where it meets the cloud on a fabric, and by the city encoded in its router hostname where it does not.

Across the three clouds' IPv4 campaigns, between 53.2% and 57.4% of neighbors are reached only across an exchange; on this measure the three clouds are close. These shares are floors, since a peering-LAN address missing from the membership lists counts as private. Two rows are not comparable to the others: the Google Cloud IPv6 set uses a different address family, target list and routing tier, and the March campaign used an older membership list and a different target list. Microsoft's neighbors are the most often seen in several places: 31.2% of its placed neighbors meet it in more than one place, against about a quarter for the others. Placement leans on exchange membership; private interconnects are placed only when a router hostname names a city, so that side is close to unmeasured. For comparison, the 2023 Google run placed 64.5% of its neighbors and found 25.3% of those in several places.

How much do extra vantage points add? The March campaign probed from three zones in each of 42 regions. Keeping one random zone per region keeps 96.6% of the neighbor ASNs (96.0%–97.2% over 20 draws) but only about 34% of the links, and the share placed in several locations barely moves (20.4%–20.8%, against 20.9% with all zones). Neighbor counts survive single-zone probing nearly intact; link-level counts do not.

What BGP sees

CAIDA's AS relationships give, every month, the neighbors a cloud's ASNs have in public BGP data, independently of any traceroute. Counted the same way for each month (neighbor ASNs of the cloud's own ASNs, links between them excluded):

BGP sees about 376 neighbors for Google Cloud in September 2026; the traceroutes above see 5,365. Public collectors miss most peering links, because a peer does not pass the cloud's routes on to the networks that feed the collectors, so interconnection has to be measured from inside. IBM's count falls from 3,027 to 289; this page does not investigate why.

Exchange route servers add a second, narrower view: CAIDA also harvests multilateral peering from a small panel of route-server looking glasses (panel size per month, with the number shared with 2020's panel in brackets: Sep 2020 9 (9), Jun 2023 0 (0), Mar 2026 11 (7), Aug 2026 3 (0), Sep 2026 3 (0)). The March 2026 panel keeps seven of 2020's nine; between those two months Google Cloud's route-server neighbors go from 503 to 0 and IBM's from 0 to 589. That says Google is no longer visible on the sampled route servers, not that it left them. The June 2023 snapshot lists no looking glasses, and the August and September 2026 panels share none with 2020, so neither can be read against it.

Every number in these three sections is computed from files by scripts/cloud_peering_trend.py (scamper-analysis 97e0e8e): the 2026 campaign peer links, Arnold et al.'s 2020 neighbor sets, the 2023 run's sets, and CAIDA AS-relationship and AS-to-organization files for each month. The 2023 run's placement shares, which need that run's per-link output, are quoted from an earlier analysis of it.

Reading them carefully

• A neighbor appears only if some traceroute from the cloud crossed into it, so each map is roughly a lower bound on the provider's interconnection, seen in the cloud-to-Internet direction, though mapping errors can also add networks that are not true neighbors.
• Locations are where the neighbor's interface geolocates, which can differ from the facility where the interconnection physically happens. Router-interface geolocation is often wrong by hundreds of kilometres or more.
• The campaigns differ in date and in which regions were measured, and the IPv6 target set is one address per prefix rather than per /24, so compare counts across maps with that in mind.