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.

How did we do?

Overview Cloud ROUTER

Get in touch