Talking about the internet as “the cloud” obscures a critical truth: it’s a physical thing, made of cables and switches and buildings. Some of the most important of those buildings are Internet Exchange Points — IXPs — the meeting halls where the world’s networks plug into each other to exchange traffic.
This post explains what IXPs are, why they exist, how they shape both internet performance and the cost structure of running an online service, and what role they play in IP routing and BGP.
The Problem IXPs Solve
Imagine the internet without IXPs. Every network (autonomous system) wanting to reach every other network has to either:
- Connect directly to every other network ($N²$ links across $N$ networks — utterly impractical).
- Buy transit through one or two upstream providers who carry traffic for them ($O(N)$ links but $O(N \cdot \text{cost})$ traffic fees).
Option 2 is what small networks do. They pay an upstream “transit provider” who has its own connections to most of the world. The transit fee scales with bandwidth — every byte costs money.
Option 1 is what big networks would do, if it were practical. Direct peering means no transit fees, full control, lowest latency. But it doesn’t scale to thousands of networks.
IXPs are the compromise. A single building, often in a major city, where dozens or hundreds of networks have a presence. Each network connects once to the IXP fabric, and from there can peer with any other network present — without each peering arrangement requiring a separate physical link.
A Concrete Example
DE-CIX in Frankfurt is one of the largest IXPs in the world. As of 2026:
- ~1,000 networks are connected.
- Peak traffic exceeds 17 terabits per second.
- Located in just a handful of data centers physically (the routing fabric is logically one, physically distributed).
If you’re a network that wants to exchange traffic with most of Europe efficiently, being at DE-CIX gives you access to almost all of it in one place. You can peer with German ISPs, Polish ISPs, French ISPs, big CDNs, and most major content networks — all by setting up BGP sessions over the IXP’s fabric.
Other major IXPs:
- AMS-IX (Amsterdam) — historically one of the largest
- LINX (London)
- Equinix Internet Exchange (multiple cities, including Ashburn, Singapore, Tokyo)
- CoreSite Open IX (US-based, multiple cities)
- NL-IX, FranceIX, NIX.CZ, MIX-IT (national/regional exchanges)
- JPNAP (Tokyo)
- HKIX (Hong Kong)
Each IXP has its own membership rules, peering policies, and traffic dynamics — but the basic model is the same.
How Peering Works at an IXP
A network joining an IXP does roughly the following:
- Becomes a member (pays a fee, usually annual or monthly).
- Installs hardware at the IXP’s data center (a router with ports into the IXP fabric).
- Negotiates peering agreements with other members. These come in flavors:
- Open peering — happy to peer with anyone.
- Selective peering — peer only with networks that meet certain criteria (size, traffic ratio, geographic spread).
- Restrictive peering — peer only by negotiation.
- Sets up BGP sessions with each peer over the IXP fabric, exchanging route advertisements.
Once peered, traffic between the two networks flows directly across the IXP rather than through transit providers. This typically:
- Reduces costs (no per-byte transit fees).
- Reduces latency (one hop instead of several through upstream networks).
- Reduces failure points (no dependency on a third-party transit provider for that pair of networks).
The Two Kinds of Peering: Public and Private
Within an IXP, peering comes in two main forms:
Public peering (route servers)
Many IXPs run route servers that act as multi-lateral peering hubs. Each member announces its routes to the route server, and the route server distributes those routes to all other members. One BGP session, hundreds of peers. Operationally simple; less control over who you exchange traffic with.
Private peering
Bilateral BGP sessions between specific pairs of networks. More setup overhead but full control over the peering relationship. Used by large networks for high-volume peering with specific partners.
A large network at a major IXP might be on the route server for general traffic and have private peering with a few critical partners (e.g., a big content provider peering privately with major eyeball ISPs).
Why This Matters for Your Application
You don’t directly interact with IXPs unless you operate your own network. But they affect you indirectly:
Latency
Your application’s latency to users depends partly on whether your hosting provider and the user’s ISP are at the same IXP. If they are, traffic flows directly (typically <5ms within a region). If not, traffic transits through other networks, adding hops and latency.
Cost
Hosting providers that peer aggressively at IXPs have lower upstream costs and can offer better prices or include more bandwidth. Major cloud providers (AWS, GCP, Azure, Cloudflare) all have extensive peering presence.
CDN performance
CDN providers measure success partly by their IXP presence. A CDN with 200+ IXP memberships globally can serve your users with lower latency than one with 50. This is why CDN claims about “POPs” or “edge locations” matter — they correlate (loosely) with peering presence.
Routing geography
The path your packets take depends on which IXPs are involved. Sometimes the “shortest” path geographically isn’t available because the relevant networks don’t peer at the same IXP. Your traffic from Munich to Vienna might transit through Frankfurt and Amsterdam if that’s where the relevant networks meet.
IXPs and IP Geolocation
For IP geolocation specifically, IXPs are part of the data the major providers analyze:
- Latency probes from many vantage points triangulate IP locations. The IXP presence determines which probe paths exist.
- Network topology derived from BGP announcements helps locate IPs by inferring which IXPs the announcing AS uses.
- For anycast IPs (see anycast), the IXP through which a user’s traffic reaches a CDN POP determines which physical instance they hit.
You won’t directly look at IXP data when geolocating an IP. But the accuracy of the geolocation depends partly on how well-instrumented the underlying probe network is — and that’s largely about IXP coverage.
The Geography of IXPs
A few interesting patterns:
Concentration
A small number of IXPs handle a disproportionate share of global traffic. Frankfurt, Amsterdam, London, Ashburn, and Tokyo are the “big five” by traffic volume. If you’re operating globally, having a presence at these is high-leverage.
Regional importance
National-level IXPs matter more in regions where international transit is expensive or politically constrained. African and Latin American IXPs have grown significantly in the 2020s as local infrastructure built out.
The carrier-hotel effect
Some buildings — like the One Wilshire building in Los Angeles, or 60 Hudson Street in New York — host so many networks that they function as IXPs even when not officially one. These “meet-me rooms” are physical concentrations of network connectivity.
Cloud provider exchanges
AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect — these are essentially “cloud provider’s private IXP” services where customers connect directly to the cloud at major IXPs (or buildings that function like IXPs).
Tier 1, Tier 2, Tier 3 Networks
A common (informal) classification ties to IXP behavior:
- Tier 1 — global networks that can reach all of the public internet through peering alone, no transit. They peer at every major IXP and have global private peering. Examples: Lumen, NTT, Telia, Telxius, Cogent.
- Tier 2 — regional networks that peer where they can and buy transit where they can’t. Most national ISPs are Tier 2.
- Tier 3 — networks that primarily buy transit and don’t peer significantly. Small ISPs, business networks.
The classification is fuzzy and contested. But it captures something real: large networks operate at IXPs; small networks don’t.
When IXP Awareness Matters
A few specific scenarios where understanding IXPs helps:
Choosing a hosting provider
A provider with peering at the IXPs your users connect through gives better performance than one without. Worth asking about peering policy before committing.
Debugging “the site is slow from country X”
Performance issues from specific regions often trace to IXP peering gaps. The CDN or hosting provider may not peer with the user’s ISP at any IXP, forcing traffic through suboptimal paths.
Operating your own network
Joining the right IXPs is a strategic decision. The math (IXP fees + hardware vs. transit savings) depends on your traffic volume, geographic spread, and the IXPs available in your region.
Investigating an outage
Major BGP routing problems sometimes trace to IXP issues — a malfunctioning route server, a fiber cut at a major exchange, a peering dispute taking down direct connections. Knowing the IXP layer exists helps you ask the right questions.
TL;DR
- IXPs are physical meeting points where networks peer. They make the internet’s “network of networks” architecture practical.
- Major IXPs (Frankfurt, Amsterdam, London, Ashburn, Tokyo) handle huge shares of global traffic.
- Peering at IXPs reduces cost, latency, and dependency on transit providers — but requires being a network with a presence.
- CDN performance correlates with IXP coverage. More peering = lower-latency edge.
- Most application developers benefit indirectly through hosting provider peering decisions, not directly.
- For IP geolocation accuracy, IXP-coverage affects the underlying measurement infrastructure.
You won’t usually need to think about IXPs in your code. But understanding they exist explains a lot: why some CDNs are faster than others, why latency from specific regions varies, and why the geography of the internet has hubs that you’ve never visited but your packets traverse every second.
To see whose AS owns a given IP — which gives you hints about which IXPs it likely peers at — try our ASN directory or IP lookup tool.