Tech Talks: How Network-as-a-Service Simplifies Global Multi-Cloud Connectivity

Executive summary

During a recent Tech Talk, our team met with a network-as-a-service (NaaS) partner that has spent 11 years building a global middle-mile fabric to connect data centers, clouds, and enterprise sites. The session showed how IT leaders can use NaaS to stand up multi-cloud connectivity, accelerate data center migrations, and bridge mixed SD-WAN and firewall environments in minutes instead of months—without buying more hardware.

Key takeaways for IT leaders

• NaaS can replace long lead times for private circuits. The partner regularly stands up virtual connections in minutes, while traditional carriers often take 90–120 days for similar links.
• The platform is built for scale. The partner reported over 2,800 enterprise clients, 100+ data center operators, 360+ service providers, and more than 1,000 enabled data centers on its fabric.
• Four main building blocks cover most use cases: physical ports, a cloud router, a virtual edge for SD-WAN/firewalls, and a specialized NAT gateway.
• Multi-vendor SD-WAN and firewall estates are easier to manage. You can virtualize different vendors on a shared edge platform and manage them through one environment.
• Data center migrations and M&A integration get easier. IPSec tunnels and virtual edges help you move workloads and connect acquired sites without waiting for new physical circuits.

Why NaaS matters right now

As more workloads move into public cloud and colocation, your WAN is now the “glue” between:

• On-prem data centers
• Public and private clouds
• Branch and remote sites
• M&A acquisitions with their own network stacks

Traditional private lines and MPLS still have a place, but long provisioning times and rigid contracts slow down cloud projects and integration work. Network-as-a-service models let teams “rent” middle-mile connectivity and virtual network functions instead of building everything themselves.

Our Tech Talk focused on how one NaaS partner does this at global scale and what that means for IT leaders planning multi-cloud connectivity and future M&A.

Highlights from the Tech Talk

A global middle-mile fabric you can spin up on demand

The partner described their platform as a middle-mile NaaS fabric that sits between enterprise networks and cloud on-ramps. Over 11 years, they’ve:

• Grown to 2,800+ enterprise clients
• Integrated with 100+ data center operators
• Connected to 360+ service providers and hyperscalers
• Enabled 1,000+ data centers worldwide as on-net locations

Once a customer is in an enabled data center and has a physical cross-connect into the fabric, they can spin up virtual connections to clouds, other data centers, or internet exchanges from a self-service portal—usually in under a minute from a provisioning standpoint. The only “slow” step is the physical cross-connect, which is controlled by the data center operator.

Four core building blocks

The partner simplified their offer into four main products (anonymized here):

1. Physical port
   • 1G (being phased out), 10G, 100G, and new 400G options.
   • This is the only physical hand-off into their network; everything else is virtual.
2. Cloud router service
   • Virtualized in their cloud platform.
   • Designed for cloud-to-cloud and data center-to-cloud routing.
   • Supports features like AS path prepending, prefix filtering, and packet filtering.
3. Virtual edge platform
   • Runs third-party network functions (e.g., SD-WAN, firewalls) as virtual network functions.
   • You bring your own license; they provide the compute platform.
   • Each virtual edge instance runs one vendor/platform, so you might spin up multiple instances if you want to host two SD-WAN stacks or firewall vendors side by side.
4. NAT gateway
   • Purpose-built for environments with very high volumes of network address translation.
   • Aimed at customers who would otherwise pay significant NAT charges to cloud providers.

All of this runs at Layer 2 across the fabric, with virtual cross-connects (VXCs) used to stitch services together.

How provisioning works in practice

In the demo, the partner walked through provisioning from their portal:

• Select an enabled data center (for example, one location in Denver and another in Italy).
• Build a private VXC between the two ports, with bandwidth set in software.
• Within about a minute, LOAs appeared for both ends so the customer could order the physical cross-connects from the data center.

The system supports up to 100 VXCs per port, each tagged with its own VLAN, which allows you to send different traffic types (e.g., Azure, AWS, another data center, internet exchange) over the same physical port while keeping them logically separate.

Once the cross-connects are in place and cabled, the services “go green” and traffic can start flowing.

Multi-cloud routing and low latency

Many customers use the cloud router to centralize routing between multiple clouds:

• Place the cloud router in a major hub (e.g., a big colocation market).
• Use direct connections from that router into multiple clouds.
• Take advantage of the fabric’s proximity to hyperscaler on-ramps to keep latency around 1 ms or less between clouds in that region, as described in the session.

