Cloud ROUTER use cases

DE-CIX PDM Team Updated by DE-CIX PDM Team

Cloud ROUTER connects cloud environments and on-premises infrastructure through a single virtual Layer 3 routing instance. The scenarios below show the most common ways customers put it to work. Each one follows the same structure — Scenario → How it works → What you configure → How to validate — so you can map your own setup to the closest pattern.

# Use case Scope
1 Cloud-to-Cloud Routing Connect two cloud environments privately
2 Hybrid Cloud Connect on-premises infrastructure with the cloud
3 Multi-Cloud with Routing Policies Connect several clouds with controlled route propagation
4 Migration / Data Transfer Move large data volumes between clouds, temporarily

Resilience and redundancy are built into every Cloud ROUTER by design, so they are not listed as a separate use case. For details, see the Under the hood section in Overview Cloud ROUTER.

Cloud-to-Cloud Routing

Scenario
A customer runs workloads in two different cloud environments — for example, compute and analytics resources in a hyperscaler environment and additional workloads in a sovereign or special-purpose cloud. These resources live within the customer's own cloud tenants (VPC/VNet) and need to exchange data privately and with low latency, without traversing the public internet.

How it works
A single Cloud ROUTER instance hosts two DirectCLOUD connections — one to each cloud environment. Traffic is routed directly between the two clouds at Layer 3, avoiding hairpinning or backhaul through a third location. The result is lower latency and reduced cloud egress costs compared to internet-based connectivity.

What you configure

How to validate
Confirm both BGP sessions are up in the Portal and check that prefixes from each cloud are learned on Cloud ROUTER and advertised to the opposite connection.

Hybrid Cloud

Scenario
A manufacturing company keeps its ERP and core systems in its own data center for compliance and latency reasons, while running analytics and database workloads in its own cloud environment for scalability. The on-premises systems need private, reliable access to those cloud-side workloads — which the customer operates within its own VPC/VNet, not as a third-party SaaS service.

How it works
Cloud ROUTER acts as the central hub. The on-premises site connects through a physical DE-CIX Access port, linked to Cloud ROUTER via VirtualPNI; the cloud side connects via DirectCLOUD. All routing happens centrally on the Cloud ROUTER, so a single instance serves both the private and the cloud leg.

When do I need which connection?

Component Purpose When you need it
DE-CIX Access Physical port into the DE-CIX platform at a data center Whenever you connect on-premises / physical equipment
VirtualPNI Private connection from your Access to Cloud ROUTER To bring your Access into the Cloud ROUTER
DirectCLOUD Cloud on-ramp to a CSP For every cloud environment you connect

Pure multi-cloud setups (use cases 1 and 3) do not require a DE-CIX Access — only hybrid setups with physical on-premises equipment do.

What you configure

How to validate
Verify the VirtualPNI and DirectCLOUD BGP sessions are established, then confirm on-premises prefixes are reachable from the cloud side and the cloud prefixes from on-premises.

Multi-Cloud with Routing Policies

Scenario
A financial services provider connects several cloud environments to a single Cloud ROUTER but, for regulatory and segmentation reasons, must control exactly which routes are exchanged between them. Simply connecting the clouds is not enough — route propagation has to be governed.

How it works
Cloud ROUTER connects all cloud environments centrally and gives you fine-grained control over route propagation. You decide which prefixes are advertised to which connection, summarize routes where needed, and keep environments segmented. The control mechanisms available on every Cloud ROUTER are:

  • Prefix Lists & Policies — accept or reject prefixes per connection (inbound/outbound)
  • Static Routes — explicitly defined routes
  • Route Aggregation — summarize many more-specific prefixes into a single prefix

Mini-example
Cloud A advertises a large set of more-specific prefixes within 10.0.0.0/16, but only the summary route should reach Cloud B. You create an aggregate route for 10.0.0.0/16, auto-generate its prefix list, and apply an export policy on the Cloud B connection that accepts the aggregate and rejects the more-specifics. Cloud B then receives a single, clean prefix while the full detail stays available inside the Cloud ROUTER.

What you configure

How to validate
Compare advertised vs. learned routes per connection in the Portal and confirm each connection only receives its intended prefixes.

Migration / Data Transfer

Scenario
A company needs a private, high-bandwidth path between two cloud environments for a limited time. Typical triggers are a one-off migration or consolidation — for example moving storage and workload data from one cloud environment to another after a merger — or a temporary capacity burst, such as a seasonal compute or analytics peak. In both cases the throughput requirement is high but time-boxed: lots of bandwidth for a defined window, after which the connection can be removed.

How it works
A Cloud ROUTER with two DirectCLOUD connections provides a private, high-bandwidth path between the source and target cloud environments. Because Cloud ROUTER is provisioned in minutes and supports a 1-month contract term, you can spin up the capacity for the window you need and decommission it afterwards — no hardware investment for a temporary requirement.

What you configure

  • One Cloud ROUTER instance on a short (1-month) contract term — see Create a Cloud ROUTER
  • Two DirectCLOUD configurations — source and target cloud environments
  • Bandwidth sized for the window; downgrade or delete the service once it is no longer needed

How to validate
Confirm both BGP sessions are up and monitor throughput during the transfer in the Portal.

Going further: controlling routes at scale

For a detailed, real-world walkthrough of using route aggregation to stay within a hyperscaler's maximum-prefix limit — a common requirement in multi-cloud setups like the one above — see the Example: Reducing AWS Prefix Count with Route Aggregation section in Static Routes & Route Aggregation.

Overview Cloud ROUTER Overview DirectCLOUD Prefix Lists & Policies in Cloud ROUTER Static Routes & Route Aggregation

How did we do?

Overview Cloud ROUTER

Get in touch