Lumen acquires Alkira for $475M to integrate NaaS into fiber backbone, targeting the east-west traffic bottleneck. Connectivity analysis inside.
Why multi-cloud latency is usually an east-west problem
Most multi-cloud designs focus on north-south traffic: users and edge clients reaching an application front door. The harder bottleneck is east-west traffic—service-to-service calls, database replicas, object storage sync, CI runners talking to artifact stores, and analytics pipelines that hop between clouds. Those paths often leave the provider’s private backbone, traverse the public internet or a chain of overlays, and pick up variable delay at every hop. The result is not only higher average latency but jitter that breaks tight service-level assumptions for chatty microservices and synchronous APIs.
When teams measure “multi-cloud latency,” they are usually measuring that uncontrolled middle path. Fixing it is less about picking a faster instance type and more about controlling how packets move between regions and providers without forcing every workload into one cloud.
What NaaS on a fiber backbone changes
Network-as-a-Service (NaaS) turns connectivity into an API-defined fabric: create a network, attach clouds and sites, apply policy, and tear it down without buying and racking hardware for every link. On its own, NaaS is only as good as the underlay it rides. Integrating NaaS with a large fiber backbone matters because policy and topology can map onto physical routes that are designed for capacity and predictable performance, rather than best-effort internet paths.
For a carrier like Lumen, acquiring Alkira for $475M is a bet that software-defined multi-cloud networking belongs next to the fiber plant—not as a separate overlay bolted on after the fact. Alkira’s NaaS model (cloud-native virtual networks, identity-aware connectivity, multi-cloud attachment) paired with Lumen’s long-haul and metro fiber aims at the same problem from both layers: define the logical network once, carry east-west traffic on infrastructure built for low-latency transport.
- Logical layer: attach VPCs/VNets, data centers, and branches into one policy domain.
- Physical layer: prefer backbone paths over ad-hoc internet peering for cross-cloud and cross-region flows.
- Ops layer: provision and change connectivity with APIs instead of ticket-driven circuit builds for every new path.
How to reason about the east-west bottleneck in practice
Start by classifying traffic, not by drawing a multi-cloud diagram. Separate user-facing ingress from service-to-service and data-plane sync. For each east-west flow, record source cloud/region, destination, protocol (sync vs async), and latency budget. Sync paths—auth, inventory locks, payment orchestration—need bounded RTT and stable loss; async paths can tolerate more delay if queues and retries are designed for it.
Then map each flow to a connectivity model: direct private interconnect, NaaS fabric, or internet VPN. The acquisition thesis only helps if you can put the chatty, budget-sensitive east-west flows onto the integrated fabric and leave bulk, delay-tolerant traffic on cheaper paths. Measure before and after at the flow level (p50/p99 latency and loss), not only at the site or VPN tunnel level, so you know whether the backbone path actually improved the services that care.
What architects should take from the deal
The strategic signal is not “buy more networking products.” It is that multi-cloud performance is a connectivity design problem: control plane (how you define and secure paths) plus data plane (where packets actually travel). Integrating NaaS with fiber is one way to close the gap between those two.
If you are evaluating similar designs, treat multi-cloud as a set of explicit traffic contracts—which workloads may cross clouds, under what latency and security constraints, and over which underlay. Use NaaS to make those contracts enforceable and changeable; use backbone-quality transport for the east-west paths that cannot absorb internet variance. That framing stays useful whether or not this specific combination of carrier and NaaS vendor is in your stack.