Internet Exchanges & Peering

Introduction Picture this: your customer in London tries to load your application hosted on AWS servers in Virginia.

Without internet exchange points, that traffic might bounce through servers in Tokyo, São Paulo, and Frankfurt before arriving-adding hundreds of milliseconds of latency and burning through expensive transit bandwidth.

Internet exchanges solve this problem by creating "traffic intersection points" where networks meet to exchange data directly, much like how microservices communicate through an API gateway rather than routing through external services.

Internet Exchange Points (IXPs) are physical locations where multiple networks interconnect to exchange traffic directly, bypassing traditional internet transit providers.

Think of them as neutral meeting grounds-shared infrastructure where ISPs, content delivery networks, cloud providers, and enterprises plug into a common fabric to pass data between their networks.

This process, called peering, dramatically reduces latency, improves performance, and cuts bandwidth costs for participating networks.

By the end of this lesson, you'll understand how IXPs function as the internet's most efficient traffic exchanges, distinguish between public and private peering models, and recognize why facilities like Amsterdam's AMS-IX and Frankfurt's DE-CIX handle more than 10 terabits per second at peak hours.

You'll gain the knowledge to evaluate peering strategies for your own infrastructure and understand how hyperscalers leverage IXPs to deliver content at scale.

The Architecture of Internet Exchange Points An IXP operates as a distributed layer 2 switching fabric-imagine a massive VLAN that spans an entire data center or multiple facilities.

Networks connect to this fabric through dedicated ports, typically 10Gbps, 100Gbps, or even 400Gbps connections.

Each participant gets one or more physical connections to the IXP's switching infrastructure and receives an IP address from the exchange's shared subnet.

The technical foundation relies on Border Gateway Protocol (BGP), the routing protocol that powers the internet.

When networks connect to an IXP, they establish BGP sessions with other members to advertise their routes and learn about available paths.

A content delivery network might advertise prefixes for thousands of websites, while a regional ISP advertises routes to its customer base.

These BGP sessions happen over the IXP's switching fabric, creating direct paths between networks that would otherwise need to route through third-party transit providers.

AMS-IX in Amsterdam illustrates this architecture at scale.

The exchange operates across multiple data centers with over 900 connected networks exchanging traffic through a distributed switching infrastructure.

Peak traffic regularly exceeds 10 Tbps, with Netflix, Google, Cloudflare, and hundreds of ISPs all connected to the same fabric.

From a systems perspective, it's like running a globally distributed message bus where every participant can subscribe to routes from every other participant.

The physical infrastructure typically includes redundant route servers that simplify BGP configuration for members.

Rather than establishing individual BGP sessions with hundreds of other networks, participants can peer with the route servers, which act as intermediaries-similar to how a service mesh handles communication between microservices without requiring every service to know about every other service.

Public Peering: The Shared Network Fabric Public peering happens on the shared infrastructure of an IXP, where networks connect to a common switching fabric and can establish peering relationships with multiple other networks simultaneously.

The economics mirror shared hosting-you pay a port fee to the IXP (typically $500-$3,000 monthly for a 10Gbps port) and gain access to potentially hundreds or thousands of networks.

DE-CIX Frankfurt, Europe's largest IXP, exemplifies the public peering model.

With over 1,100 connected networks, a single port purchase gives you the ability to peer with major content providers, cloud platforms, and ISPs.

Google maintains multiple 100Gbps connections at DE-CIX, allowing European ISPs to reach YouTube and Google Cloud services with single-digit millisecond latency instead of routing through expensive transatlantic links.

The operational model works through a combination of multilateral and bilateral peering agreements.

Multilateral peering uses the IXP's route servers-you establish one BGP session with the route server and automatically exchange routes with all other members using the same service.

Bilateral peering involves direct BGP sessions between two specific networks for more control over traffic policies and routing decisions.

Here's what the peering options typically look like:

