Skip to Content
Technical Articles

Accessing SAP Cloud Platform via AWS Direct Connect

Traditionally, SAP Cloud Platform is considered as public cloud offered as Platform as a Service (PaaS), accessible only via public Internet.  While Internet services have become reliable and stable over the years and many customers still choose to access SAP Cloud Platform securely via public Internet, few of our regulated customers in Government, Banking and Finance and other public sector organizations require dedicated “direct” connectivity from on-premise to SAP Cloud Platform services to access business critical applications. For such customers, using public internet is unacceptable for security and compliance reasons.

In this blog, we explore how SAP customers can access SAP Cloud Platform securely via AWS Direct Connect connection without traffic traversing via public internet. We will explore details on how to establish direct connectivity between on-premise customer location and SAP Cloud Platform (Cloud Foundry) running on AWS.

SAP Cloud Platform (CF@AWS) Access via AWS Direct Connect

SAP Cloud (Cloud Foundry) runs on public cloud service providers (hyperscalers) such as AWS, Azure, GCP and Alibaba. The SAP Cloud Platform regions and service capabilities and hyperscalers used in various regions can be found here.  While all hyperscalers provide native capability to establish dedicated direct link to their respective cloud platform, we focus specifically only on AWS in this blog.

AWS Direct Connect service is a physical connection that connects customer on-premise network to AWS. This allows customer on-premise traffic to traverse via secure direct network to SAP Cloud Platform without traversing via Public Internet and this offers an excellent bandwidth, consistent network performance and low latency. The connectivity architecture has three parts:

 

Step 1:

  • As a prerequisite, a customer must have an AWS account and obtain Letter of Authorization and Connecting Facility Assignment (LOA-CFA) from AWS after specifying name, location, speed and interconnection provider details. This is essentially customer requesting a “AWS DX port” operating at certain speed belonging to their AWS Account ID and allow that port to be connected to their router via cross-connect. This is entirely customer responsibility.

Step 2:

  • Customer works with Interconnect Provider (such as Equinix, Verizon) by presenting LOA-CFA to “cross connect” AWS DX port in DX location to customer router/partner router in the same DX location. Connections to AWS Direct Connect require single mode fiber, 1000BASE-LX (1310nm) for 1 gigabit Ethernet, or 10GBASE-LR (1310nm) for 10 gigabit Ethernet. Auto Negotiation for the port must be disabled. Customer router must support 802.1Q VLANs across these connections, support Border Gateway Protocol (BGP) and BGP MD5 authentication.
  • Once cross connect is established, customer AWS Account ID will accept incoming connection request. If customers are large enterprise or public sector, they can reach out to your national carrier to provide physical connectivity from DX location through to their business premises or on-premise data center.  If customer is a smaller company, they can connect AWS DX Port to their partner router and partner brings physical connectivity to customer on-premise router. In any case, it is customer responsibility to bring that physical connectivity from DX Port to their on-premise router. This is just single physical fiber optic cable from AWS DX Port all the way to customer premises. While AWS DX port allocation will be faster, setting physical connection from your on-premise router to DX Router will take many weeks and this must be planned well in advance.

Step 3:

  • Once physical connection is setup between AWS DX Port to on-premise router, virtual configuration must be completed. To connect to AWS resources that are reachable by a public IP address or AWS public endpoints, Public Virtual Interface should be used. Therefore, over the top of physical connection, a public VIF should be configured to connect to AWS Public zone services. Each VIF is considered as one VLAN. BGP peering must be established between AWS Port and Customer Router.
  • Customer will provide BGP ASN number for establishing BGP session.Once Public VIF is setup, AWS will advertise its global IP routes to customer router using Border Gateway Protocol (BGP). Customer have an option to filter routes based on BGP attributes limiting AWS public routes only from specific regions that establishes connectivity to customer network.  Similarly, customer can advertise their routes along with BGP attributes to limit route advertisement to single or multiple regions.  SAP provides documentation related to URL/IP address SAP Cloud Foundry environment in AWS here.
  • It must be noted that AWS Public VIF connectivity provides direct connectivity to AWS public zone (such as public endpoints, Elastic Load Balancers, AWS API Gateways etc). Therefore, customer must establish best practice approach and comply to their internal IT policy for connecting to AWS public network.
  • It must be noted that this is entirely customer responsibility to establish connectivity from their on-premise to SAP Cloud Platform using public VIF, working with AWS, Interconnect Providers and Networks Service Providers.

High Availability Setup

Many customer run business critical applications and integration scenarios on SAP Cloud Platform. In order to ensure high availability and cater for disaster recovery scenarios customer can have diversity of connection via two separate co-location partners operating in multiple location. While building redundant links, it is also important to provision enough capacity to ensure that failure of one network connection does not overwhelm and degrade redundant connection. More information on best practice guideline can be found here.

Additional Considerations

It is important to understand that there is no built-in or native encryption in AWS Direct Connect link. However, SAP supports application level encryption for data in transit via HTTPS/TLS1.2. In most cases, this will be acceptable to our customers to meet security and regulatory compliance. Also, it must be noted that for on-premise integration scenarios, Cloud Connector is still needed as an reverse invoke proxy solution to communicate to SAP backend systems. The network traffic (TLS1.2 tunnel) from cloud connector to SAP Cloud Platform (Cloud Foundry) will traverse via this AWS Direct connect link instead of going via public Internet.

Conclusions

If SAP enterprise customers have multiple SAP solutions running on AWS such as SAP HANA Enterprise Cloud, SAP Cloud Platform and their own works loads, a single AWS Direct Connect physical link can be used to create multiple Private VIF and Public VIF. Please refer to my blog on how to connect to use Private VIF for SAP HANA Enterprise Cloud here. This helps to protect existing investments on AWS Direct Connect. If customers are using SAP Cloud Platform (Cloud Foundry) using Azure, similar approaches are supported using Azure Express Route and for customers using SAP Cloud Platform (Cloud Foundry) on Google Cloud Platform, customer can use Google Cloud Interconnect. This approach greatly helps our customers to bypass internet while accessing SAP Cloud Platform (Cloud Foundry) and thereby facilitate meeting security and compliance requirements.

3 Comments
You must be Logged on to comment or reply to a post.