Cloud network integration

Without connectivity to the local data centre, a cloud strategy cannot be implemented.

by Urs Haug


2 May 2022

No matter which cloud strategy is to be implemented, it makes sense to connect the local data centre with the cloud, as the path to the cloud corresponds to a step-by-step procedure. There are always services in the local data centre that require access from the cloud. For example, directory and identity services, or access to databases and DDI integration.

Cloud connection

However, the way in which the connection is realised depends on the required quality. Depending on the use case, the following questions must be asked and answered in advance.


Required quality


  • What quality (availability, loss, delay jitter) of connection is required for my use case?
  • Do I need a quality guarantee from the service provider?

Connection variant

  • Can the required quality be achieved using IPSec VPN, or is a direct connection (e.g. Express Route) required?
  • Can I integrate the DC connection into an existing SD-WAN?

It should be noted that in the cloud for IaaS and PaaS, virtual networks are primarily created with private IP addresses (RFC 1918), which are then routed via the DC cloud connection. SaaS services, which include the cloud portal, are addressed with public IP addresses and are accessed via the internet access that is also used for surfing the internet.

These graphics show the possibilities of connecting a public cloud to the local DC.

Connection to the public cloud via IPsec VPN
Connection of the Public Cloud via IPsec VPN over the Internet

This type of connection is inexpensive and relatively quick to realise. However, this type of connection is not suitable for all quality requirements.

Direct connection
Direct connection

For high quality requirements, a direct connection of the cloud to the local data centre is suitable. Such a connection is made via a service provider who offers these services in the respective country. Here, too, the connection is usually encrypted.

Another variant is SD-WAN, which is usually accompanied by the connection of the users. SD-WAN represents a platform on which various IPsec VPNs with different topologies and transport networks can be realised and centrally managed. Both the IPsec VPN variant and the direct connection can be realised with SD-WAN or, in the case of the direct connection, integrated as a transport.


The following table shows which connection variants are suitable for the different use cases.


Internet IPsec VPN


This type of connection is sufficient for basic needs, unless a guarantee is required from the service provider. It is recommended to realise the connection by means of a TIER 2 internet provider.

Direct connection

Suitable for all use cases and quality requirements. Since this variant also incurs higher costs and is more complex to implement, it should not be considered for use cases that are of a temporary nature.


If SD-WAN already exists for the connection of the users, it is advisable to use SD-WAN for the DC connection as well, since, as already mentioned, the direct connection is usually encrypted as well.

Cloud Networking

In addition to the connection to the local DC, the question arises as to what functional requirements are placed on cloud networking. On the one hand, this involves network components such as routers, VPN gateways and load balancers, as well as the question of whether a fabric technology used locally in the DC should be extended into the cloud.


Network components


  • What are my functional requirements for the cloud network components?
  • Do the cloud native network components meet these requirements or do I need to deploy virtual appliances of network components in the cloud?

DC Fabric Integration

  • Should the fabric technology used in the local DC be extended to the cloud? (e.g. Cisco ACI or VMware NSX)

The question regarding network components in the cloud can be answered as follows from a functional point of view.




Wherever possible, network components from the cloud provider, so-called cloud-native components, should be used. These are usually sufficient for the standard Layer 2 and Layer 3 functions.

Virtual appliances

If the cloud-native components do not support certain functions, virtual appliances are usually used. This is especially the case for load balancers, VPN gateways and transitions from legacy networking to SDN networking (ACI or NSX).

Whether a DC fabric should be extended into the cloud depends on which cloud strategy is being pursued. If the cloud is operated in hybrid mode for a longer period of time and the network segmentation in the cloud is to be managed with the same tools, then it makes sense to extend the local DC fabric into the cloud. However, if the cloud is used temporarily, such an extension makes little sense. In order to extend the local DC fabric into the cloud, "Cisco Cloud ACI" must be implemented and activated on the cloud side in the case of Cisco ACI and "VMware NSX Cloud" in the case of VMware NSX. These are available in the corresponding cloud stores.

Our consultants have built up and developed the necessary know-how in countless cloud projects from conceptual design to implementation. We support our customers to successfully implement their cloud projects holistically, i.e. beyond the network level.