Peering Type	BGP Sessions	Setup Complexity	Traffic Control	Use Case
Multilateral (route servers)	1-2 sessions	Low	Basic filtering	Quick access to many networks
Bilateral	One per peer	Medium to High	Granular control	Major traffic partners
Hybrid	Both approaches	Medium	Flexible	Most common deployment

AWS and Azure maintain presence at most Equinix exchanges, making them strategic locations for enterprises wanting direct connectivity to cloud services.

A typical Equinix customer might maintain bilateral peering with their top 10 traffic sources and use multilateral peering for the long tail of smaller networks.

Private Peering: Dedicated Interconnection Private peering creates dedicated, direct connections between two networks without using shared IXP infrastructure.

Think of it as establishing a private VPC peering connection rather than routing through a public subnet-you get a dedicated circuit with predictable performance and enhanced security.

The technical implementation usually involves cross-connects within a colocation facility.

If Netflix and Comcast both have equipment in the same Digital Realty facility in Dallas, they can order a fiber cross-connect between their cages and establish a direct BGP session.

This creates a private interconnection with dedicated capacity, typically ranging from 10Gbps to multiple 100Gbps links depending on traffic volume.

Major hyperscalers structure their peering strategies around private interconnects for high-volume partners.

Meta's edge network uses extensive private peering with ISPs worldwide.

At CyrusOne's facility in Phoenix, Meta might maintain 4x100Gbps private interconnects with Cox Communications, delivering Instagram and Facebook content directly to Cox subscribers without touching public exchange fabric or third-party transit networks.

The cost structure differs significantly from public peering:

Aspect	Public Peering	Private Peering
Connection Type	Shared fabric port	Dedicated cross-connect
Typical Cost	$500-$3,000/month per port	$500-$2,000/month per cross-connect + port costs both sides
Capacity	Shared with other traffic	Dedicated bandwidth
Setup Time	Days to weeks	Hours to days
Ideal Volume	<1 Gbps per peer

1 Gbps sustained | Microsoft Azure implements a hybrid model at CoreSite facilities in Los Angeles.

They maintain public peering presence at major IXPs for general connectivity while using private interconnects for high-volume partners like AT&T and Verizon.

This architecture mirrors how you'd design a microservices network-public API endpoints for general access, with dedicated service-to-service connections for high-throughput integrations.

Private Peering Interconnection (PNI) becomes cost-effective when two networks exchange enough traffic that the dedicated circuit costs less than the equivalent transit bandwidth.

If you're paying $0.50 per Mbps for transit and consistently exchanging 10 Gbps with a partner, that's $5,000 monthly for transit versus perhaps $1,500 for a dedicated 10G cross-connect.

Major Global Internet Exchanges AMS-IX (Amsterdam Internet Exchange) ranks among the world's largest IXPs, handling peak traffic exceeding 10 Tbps.

Founded in 1994, it pioneered the European internet exchange model and now connects over 900 networks.

Equinix operates multiple Amsterdam facilities housing AMS-IX infrastructure, making it a critical European traffic exchange point.

Netflix, AWS, Google Cloud, Akamai, and Cloudflare all maintain significant presence, serving as the primary content delivery gateway for European internet users.

The distributed architecture spans 13 locations throughout Amsterdam, using dark fiber to create a unified layer 2 fabric. DE-CIX Frankfurt processes over 11 Tbps at peak hours, making it Europe's largest exchange by traffic volume.

With more than 1,100 connected networks spanning 60+ countries, it serves as the primary interconnection point for European, Asian, and Middle Eastern traffic flows.

Interxion (now Digital Realty) and Equinix facilities house the majority of DE-CIX infrastructure.

The exchange operates additional points of presence in New York, Dallas, and Mumbai, extending its reach beyond Germany. LINX (London Internet Exchange) connects over 800 networks and typically peaks around 5 Tbps.

Operating primarily from Telehouse and Equinix facilities in London's Docklands area, LINX pioneered several IXP technical innovations including distributed route servers and advanced monitoring platforms.

