Summary

  • On 11 November 2026 the AMS-IX Amsterdam page carried a box headed "Amsterdam in numbers" reporting 915 connected networks and a peak of 15.822 Tb/s, with no stated measurement period, averaging window or platform scope.
  • The same page presents eight separately named connectivity products, from Internet Peering to IX-as-a-Service. A single peak spanning them cannot be a measurement of the shared switch, and the page does not say which product it counts.

Read the front page of the Amsterdam internet exchange and you meet two numbers. The box is headed "Amsterdam in numbers". One figure is 915, labelled connected networks. The other is 15.822, labelled Peak (Tb/s). They sit above a menu of services, and the menu is longer than most people assume.

Start with what the label actually says. "Peak" is an adjective describing a maximum. "Tb/s" is a unit. Between them there is no period, no averaging window, no sampling interval, and no statement of which platforms the figure covers. That is not an accusation of dodgy arithmetic. It is a statement about what a reader standing in front of the page can and cannot conclude, and the honest answer is: less than the number's prominence suggests.

The page as read on 11 November 2026 presents eight differently named service lines alongside those figures: Internet Peering, Mobile Peering, Private Interconnect, Closed User Group, Data Centre Interconnect, EasyAccess, Remote Peering and IX-as-a-Service. Only the first is the shared switch that most people picture when they say "the exchange".

The other seven are not decoration. On a shared switch, every member port carries traffic to whichever peers accept it, and a peak is a sum across sampled counters on those ports. Private Interconnect takes a bilateral session off that shared port and puts it on dedicated capacity between two named parties. Data Centre Interconnect carries traffic between sites on the operator's estate, which is a different product with a different customer. Remote Peering attaches a network sitting in another city or country to the Amsterdam fabric, so its traffic appears in Amsterdam's counters without a router in Amsterdam.

Closed User Group sells a partitioned segment rather than general peering. IX-as-a-Service sells the platform itself to somebody else's exchange, which may run on the operator's software and speak to its fabric under a different brand entirely.

Now add them up the way a headline does. A single peak figure spanning those eight products is a total across customers with different contracts, different margins, and very different implications for how much of the internet still aggregates in one building. It can rise for reasons that have nothing to do with the shared fabric growing. It can rise precisely because remote peering and dedicated capacity grew faster.

The sceptical reading starts from a pattern operators know well: the largest networks have long preferred their own dedicated links wherever they can get them, and every one of those links removes a session from the multilateral pool. Under that reading, the headline peak becomes a lagging indicator of brand reach rather than a leading indicator of aggregation. I cannot prove that share is falling from what the page shows. Nobody can, which is the point.

What the two dated points do say is narrower. BTW's own briefing of 18 October 2026 recorded this headline family at 903 connected networks and asked what unit the figure covers. Twenty-four days later the same counter reads 915. Twelve more networks is a fact about two readings of a published number. It is not a growth rate, and it should not be drawn as a curve: a network count moves when a member joins, when two members merge into one autonomous system, when a reseller consolidates its downstreams, or when the operator changes how it counts. The directory record for this exchange is similarly a description of a role, not a measurement of load.

AMS-IX maintains a dedicated statistics surface at AMS-IX Statistics, which is where a per-product split would live if one were published. The figures quoted in this article are the ones the operator displays on its Amsterdam page.

Three things would settle the question, and none of them is a bigger headline. A per-product volume disclosure, even a coarse one, would separate shared-fabric traffic from dedicated and remote traffic and turn one number into three. A dated peak series with a stated scope and averaging rule would let an analyst see whether the aggregate is climbing because the fabric is growing or because the product mix is shifting. Port counts and port speeds would do the same job from the physical side: lit capacity at known port sizes tells you how much of the estate is actually carrying traffic, and it cannot be inflated by attaching a remote peer.

Here is why a buyer should care rather than merely tut. If you are choosing where to interconnect, the headline tells you the brand is large and the estate is busy. It does not tell you how much multilateral reach you are buying, how many of those 915 networks will actually accept your routes, or whether the growth you are paying for sits in a product you are not buying. If you are siting equipment, the question is whether physical presence still buys reach or whether a remote attachment buys the same routes more cheaply.

If you are writing an investment memo, a composite figure that nobody can decompose is a benchmark you inherit and cannot audit.

A number that sits above the fold on a homepage is a marketing decision before it is a measurement. That is not a scandal; an exchange is entitled to lead with its strongest asset. It becomes a problem when the rest of the market stops noticing that the asset being marketed is a portfolio.

The 15.822 Tb/s peak is real, published and quotable. Quote it as what it is: one composite figure across eight products, from an operator that has not said which one it counts. The menu underneath is the more honest document.