10X Backbone: How Meta Is Scaling Backbone Connectivity for AI
Meta scaled its Express Backbone network 10x using pre-built metro ring infrastructure, a combination of IP platform scale-up and scale-out techniques, and ZR optical integration that cuts power per terabit by 80–90%.
Everyone talks about GPU clusters as the bottleneck in AI infrastructure. The WAN fabric that connects those clusters to each other and to the world has its own scaling wall — and it runs on a different timeline than compute procurement.
Source
10X Backbone: How Meta Is Scaling Backbone Connectivity for AI
By: Meta
Published: Oct 16 2025
Type: Engineering article
Saved because this is a concrete account of backbone network architecture decisions made at the scale of actual AI cluster deployment — fiber pre-provisioning, IP platform choices, and optical integration — with real power efficiency numbers attached.
Three Techniques Behind a 10x Backbone
Meta’s backbone network is not a single system. It is two networks with different design philosophies serving different roles. Classic Backbone (CBB) provides global reach — from data centers to the points of presence (POPs) where Meta connects with external carriers. CBB uses traditional IP/MPLS-TE, is designed for flexibility, and can grow or shrink to cover new geographies. Express Backbone (EBB) is built for DC-to-DC interconnection specifically. It runs Open/R as its routing protocol, an in-house traffic engineering stack with on-box agents and a centralized controller, and has less flexibility in terms of minimum deployment size. In return, it is optimized for scalable, high-throughput interconnection between Meta’s data centers.
Both networks are growing, but EBB is where the pressure is most acute. AI training clusters are large, co-located, and communicate intensively across sites at bandwidth that CBB was not designed to absorb efficiently. EBB first carried production traffic in 2015. What Meta now calls 10X Backbone is the evolution of EBB under the demands that AI infrastructure has imposed — not a redesign, but a set of coordinated scaling techniques applied simultaneously.
The first technique is pre-built metro ring infrastructure. Connecting a new data center to the backbone has historically meant commissioning new long-haul fiber — physical cable installation over potentially hundreds of miles, measured in months. That timeline was compatible with the old pace of data center construction. With AI clusters being stood up quickly, the fiber procurement timeline has become a deployment bottleneck. Meta’s answer is to decouple the two: pre-build two rings of fiber in each metro area, connect long-haul fibers to those rings in advance, and build two POPs to handle connectivity toward remote sites. When a new data center is ready, it connects to the existing ring rather than initiating a new long-haul fiber project. The timeline dependency is broken. The capital outlay moves forward in time — spend on the ring before knowing exactly which data centers will attach to it — but the operational benefit is that the network is ready when the compute is ready, not months after.
The second technique is IP platform scaling, and it has two complementary flavors: scale-up and scale-out. Scaling up is primarily vendor-driven. It means upgrading to routers and line cards with higher port density and higher per-port throughput as each hardware generation ships. The approach is straightforward — consume capacity improvements as the industry delivers them — but it creates a hard dependency on vendor product roadmaps. You can only scale as fast as the next router generation arrives. Scaling out operates differently and is more under Meta’s control. Rather than waiting for a single platform to grow larger, scaling out means adding more platforms and distributing traffic across them. In EBB’s history this has taken different forms, and both scale-up and scale-out are active in the 10X effort. They are not substitutes for each other; they address different bottlenecks. Scale-up increases capacity per device. Scale-out increases the number of paths through the topology. Applied together, they give Meta both the raw throughput and the topological redundancy that a 10x traffic growth target requires.
The third technique is IP and optical integration using ZR transceivers. Traditional long-haul optical networking separates the IP layer from the optical layer: a router handles packet forwarding, and a standalone coherent transponder handles the optical transmission. This separation is modular and operationally familiar, but the standalone transponders consume significant power and take up dedicated shelf space. ZR technology — specifically the ZR+ extended-reach variant — allows coherent optical transceivers to be plugged directly into routers, eliminating the transponder entirely. The router draws more power per port as a result. The net effect, measured in aggregate across the system, is 80–90% less power per terabit, once the transponder savings are included. That number deserves some context.
Power is not just an operating cost at Meta’s scale — it is a physical constraint on how many racks of infrastructure fit in a given building, how many buildings the local grid can support, and how quickly new capacity can be brought online. A 10x growth in backbone traffic capacity needs to fit inside a power budget that the physical data center infrastructure can actually provide. An 80–90% reduction in watts per terabit means the traffic scaling does not demand a commensurate power scaling. Without that efficiency improvement, the backbone becomes a power bottleneck on AI cluster deployment regardless of how much fiber or how many routing platforms are available.
The three techniques are designed to address three separate limiting factors. Metro rings solve time-to-connectivity — they separate the question of whether fiber exists from the question of whether a new data center can connect. IP platform scaling solves raw capacity — it provides the throughput and path diversity that 10x traffic growth requires. ZR integration solves power efficiency — it ensures the capacity growth does not translate directly into a power growth that the physical infrastructure cannot absorb.
One observation about EBB’s architecture worth noting: the decision to run Open/R and an in-house TE stack rather than standard vendor-controlled routing software is what makes tight co-design between IP and optical layers possible. A network running on a fully vendor-managed control plane would have limited ability to integrate ZR-plugged routers in ways that optimize for Meta’s specific traffic patterns and physical topology. Owning the control plane is the prerequisite for being able to optimize the physical layer.
My take
The pre-built metro ring strategy is the most instructive part of this for anyone thinking about infrastructure planning. It is a bet that the cost of stranded fiber capacity — rings pre-built in advance of confirmed tenants — is lower than the cost of delayed connectivity when new data centers are ready to come online. That is not obviously true in all cases, but at Meta’s deployment pace, the math almost certainly favors pre-provision. It is the same logic as keeping buffer stock in a manufacturing line: waste a little capacity to prevent blocking the entire pipeline.
Where this is useful
- When designing DC-interconnect architecture that needs to scale ahead of confirmed traffic demand
- When evaluating power efficiency at the WAN layer as a constraint on cluster deployment density
- When assessing tradeoffs between vendor-managed and in-house routing control planes
- When NOT applicable: single-site deployments or small clusters where the WAN is not a constraint on training performance or deployment timeline
Apply this: When planning network capacity for AI infrastructure, treat time-to-provision, throughput, and power efficiency as three separate bottlenecks requiring separate solutions — solving one does not address the others.
What I want to remember
Remember: Backbone WAN is a first-class infrastructure constraint for AI at scale — fiber availability, routing platform capacity, and power per bit each have their own scaling wall and their own solution.