The exchange expanded to Manchester, Edinburgh, and Northern Virginia, creating a trans-Atlantic presence.

Regional exchanges show impressive growth patterns too. Equinix IX Ashburn serves as North America's largest public peering point, strategically located near Washington DC where numerous subsea cables land.

QTS's facility in Ashburn hosts significant Equinix IX infrastructure, connecting over 550 networks. Singapore's SGIX handles peak traffic around 800 Gbps, serving as Southeast Asia's primary interconnection point with major presence in Equinix and Global Switch facilities.

Traffic patterns reveal internet usage geography.

DE-CIX Frankfurt peaks during European business hours when video streaming and web traffic concentrate.

Tokyo's JPIX handles massive gaming traffic in Asian evenings.

These exchanges function like regional CDN edge caches-strategically positioned where user demand concentrates.

Peering Economics and Business Drivers The financial calculus behind peering decisions mirrors build-versus-buy analysis in software architecture.

Transit bandwidth costs typically range from $0.20 to $2.00 per Mbps depending on location and volume, while peering incurs fixed port fees regardless of traffic volume.

Once you exchange enough traffic with networks available at an IXP, the port fee becomes cheaper than transit costs.

Consider a mid-sized content provider delivering video streaming: Transit-only approach:

• Average traffic: 50 Gbps
• Transit cost: $0.50/Mbps
• Monthly bandwidth cost: 50,000 Mbps × $0.50 = $25,000 IXP peering approach:
• Two 100Gbps ports at major IXPs: $6,000/month
• Residual transit for uncovered networks: 10 Gbps × $0.50 = $5,000/month
• Total monthly cost: $11,000 The peering approach saves $14,000 monthly while improving latency and reliability.

The breakeven point typically occurs around 20-30 Gbps of traffic volume that can be offloaded to IXP peers.

Latency improvements add significant value beyond cost savings.

Google measures that every 100ms of latency reduces user engagement measurably.

By peering directly with ISPs at local exchanges, content reaches users 20-50ms faster compared to transit routing.

For a gaming platform or financial trading application, this performance gain justifies peering costs independent of bandwidth savings.

Cloud providers structure entire edge architectures around strategic peering.

AWS Direct Connect locations frequently colocate with major IXPs specifically to enable customers to combine private cloud connectivity with public peering.

Switch's Las Vegas campus demonstrates this integration-it hosts Equinix IX fabric alongside AWS Direct Connect and Azure ExpressRoute, allowing customers to build hybrid architectures with optimized cloud and peering connectivity from a single location.

Practical Example: Content Delivery Network Peering Strategy Fastly, a major content delivery network, builds its edge architecture around aggressive peering.

With over 70 global points of presence, they maintain peering relationships with thousands of ISPs and networks.

At Equinix's SV5 facility in Silicon Valley, Fastly operates multiple 100Gbps connections to Equinix IX, peering with regional ISPs, cloud providers, and other CDNs.

Their strategy follows this decision framework:

1. Identify traffic destinations: Analyze where customer content gets delivered
2. Evaluate IXP presence: Determine which exchanges reach those destinations most effectively
3. Calculate economic breakpoint: Peer when traffic exceeds ~1-2 Gbps to available networks
4. Establish public peering: Connect to major IXPs in strategic markets (Amsterdam, Frankfurt, London, Ashburn, Singapore)
5. Layer private peering: Add PNIs with top 20 traffic partners For a specific implementation, consider Fastly's presence at DE-CIX Frankfurt.

They connect with 2×100Gbps ports ($8,000/month) and exchange traffic with over 500 European networks.

Their top partner-Deutsche Telekom-represents 15 Gbps of traffic.

Rather than consuming public peering capacity, they established a 2×10Gbps private interconnect ($2,500/month) at Interxion Frankfurt.

The dedicated capacity ensures predictable performance for millions of Deutsche Telekom subscribers accessing Fastly-served content.

