(Jana Subramanian serves as the APJ Principal Cybersecurity Advisor for Cloud Security. He is a Fellow of Information Privacy (FIP), awarded by the International Association of Privacy Professionals (IAPP). In this role, Jana supports strategic customer engagements on cybersecurity, data privacy, multi-cloud security integration architecture, contractual assurance, audit, and compliance.)
Introduction
When organizations adopt RISE with SAP S/4HANA Cloud, private edition (PCE), one of the key considerations is how to establish secure connections to the RISE with SAP - PCE landscape hosted on a Hyperscale environment. While it is the customer's responsibility to ensure secure connectivity to the PCE landscape, SAP supports a variety of network connectivity options from customer on-premises network to RISE with SAP S/4HANA Cloud, private edition. This is especially important for industries that are subject to regulations, as they often require secure connectivity options that do not involve connections via the Internet. This blog primarily focuses on the different connectivity options available for secure network connections between a customer's environment and RISE with SAP S/4HANA Cloud private edition. The options explained in this blog is applicable only for SAP S/4HANA cloud, Private Edition running on Hyperscale environment and are not an exhaustive scenarios. For a comprehensive connectivity requirements, it would be best to reach out to SAP Cloud Architect Advisors. Only general information and additional references are provided for simplified understanding.
Secure Cloud Connectivity
In general, there are essentially four different ways to connect to SAP S/4HANA Cloud, Private Edition. Customer can opt the connection based on their specific requirements on security, compliance, bandwidth, cost among other considerations. The connectivity architecture patterns between AWS, Azure and Google Cloud are almost similar with subtle differences.
In the following section, we will examine at a high-level information on each of the connectivity setup.
SITE TO SITE IPSEC VPN
In this setup, customer must have a compatible customer gateway on the on-premises end and SAP ECS will setup VPC or VNET for each customer landscape and then create Virtual Private Gateway or VPN Gateway. Customer end IPSEC configuration will be done by customer and SAP ECS will make relevant configuration such as encryption parameters and authentication details at Virtual Private gateway to establish a secure IPSEC tunnel. Either static route and BGP Routing can be configured both ends depending customer requirements and the connection will be tested.
SAP S/4HANA Cloud Private Edition supports redundant IPSEC connection to support resiliency requirements such as active-active setup with multiple tunnel endpoints on Virtual Private Gateway having unique public IP Address setting up connection on-premises customer gateway. Another supported configuration would be having two customer gateway on-premises and setting up two separate tunnels to virtual private gateway. This protects against any single point of failure at the on-premises customer gateway. Following are some of the examples of resilient IPSEC configuration. For detailed supported configuration, SAP Cloud Architect Advisors (CAA) may help to design based on customer requirement.
One consideration that must be kept in mind is that IPSEC bandwidth may be limited. Each of the Hyperscale environment support various bandwidth for IPSEC Tunnel. For example in case of AWS, each IPSEC tunnel support 1.25Gbps and GCP supports 3 Gbps per tunnel (ingress & egress). While the traffic is encrypted and is easy to configure, it still traverses via Internet. For detailed design and configuration of IPSEC VPN for AWS, Azure and GCP, you can refer to the link below:
Dedicated Private Connection
While many customers have confidence in the stability of internet services and use IPSEC VPN to connect their on-premises to RISE with SAP PCE, some regulated customers may prefer a dedicated private connection to the Hyperscaler environment for added security and compliance when running their business processes and applications.
Amazon Web Services – AWS Direct Connect
The AWS Direct Connect allows customers to establish a dedicated network connection from their on-premises data centres to AWS. This dedicated connection bypasses the public internet and provides a more reliable, lower-latency communication between the customer's on-premises infrastructure and AWS. A dedicated connection is a 1G or 10G physical Ethernet port exclusively assigned to one customer. In case of hosted connection, which can be ordered by customers from AWS Direct Connect Partners and supported bandwidth for hosted connection can start from 50M to 10G. Since SAP manages to AWS environment, SAP ECS will provide Letter of Authorization to customer.
As part of this configuration, SAP will provide the Direct Connect (DX) name, location, port speed, and interconnect partner on the AWS portal. This is an "AWS DX port" operating at a specific speed that belongs to an AWS Account ID managed by SAP. You can refer to a blog “Private Connectivity to SAP HANA Enterprise Cloud via AWS Direct Connect” and AWS documentation on AWS Direct Connect. An high level architecture view of customer network connecting to RISE with SAP landscape via AWS Direct Connect is as follows:
Azure - ExpressRoute
Azure ExpressRoute is a service provided by Microsoft Azure that enables customers to create private connections between their on-premises infrastructure and Azure data centres. It bypasses the public internet and provides a more reliable, secure, and lower-latency communication between the customer's on-premises infrastructure and Azure.
RISE with SAP S/4HANA cloud, Private Edition supports Expressroute, ExpressRoute Direct and sharing of customer’s own express route. Azure ExpressRoute allows customers to connect to Azure through a partner's data centre, such as an Equinix or colocation facility, using a dedicated and secure connection. This provides a layer of separation from the public internet and helps customers meet their compliance requirements.
ExpressRoute Direct, is a direct connection between the customer's on-premises network and Microsoft's global network. This direct connection provides increased security and lower latency as compared to ExpressRoute. Additionally, ExpressRoute Direct provides dual 100 Gbps or 10 Gbps connectivity, which supports Active/Active connectivity at scale. With ExpressRoute through partner Data centre, incremental bandwidth in the range of 100 Mbit/s, 200 Mbit/s, 500 Mbit/s, 1 Gbps, 2 Gbit/s, 5 Gbit/s, 10 Gbit/s can be supported.
The above diagram is shown with ExpressRoute failover to IPSEC VPN. The primary data connection is always through the ExpressRoute circuit. If it fails, data will be routed through the Site-to-Site VPN. To prevent “asymmetrical” routing, the customer's local network should prioritize ExpressRoute over Site-to-Site VPN by assigning higher preference to routes received via ExpressRoute. For enhanced security requirement for regulated industries, SAP ECS supports running an encrypted VPN tunnels over an ExpressRoute connection.
You can refer to Azure documentation relating to Extend an on-premises network using ExpressRoute to know more about workflow and architecture components.
Google Cloud Interconnect
Similar to AWS Direct Connect and Azure ExpressRoute, Google supports Cloud Interconnect. This is a service provided by Google Cloud Platform (GCP) that allows customers to connect their on-premises infrastructure to GCP via a dedicated and secure network connection. It enables customers to transfer data between their on-premises systems and GCP services with reduced latency and improved security compared to public internet connections. There are two types of interconnects are supported – partner interconnect and dedicated interconnect. For high bandwidth requirements (10Gb/s and above), dedicated interconnect is a good fit. If lower capacity is sufficient or a direct link to Google Point of Presence (PoP) is not feasible, partner interconnect is the better option.
For detailed architecture of Google Cloud Interconnect, you can refer to this link.
VPC/VNET Peering
Many customers using RISE with SAP S/4HANA Cloud, Private Edition have an existing account with hyperscale providers, where they've set up their own VPC/VNET and run their own vital business processes and applications. As a part of integration, a secure connection is needed between the customer's own VPC/VNET under their account/subscription and the VPC/VNET managed by SAP ECS in RISE with SAP.
In case of Azure, Virtual network peering allows customers to easily connect their Azure virtual network to the RISE with SAP - PCE virtual network. Communication between virtual machines is facilitated through Microsoft's backbone infrastructure, with traffic only passing through Microsoft's private network. Further Network Security Group can be used to control access between the VNETs. This results in a fast and efficient connection between resources in different virtual networks. Azure offers two peering options for RISE with SAP – PCE customers: Virtual network peering within the same region, and global virtual network peering for connections across Azure regions.
A simple architecture on Azure is as follows:
The same concept applies to Google Cloud platform too. This connection can be achieved through VPC Peering as shown the diagram below:
For details of the architecture and limitations, please refer to the below link:
Advantages of VPC/VNET Peering
There are many advantages of this connection due to higher performance as it uses Cloud Services Provider Backbone Network, Low Latency, Traffic Isolation. However, VPC can only communicate with peered VPC and transitive indirectly connected VPC is not supported. Also customers must ensure that there is no overlapping IP Addresses. To overcome limitation on non-transit VPC peering, customer can consider using Transit Gateway and this should be managed by customer. RISE with SAP PCE does not allow deployment of Transit Gateway at the SAP managed landscape. In case of Azure, customer can consider using “Gateway Transit”
RISE with SAP PCE – PCE Access via Internet
If customer wants to access SAP S/4HANA in PCE via Internet, this can be allowed via traffic traversing via Web Application Firewall (WAF). For inbound Internet connection, only HTTPS/TLS1.2 is allowed. In case of Azure deployments, the Azure Application Gateway (AAG) is used and this as a web traffic load balancer and has the capabilities of a Layer 7 load balancer as well as a Web Application Firewall (WAF). Similarly, AWS WAF and Google Cloud supported Cloud Armor is used for Internet inbound traffic for AWS and GCP environments. This provides screening of L4-L7 traffic, protecting web application from common exploits and vulnerabilities based on OWASP 3.0
Conclusion
This blog offers an overview of the different connectivity options available to customers. To ensure secure connectivity to RISE with SAP S/4HANA Cloud, Private Edition, a thorough understanding of the customer's existing on-premises network, performance, latency, bandwidth, cost, and security requirements is necessary. While the responsibility for secure connectivity from on-premises to RISE with SAP PCE lies with the customer, SAP Cloud Architect Advisors (CAA) should be consulted to address design considerations.
Disclaimer
© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.
Introduction
When organizations adopt RISE with SAP S/4HANA Cloud, private edition (PCE), one of the key considerations is how to establish secure connections to the RISE with SAP - PCE landscape hosted on a Hyperscale environment. While it is the customer's responsibility to ensure secure connectivity to the PCE landscape, SAP supports a variety of network connectivity options from customer on-premises network to RISE with SAP S/4HANA Cloud, private edition. This is especially important for industries that are subject to regulations, as they often require secure connectivity options that do not involve connections via the Internet. This blog primarily focuses on the different connectivity options available for secure network connections between a customer's environment and RISE with SAP S/4HANA Cloud private edition. The options explained in this blog is applicable only for SAP S/4HANA cloud, Private Edition running on Hyperscale environment and are not an exhaustive scenarios. For a comprehensive connectivity requirements, it would be best to reach out to SAP Cloud Architect Advisors. Only general information and additional references are provided for simplified understanding.
Secure Cloud Connectivity
In general, there are essentially four different ways to connect to SAP S/4HANA Cloud, Private Edition. Customer can opt the connection based on their specific requirements on security, compliance, bandwidth, cost among other considerations. The connectivity architecture patterns between AWS, Azure and Google Cloud are almost similar with subtle differences.
- IPSEC VPN
- Dedicated Private Connection
- VPC or VNET Peering
- Internet Inbound
Figure 1: Secure Cloud Connectivity Types to SAP S/4HANA Cloud - PCE
In the following section, we will examine at a high-level information on each of the connectivity setup.
SITE TO SITE IPSEC VPN
In this setup, customer must have a compatible customer gateway on the on-premises end and SAP ECS will setup VPC or VNET for each customer landscape and then create Virtual Private Gateway or VPN Gateway. Customer end IPSEC configuration will be done by customer and SAP ECS will make relevant configuration such as encryption parameters and authentication details at Virtual Private gateway to establish a secure IPSEC tunnel. Either static route and BGP Routing can be configured both ends depending customer requirements and the connection will be tested.
Figure 2: IPSEC VPN Architecture Patterns on AWS
SAP S/4HANA Cloud Private Edition supports redundant IPSEC connection to support resiliency requirements such as active-active setup with multiple tunnel endpoints on Virtual Private Gateway having unique public IP Address setting up connection on-premises customer gateway. Another supported configuration would be having two customer gateway on-premises and setting up two separate tunnels to virtual private gateway. This protects against any single point of failure at the on-premises customer gateway. Following are some of the examples of resilient IPSEC configuration. For detailed supported configuration, SAP Cloud Architect Advisors (CAA) may help to design based on customer requirement.
Figure 3: IPSEC VPN Architecture Pattern on Azure
One consideration that must be kept in mind is that IPSEC bandwidth may be limited. Each of the Hyperscale environment support various bandwidth for IPSEC Tunnel. For example in case of AWS, each IPSEC tunnel support 1.25Gbps and GCP supports 3 Gbps per tunnel (ingress & egress). While the traffic is encrypted and is easy to configure, it still traverses via Internet. For detailed design and configuration of IPSEC VPN for AWS, Azure and GCP, you can refer to the link below:
- Setting up Site to Site VPN Architectures (AWS VPN)
- Highly Available cross-premises and VNet-to-VNet connectivity (Azure)
- Cloud VPN (GCP)
Dedicated Private Connection
While many customers have confidence in the stability of internet services and use IPSEC VPN to connect their on-premises to RISE with SAP PCE, some regulated customers may prefer a dedicated private connection to the Hyperscaler environment for added security and compliance when running their business processes and applications.
Amazon Web Services – AWS Direct Connect
The AWS Direct Connect allows customers to establish a dedicated network connection from their on-premises data centres to AWS. This dedicated connection bypasses the public internet and provides a more reliable, lower-latency communication between the customer's on-premises infrastructure and AWS. A dedicated connection is a 1G or 10G physical Ethernet port exclusively assigned to one customer. In case of hosted connection, which can be ordered by customers from AWS Direct Connect Partners and supported bandwidth for hosted connection can start from 50M to 10G. Since SAP manages to AWS environment, SAP ECS will provide Letter of Authorization to customer.
Figure 4: Supported Connectivity on AWS
As part of this configuration, SAP will provide the Direct Connect (DX) name, location, port speed, and interconnect partner on the AWS portal. This is an "AWS DX port" operating at a specific speed that belongs to an AWS Account ID managed by SAP. You can refer to a blog “Private Connectivity to SAP HANA Enterprise Cloud via AWS Direct Connect” and AWS documentation on AWS Direct Connect. An high level architecture view of customer network connecting to RISE with SAP landscape via AWS Direct Connect is as follows:
Figure 5: AWS Direct Connect
Azure - ExpressRoute
Azure ExpressRoute is a service provided by Microsoft Azure that enables customers to create private connections between their on-premises infrastructure and Azure data centres. It bypasses the public internet and provides a more reliable, secure, and lower-latency communication between the customer's on-premises infrastructure and Azure.
RISE with SAP S/4HANA cloud, Private Edition supports Expressroute, ExpressRoute Direct and sharing of customer’s own express route. Azure ExpressRoute allows customers to connect to Azure through a partner's data centre, such as an Equinix or colocation facility, using a dedicated and secure connection. This provides a layer of separation from the public internet and helps customers meet their compliance requirements.
Figure 6: Connectivity Option to RISE with SAP - PCE on Azure
ExpressRoute Direct, is a direct connection between the customer's on-premises network and Microsoft's global network. This direct connection provides increased security and lower latency as compared to ExpressRoute. Additionally, ExpressRoute Direct provides dual 100 Gbps or 10 Gbps connectivity, which supports Active/Active connectivity at scale. With ExpressRoute through partner Data centre, incremental bandwidth in the range of 100 Mbit/s, 200 Mbit/s, 500 Mbit/s, 1 Gbps, 2 Gbit/s, 5 Gbit/s, 10 Gbit/s can be supported.
Figure 7: Azure ExpressRoute Connectivity
The above diagram is shown with ExpressRoute failover to IPSEC VPN. The primary data connection is always through the ExpressRoute circuit. If it fails, data will be routed through the Site-to-Site VPN. To prevent “asymmetrical” routing, the customer's local network should prioritize ExpressRoute over Site-to-Site VPN by assigning higher preference to routes received via ExpressRoute. For enhanced security requirement for regulated industries, SAP ECS supports running an encrypted VPN tunnels over an ExpressRoute connection.
You can refer to Azure documentation relating to Extend an on-premises network using ExpressRoute to know more about workflow and architecture components.
Google Cloud Interconnect
Similar to AWS Direct Connect and Azure ExpressRoute, Google supports Cloud Interconnect. This is a service provided by Google Cloud Platform (GCP) that allows customers to connect their on-premises infrastructure to GCP via a dedicated and secure network connection. It enables customers to transfer data between their on-premises systems and GCP services with reduced latency and improved security compared to public internet connections. There are two types of interconnects are supported – partner interconnect and dedicated interconnect. For high bandwidth requirements (10Gb/s and above), dedicated interconnect is a good fit. If lower capacity is sufficient or a direct link to Google Point of Presence (PoP) is not feasible, partner interconnect is the better option.
Figure 8: Supported Cloud Connectivity on GCP
For detailed architecture of Google Cloud Interconnect, you can refer to this link.
VPC/VNET Peering
Many customers using RISE with SAP S/4HANA Cloud, Private Edition have an existing account with hyperscale providers, where they've set up their own VPC/VNET and run their own vital business processes and applications. As a part of integration, a secure connection is needed between the customer's own VPC/VNET under their account/subscription and the VPC/VNET managed by SAP ECS in RISE with SAP.
In case of Azure, Virtual network peering allows customers to easily connect their Azure virtual network to the RISE with SAP - PCE virtual network. Communication between virtual machines is facilitated through Microsoft's backbone infrastructure, with traffic only passing through Microsoft's private network. Further Network Security Group can be used to control access between the VNETs. This results in a fast and efficient connection between resources in different virtual networks. Azure offers two peering options for RISE with SAP – PCE customers: Virtual network peering within the same region, and global virtual network peering for connections across Azure regions.
A simple architecture on Azure is as follows:
Figure 9: Azure VNET Peering Connection
The same concept applies to Google Cloud platform too. This connection can be achieved through VPC Peering as shown the diagram below:
Figure 10: Google Cloud VPC Peering
For details of the architecture and limitations, please refer to the below link:
Advantages of VPC/VNET Peering
There are many advantages of this connection due to higher performance as it uses Cloud Services Provider Backbone Network, Low Latency, Traffic Isolation. However, VPC can only communicate with peered VPC and transitive indirectly connected VPC is not supported. Also customers must ensure that there is no overlapping IP Addresses. To overcome limitation on non-transit VPC peering, customer can consider using Transit Gateway and this should be managed by customer. RISE with SAP PCE does not allow deployment of Transit Gateway at the SAP managed landscape. In case of Azure, customer can consider using “Gateway Transit”
RISE with SAP PCE – PCE Access via Internet
If customer wants to access SAP S/4HANA in PCE via Internet, this can be allowed via traffic traversing via Web Application Firewall (WAF). For inbound Internet connection, only HTTPS/TLS1.2 is allowed. In case of Azure deployments, the Azure Application Gateway (AAG) is used and this as a web traffic load balancer and has the capabilities of a Layer 7 load balancer as well as a Web Application Firewall (WAF). Similarly, AWS WAF and Google Cloud supported Cloud Armor is used for Internet inbound traffic for AWS and GCP environments. This provides screening of L4-L7 traffic, protecting web application from common exploits and vulnerabilities based on OWASP 3.0
Figure 11: Internet Inbound Connection
Conclusion
This blog offers an overview of the different connectivity options available to customers. To ensure secure connectivity to RISE with SAP S/4HANA Cloud, Private Edition, a thorough understanding of the customer's existing on-premises network, performance, latency, bandwidth, cost, and security requirements is necessary. While the responsibility for secure connectivity from on-premises to RISE with SAP PCE lies with the customer, SAP Cloud Architect Advisors (CAA) should be consulted to address design considerations.
Disclaimer
© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.
- SAP Managed Tags:
2 Comments
