In this article, we will explore different ways to connect to RISE with SAP S/4HANA Cloud, Private Edition deployment on Azure, guiding you through the selection criteria and considerations for data migration. From this point forward, "RISE with SAP S/4HANA Cloud, Private Edition" will be referred to as "RISE with SAP" for brevity.
1. Overview
1.1 Network Connectivity Options - RISE with SAP S/4HANA Cloud, Private Edition
The RISE with SAP offering includes an AI-powered cloud ERP that is managed by SAP. The SAP S/4HANA Cloud, Private Edition serves as the foundation for the "RISE with SAP" offering. SAP Enterprise Cloud Services (ECS) delivers a managed private environment featuring a multi-layered defence-in-depth and zero-trust architecture principles that covers infrastructure and technical managed services.
Microsoft Azure is one of the cloud infrastructure options for the RISE with SAP offering. On Azure, RISE with SAP leverages Microsoft’s global network infrastructure to provide connectivity to SAP applications in a secure and reliable way.
As customers migrate their SAP workloads to RISE with SAP on Azure, they need to consider the various network connectivity options. The connectivity option depends on multiple factors including the following:
- Location where the existing SAP workload to be migrated is (on-premises or Azure)
- Azure landing zone network architecture (hub and spoke, or Virtual WAN)
- Bandwidth requirement during different stages of the SAP migration
Figure 1.1 Typical Hub and Spoke architecture for connecting to RISE with SAP
Many customers deploying RISE with SAP are already using Azure landing zones. A platform landing zone hosts shared services like connectivity and tooling services. An application landing zone hosts the application workloads.
1.2 RISE with SAP Networking Components
The RISE with SAP system is a fully-managed Azure subscription within the SAP tenant and consists of, but is not limited to, the following components:
- Virtual network with subnet, routing and security configuration
- Virtual network gateway for hybrid connectivity
- DNS servers for internal and external DNS resolution
- SAP S/4 HAHA for business applications
- SAP BW/4 HANA - (Optional) data warehouse
- SAP Cloud Connector for secure connectivity to external SAP systems
Figure 1.2 RISE with SAP components
Every standard RISE with SAP environment can be provisioned with an ExpressRoute gateway or a site-to-site VPN gateway to facilitate direct connectivity to on-premises. RISE with SAP customers can also use virtual network (VNet) peering to connect their RISE with SAP VNet to their Azure VNet.
Suggested further reading:
- Connectivity during migration to RISE with SAP
- RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained
- RISE with SAP: Multi-layer Defense in Depth Architecture of SAP S/4HANA Cloud, Private Edition
2. Connecting to RISE with SAP
2.1 Overview
Azure offers a broad range of networking services that provide networking and security capabilities. The following networking connectivity options are available for customers to connect to the RISE with SAP virtual network (VNet):
- ExpressRoute connection
- VPN Connection (Site-to-site and VNet-to-VNet)
- Virtual network peering
- Virtual WAN connection
Figure 2.1 is a general guide to help you select the appropriate way to connect to your RISE with SAP environment.
Figure 2.1 General guide for selecting RISE with SAP connectivity
* Microsoft peering and Azure Peering Service could provide more reliable public connectivity for site-to-site VPN. Some Azure Peering providers may offer SLA.
The method used to connect to the RISE with SAP VNet depends on whether a customer has an existing Azure platform landing zone or not.
Connectivity when there is no existing Platform Landing Zone
When a customer does not yet have an existing landing zone in Azure and need to migrate their SAP systems from on-premises to Azure, they will require direct connectivity from on-premises to the RISE with SAP VNet. ExpressRoute and site-to-site VPN are suitable options for connectivity as described further in these sections:
Connectivity through existing Platform Landing Zone
Many customers looking to migrate their SAP systems to RISE with SAP on Azure already have existing platform landing zones that are connected to their on-premises network. The existing platform landing zones are either virtual network (VNet) hubs or virtual WAN hubs. For VNet hubs, you can connect to the RISE with SAP VNet through VNet peering. For virtual WAN hubs, you can connect to the RISE with SAP VNet through a virtual WAN VNet connection. These are explained further in these sections:
2.2 Network Connectivity for Business Continuity and Disaster Recovery
RISE with SAP systems are designed with high availability in a single region to ensure maximum service uptime across all system components. RISE with SAP also offers Business Continuity and Disaster Recovery (BCDR) solutions that replicate an entire SAP system to another region. With a BCDR solution, customers have continuous access to their services despite the failure of an entire SAP system in a region due catastrophic events like earthquakes or floods.
For disaster recovery (DR) deployments, networking connectivity to RISE with SAP DR region follows the same flowchart in Figure 2.1.
Suggested further reading:
3. ExpressRoute Connection
3.1 ExpressRoute Overview
ExpressRoute is one of the options for connecting customer on-premises network directly to the RISE with SAP virtual network (VNet). This option is typically used when customers do not have existing Azure landing zone and therefore, need to connect their on-premises networks directly to their RISE with SAP VNet using ExpressRoute.
If a customer has an existing Azure landing zone, it is recommended to connect to RISE with SAP using VNet peering or virtual WAN connection as described in sections 5. Virtual Network Peering and 6. Virtual WAN Connection respectively.
ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connection. You can connect with the help of a network service provider that provides layer 2 or layer 3 network connectivity services.
Figure 3.1 ExpressRoute (Provider model) (source)
ExpressRoute Direct connects your on-premises network directly into the Microsoft global network at peering locations strategically distributed around the world. ExpressRoute Direct provides dual 10Gbps or 100Gbps connectivity that supports Active/Active connectivity at scale.
Figure 3.2 ExpressRoute Direct (direct connectivity model) (source)
Read more in this blog about Understanding ExpressRoute private peering to address ExpressRoute resiliency (by Cynthia Treger and David Santiago).
3.2 ExpressRoute from On-premises to RISE with SAP
Every RISE with SAP environment can be provisioned with an ExpressRoute gateway if required. An ExpressRoute circuit in a Microsoft peering location can be connected to the ExpressRoute gateway in the RISE with SAP VNet in order to allow connectivity to the on-premises network.
Use ExpressRoute from on-premises to RISE with SAP when:
- There is no existing Azure platform landing zone
- You can easily setup ExpressRoute to Azure via an ExpressRoute partner
It is common to have customers with on-premises SAP systems that need to be migrated to RISE with SAP before their Azure landing zone is ready. Such customers can connect directly to RISE with SAP using ExpressRoute as shown in Figure 3.3.
Figure 3.3 Connecting on-premises directly to RISE with SAP using an ExpressRoute Provider
Figure 3.3 shows a customer connecting from their on-premises network to the RISE with SAP VNet through an ExpressRoute provider. Here we assume that the customer has an existing on-premises WAN network that can be easily integrated into the Microsoft network through the ExpressRoute provider.
Data Migration
If you are migrating data from your on-premises datacentre to RISE with SAP, ensure that you have adequate bandwidth provisioned through your ExpressRoute provider. You should also ensure you have the right size of ExpressRoute circuit and ExpressRoute gateway to accommodate the bandwidth required for data migration.
Figure 3.4 ExpressRoute Provider: RISE with SAP data migration path and user traffic path
4. VPN Connection
4.1 Overview
IPsec VPN is another option for customers to connect their on-premises network directly to the RISE with SAP virtual network (VNet). This option is typically used when customers do not have existing Azure landing zone and therefore, need to connect their on-premises networks directly to RISE with SAP.
Every RISE with SAP environment can be provisioned with an VPN gateway if required. The gateway enables VPN connections to be established into the RISE with SAP VNet. There are two types of VPN connection - site-to-site and vnet-to-vnet connection. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec.
4.2 Site-to-site VPN from On-premises to RISE with SAP
Site-to-site (S2S) VPN connections can be used for connecting on-premises to your Azure virtual network (VNet). Site-to-site VPN connections offer a reliable, secure and quick way to connect directly to RISE with SAP environment.
Use site-to-site VPN to connect on-premises directly to RISE with SAP when:
- There is no existing Azure landing zone (hub virtual network)
- It is not feasible to deploy ExpressRoute due to time, cost or design constraints
- Site-to-site VPN has sufficient bandwidth for data migration and application traffic
Customers without an existing Azure landing zone can connect their on-premises network directly to RISE with SAP using site-to-site VPN in situations where ExpressRoute is not feasible. Azure site-to-site VPN gateway is a highly available service with an SLA of 99.95%.
Figure 4.1 Site-to-site VPN from On-premises to RISE with SAP
Data Migration
If you are migrating data from your on-premises datacentre to RISE with SAP, ensure that you have sufficient dedicated Internet bandwidth to support the data migration. You should also ensure you have the right size of VPN gateway deployed in the RISE with SAP VNet to support the bandwidth required for data migration.
Figure 4.2 Data paths: Site-to-site VPN from On-premises to RISE with SAP
4.3 VNet-to-vnet Connection to RISE with SAP
A vnet-to-vnet connection allows you to connect a virtual network to another virtual network using IPsec VPN. This allows a customer to connect their VNet directly to the RISE with SAP VNet using IPsec VPN.
The recommended way to connect your VNet to the RISE with SAP VNet is by using virtual network peering. However, VNet-to-vnet VPN connection might be a more suitable way to connect your VNet to the RISE with SAP VNet in order to meet specific requirements. An example is a hub and spoke architecture where the on-premises and spoke networks use the VPN gateway in the customer hub VNet to access the RISE with SAP environment.
Figure 4.3 VNet-to-VNet connectivity to RISE with SAP
In this design shown in Figure 4.3, the VPN gateway acts as the single point of entry into the customer’s network; and can be used by a central network team to restrict the IP address ranges (of the RISE with SAP VNet) that are exposed to the on-premises network and Azure virtual networks.
Read more about RISE with SAP vnet-to-vnet-vpn.
5. Virtual Network Peering
5.1 Overview
Virtual network peering is the most common way to connect directly to the RISE with SAP virtual network (VNet). VNet peering enables you to seamlessly connect two or more Virtual Networks in Azure. The virtual networks appear as one for connectivity purposes. The traffic between virtual machines in peered virtual networks uses the Microsoft backbone infrastructure.
5.2 VNet Peering to RISE with SAP VNet
For RISE with SAP deployments, virtual network peering is the preferred way to establish connectivity from a customer's VNet to the RISE with SAP VNet. For customers that already have a landing zone hub and spoke architecture, the hub VNet should be connected to RISE with SAP VNet through VNet peering.
Figure 5.1 Virtual Network Peering to RISE with SAP (source)
The RISE with SAP VNet is simply a spoke VNet connected to the customer's hub VNet. The customer’s hub VNet could be connected to other Azure spoke VNets, as well as the on-premises network. The following sections show different network patterns for connecting on-premises network to the customer hub when using VNet peering to RISE with SAP.
Read more about virtual network peering with SAP RISE/ECS.
5.3 VNet Peering and Site-to-site VPN to On-premises
In this network pattern, the on-premises network is connected to the customer hub VNet using site-to-site VPN and the hub VNet is connected to the RISE with SAP VNet using VNet peering.
Use this network connectivity pattern when:
- There is an existing Azure landing zone hub
- It is not feasible to deploy ExpressRoute due to time, cost or design constraints
- Site-to-site VPN has sufficient bandwidth for SAP migration
VNet peering to RISE with SAP is configured to allow transit connectivity via the VPN gateway in the hub. This allows traffic from the on-premises network to reach the RISE with SAP network via the hub.
Figure 5.2 VNet peering to RISE with SAP VNet and site-to-site VPN to on-premises
Data Migration
If you are migrating data from your on-premises datacentre to the RISE with SAP environment, ensure that you have sufficient dedicated Internet bandwidth to support the data migration over the site-to-site VPN. You should also ensure you have the right size of VPN gateway deployed in the Azure hub.
User traffic
The on-premises branch locations connect through the customer data centre to reach the Azure hub and RISE with SAP network.
Figure 5.3 Data paths: VNet peering to RISE with SAP and site-to-site VPN to on-premises
5.4 VNet Peering and SD-WAN Connectivity to On-premises
In this network connectivity pattern, the on-premises SD-WAN network is extended into the customer’s hub VNet and the hub VNet is connected to the RISE with SAP VNet using VNet peering.
Use this network connectivity pattern when:
- There is an existing Azure landing zone hub
- SD-WAN is used for the on-premises network connectivity
- There is sufficient bandwidth for SAP data migration over the SD-WAN tunnels to Azure
It is practical for customers with SD-WAN to maximise their SD-WAN investments into the public cloud. Customers with an existing Azure hub VNet can extend their SD-WAN network into Azure, in the same capacity as their on-premises SD-WAN hub.
Figure 5.4 VNet peering to RISE with SAP and SD-WAN connectivity to on-premises
Data Migration
If you are migrating data from your on-premises data centre to the RISE with SAP environment, ensure that you have sufficient Internet bandwidth to support the data migration over the SD-WAN tunnels.
User Traffic
Customer branch locations can establish SD-WAN tunnels directly to the Azure hub and connect to the RISE with SAP network using VNet peering.
Figure 5.5 Data paths: VNet peering to RISE with SAP and SD-WAN connectivity to on-premises
5.5 VNet Peering and ExpressRoute to On-premises
In this network pattern, the on-premises network is connected to the customer hub VNet using ExpressRoute and the hub VNet is connected to the RISE with SAP VNet using VNet peering.
Use this connectivity pattern when:
- There is an existing Azure landing zone hub
- It is feasible to deploy ExpressRoute or there’s an existing ExpressRoute deployed into the landing zone hub
- There is sufficient bandwidth over ExpressRoute for SAP data migration
Many small medium-sized companies use site-to-site VPN and SD-WAN because of the ease of deployment and cost effectiveness as described in section 5.3 and section 5.4. However, some customers already have ExpressRoute deployed into their landing zone hub VNet. The existing ExpressRoute could be used for connectivity from on-premises to RISE with SAP as shown in Figure 5.6.
Figure 5.6 VNet peering to RISE with SAP and ExpressRoute connectivity to on-premises
The VNet peering to RISE with SAP is configured to allow transit connectivity via the ExpressRoute connection in the hub VNet. This allows traffic from the on-premises network to reach the RISE with SAP network via the hub.
Data Migration
If you are migrating data from your on-premises datacentre to the RISE with SAP environment, ensure that you have sufficient bandwidth on the ExpressRoute circuit to support the data migration. You should also ensure the ExpressRoute gateway SKU is sized correctly to accommodate the bandwidth required.
Figure 5.7 Data paths: VNet peering to RISE with SAP and ExpressRoute connectivity to on-premises
6. Virtual WAN Connection
6.1 Overview
The Virtual WAN offers an alternative way to connect to the RISE with SAP virtual network (VNet). Virtual WAN is a hub and spoke architecture that offers integrated connectivity for virtual networks and on-premises networks. It consists of a virtual WAN hub which provides connectivity for virtual networks, site-to-site VPN, ExpressRoute and SD-WAN.
On-premises networks can be integrated into to the virtual WAN by deploying resources such as VPN gateway, ExpressRoute gateway and SD-WAN appliances in the customer’s virtual WAN hub. A virtual network (VNet) spoke connects to a virtual WAN hub using virtual network connection. The RISE with SAP VNet is a spoke VNet in the context of virtual WAN.
For customers that use virtual WAN, it is recommended to connect the RISE with SAP VNet to the virtual WAN hub using a virtual WAN connection. This allows full mesh connectivity from on-premises and existing application landing zones into the RISE with SAP environment.
6.2 Virtual WAN Connection to RISE with SAP and Site-to-site VPN to On-premises
In this network connectivity pattern, the on-premises network connects to the virtual WAN hub using site-to-site VPN.
Use this network connectivity pattern when:
- There is an existing Azure landing zone hub (virtual WAN)
- It is not feasible to deploy ExpressRoute due to time, cost or design constraints
- Site-to-site VPN has sufficient bandwidth for SAP data migration
The virtual WAN VNet connection to the RISE with SAP VNet automatically allows transit connectivity via the VPN gateway in the hub. This allows traffic from the on-premises network to reach the RISE with SAP network via the hub.
Figure 6.1 Virtual WAN connection to RISE with SAP and site-to-site VPN to on-premises
Data Migration
If you are migrating data from your on-premises datacentre to RISE with SAP, ensure that you have sufficient dedicated Internet bandwidth to support the data migration over site-to-site VPN. You should also ensure you have the right size of VPN gateway deployed in the Azure virtual WAN hub.
User traffic
The on-premises branch locations connect through the on-premises data centre to reach the virtual WAN hub and RISE with SAP network.
Figure 6.2 Data paths: Virtual WAN connection to RISE with SAP and site-to-site VPN to on-premises
6.3 Virtual WAN Connection to RISE with SAP and SD-WAN to On-premises
In this network connectivity pattern, the on-premises network connects to the virtual WAN hub using SD-WAN tunnels.
Use this connectivity pattern when:
- There is an existing Azure landing zone virtual WAN hub
- SD-WAN is used for the on-premises network connectivity
- There is sufficient bandwidth for SAP data migration over SD-WAN
It is practical for customers with SD-WAN to maximise their investments into the public cloud. Customers with an existing virtual WAN hub can extend their SD-WAN network into Azure, in the same capacity as their on-premises SD-WAN hub.
Figure 6.3 Virtual WAN connection to RISE with SAP and SD-WAN to on-premises
The VNet connection to the RISE with SAP VNet allows transit connectivity via the SD-WAN appliances in the virtual WAN hub. This allows traffic from the on-premises network to reach the RISE with SAP network via the hub.
Data Migration
If you are migrating data from your on-premises datacentre to the RISE with SAP environment, ensure that you have sufficient dedicated Internet bandwidth to support the data migration over SD-WAN.
User Traffic
Customer branch locations can establish direct SD-WAN tunnels to the Azure hub, and connect to RISE with SAP over the virtual WAN VNet connection.
Figure 6.4 Data paths: Virtual WAN connection to RISE with SAP and SD-WAN to on-premises
6.4 Virtual WAN Connection to RISE with SAP and ExpressRoute to On-premises
Some customers have either already deployed ExpressRoute into their landing zone (virtual WAN hub) or are currently in the process of doing so. In either case, ExpressRoute could be used to allow connectivity from on-premises to RISE with SAP.
Use this connectivity pattern when:
- There is an existing Azure landing zone virtual WAN hub
- It is feasible to deploy ExpressRoute or there’s an existing ExpressRoute deployed into the landing zone hub
- There is sufficient bandwidth over ExpressRoute for data migration
Figure 6.5 Virtual WAN connection to RISE with SAP and ExpressRoute to on-premises
Data Migration
If you are migrating data from your on-premises datacentre to the RISE with SAP environment, ensure that you have adequate bandwidth on the ExpressRoute circuit to support the data migration. You should also ensure the ExpressRoute gateway SKU is sized correctly to accommodate the bandwidth required.
Figure 6.6 Data paths: Virtual WAN connection to RISE with SAP and ExpressRoute to on-premises
Summary
In this article, we explored different ways to connect to the RISE with SAP network in Azure. The connectivity method used depends on whether a customer has an existing Azure platform landing zone or not.
If there is an existing platform landing zone, you should connect to RISE with SAP using VNet peering or virtual WAN VNet connection. Connecting through VNet peering or virtual WAN connection is the recommended approach because it provides a more robust way to connect on-premises and Azure-native workloads to RISE with SAP.
If there is no existing platform landing zone, you can connect directly from on-premises to RISE with SAP using either ExpressRoute or site-to-site VPN.
Microsoft