New support for IPSec tunnels on the cloud router lets customers connect from sites that aren’t in an enabled data center yet, which is helpful for:

• Data center migrations
• Temporary connectivity while waiting for new ports or circuits
• Moving workloads from smaller locations into the cloud

Handling M&A and multi-vendor networks

We asked a common question for IT leaders: “What about multi-site environments where we’re acquiring companies and refreshing infrastructure?”

The partner’s answer:

• Spin up virtual edges for each SD-WAN or firewall vendor in a regional hub.
• Use the NaaS fabric to connect acquired networks into that hub.
• Migrate traffic over time, without waiting for months-long private circuit builds.
• Turn down virtual instances as you consolidate onto a preferred platform.

Because the service allows no-term or 12-month contracts, teams can align network spend with project timelines instead of long 3- or 5-year commitments.

Who this is a good fit for

From their perspective, sweet spots include:

• Enterprises with data centers or plans to move into hyperscale cloud
• Organizations with mixed SD-WAN/firewall estates (especially after M&A)
• Healthcare and financial services, where predictable private paths into cloud services and partners matter
• AI companies, since many AI workloads need high-bandwidth, low-latency connectivity between GPU clusters, storage, and cloud services

They mentioned that a customer might start at a few hundred dollars per month for a basic port and VXC, and then grow usage over time. On average, customers that turn up a port and VXC see about 30% year-over-year growth in their spend on the fabric, according to the partner.

Solution approach: architecture and integration

From an IT leader’s perspective, this model gives you:

• A programmable middle-mile underlay (ports + VXCs) instead of a fixed circuit mesh.
• Centralized cloud routing, so you’re not stitching every cloud to every data center manually.
• Virtual edges that host the SD-WAN or firewall software you already own.
• A clean separation between underlay and overlay: the NaaS provider handles the transport and virtual compute; you or your vendors manage SD-WAN policies, security rules, and routing.

Key integration points to plan for:

• Identity and access for the NaaS portal and APIs.
• IP addressing, VLAN strategy, and routing design across on-prem, cloud, and virtual edges.
• Logging and monitoring—how you pull telemetry into your existing NMS/SIEM tools.
• Governance around who can spin up VXCs and change bandwidth.

Outcomes and impact (qualitative)

Based on the Tech Talk discussion, IT teams are using this approach to:

• Shorten time-to-connect between data centers and cloud from months to minutes (once cross-connects are in place).
• Simplify multi-cloud networking, centralizing routing rather than managing separate cloud-native constructs everywhere. TRG Datacenters
• De-risk M&A integrations, by giving acquired environments a fast path into a shared fabric while you rationalize platforms.
• Support modern workloads, including AI training/inference and compliance-sensitive apps, over predictable private paths rather than the open internet.

The specific improvements will vary by environment, but the direction is consistent: less waiting on carrier turn-ups, more flexibility to move workloads where the business needs them.

Implementation considerations for IT leaders

If you’re considering NaaS for your own environment, keep an eye on:

• Contract and term strategy
  • Use shorter terms for migration or M&A projects.
  • Reserve longer terms for steady-state hubs where traffic will live for years.
• Licensing alignment
  • Confirm how many virtual edge instances you need for your SD-WAN and firewall vendors.
  • Make sure “bring your own license” terms are clear on both sides.
• Data center planning
  • Map which of your facilities—and which strategic colos—are on-net with the NaaS partner.
  • Plan cross-connect timelines carefully; this is often the longest step.
• Security and segmentation
  • Design VLANs, VRFs, and security zones early so VXCs and virtual edges follow a consistent pattern.
  • Integrate network logging, flow records, and firewall events into your SIEM.
• Change management
  • Train your network team on the portal and APIs.
  • Document standard patterns (e.g., “how we connect a new cloud region,” “how we onboard an acquired site”).

Next steps

If you see your organization in these use cases, here’s a simple path forward:

1. Inventory your current WAN and cloud connectivity, including all private lines and VPNs.
2. Identify one or two pilot scenarios: a data center migration, a new cloud region, or an upcoming acquisition.
3. Engage our team for a NaaS design session, using this partner as one of the options we evaluate.
4. Run a time-boxed pilot with clear success metrics (time-to-connect, latency, project delivery speed).
5. Scale what works, folding NaaS into your broader network and cloud strategy.

If you’d like help assessing whether NaaS makes sense for your environment, schedule a call with our team. We’ll walk through your current topology, project roadmap, and governance requirements, and then recommend the right mix of providers and designs.