Practical Example: Enterprise Multi-Cloud Networking A global financial services company operates workloads across AWS, Azure, and Google Cloud while maintaining applications in colocation facilities.

They need low-latency connectivity between environments and direct access to financial data feeds.

Their architecture uses CoreSite's CH1 facility in Chicago as the network hub.

The building provides unique value:

• Public peering: CME Group (Chicago Mercantile Exchange) peers at the Chicago IXP housed in CoreSite facilities
• Cloud connectivity: AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect all available
• Private peering: Dedicated interconnects to major ISPs for branch office connectivity The technical implementation creates a routing architecture where:

Financial market data arrives via peering with CME Group at Chicago IXP (sub-millisecond latency) 2.

Private connections to each cloud provider carry workload traffic (consistent 2-3ms latency) 3.

BGP routing policies prefer local peering over transit for general internet connectivity This design reduces their transit bandwidth costs by 60% while improving application performance measurably.

Trading algorithms depending on microsecond timing access market data through direct peering rather than routing through multiple networks.

Cloud synchronization between AWS and Azure occurs through local fabric rather than traversing public internet paths.

Common Misconceptions Misconception: Public peering means anyone can see your traffic Public peering refers to the shared infrastructure model, not traffic visibility.

Peering at an IXP doesn't mean your traffic becomes "public" any more than deploying to a shared colocation facility makes your servers accessible to other tenants.

Each network maintains its own routing policies through BGP, and traffic only flows between networks that explicitly establish peering relationships.

The switching fabric operates at layer 2 with VLAN isolation between peers.

Think of it like using a public cloud provider-you're on shared infrastructure, but your workloads remain isolated through software-defined networking. Misconception: Bigger exchanges are always better Exchange selection should match your traffic patterns, not just total exchange size.

DE-CIX Frankfurt handles massive traffic volume, but if your users concentrate in Southeast Asia, SGIX in Singapore delivers better latency reduction despite smaller overall scale.

Netflix doesn't simply connect to the world's largest IXPs-they strategically place connections where their subscriber base concentrates.

A regional exchange with 100 networks might deliver more value than a massive global exchange if those 100 networks represent your actual traffic destinations.

The right architecture peers where your users are, similar to how you'd distribute application servers geographically based on actual user distribution rather than simply choosing the largest data centers.

Summary & Key Takeaways

• Internet Exchange Points (IXPs) function as distributed layer 2 switching fabrics where networks establish direct BGP peering relationships, dramatically reducing latency and transit costs compared to traditional routing through upstream providers
• Public peering uses shared IXP infrastructure with port fees typically $500-$3,000 monthly per 10Gbps connection, providing cost-effective access to hundreds or thousands of networks through multilateral or bilateral peering arrangements
• Private peering creates dedicated cross-connects between two networks in the same facility, ideal for high-volume partnerships exceeding 1-2 Gbps sustained traffic where dedicated capacity justifies additional costs
• Major IXPs like AMS-IX Amsterdam (10+ Tbps peak), DE-CIX Frankfurt (11+ Tbps), and LINX London (5+ Tbps) serve as critical traffic exchange points with hundreds to over 1,000 connected networks in facilities operated by Equinix, Digital Realty, and other colocation providers
• Peering economics favor IXP connectivity once traffic volume reaches 20-30 Gbps that can be offloaded from transit, with additional benefits from latency reduction improving user experience and application performance
• Strategic peering architecture combines public IXP presence in key markets with private interconnects to major traffic partners, similar to hybrid cloud networking that mixes public and private connectivity based on traffic patterns and performance requirements

Next Steps Study BGP routing fundamentals and traffic engineering techniques to understand how networks control traffic flow across peering relationships.

Examine direct cloud connectivity options including AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect to understand how enterprises combine peering strategies with cloud architectures.

Research colocation facility selection criteria to identify which data centers house the IXP infrastructure and cloud on-ramps most relevant to your connectivity requirements.