Other considerations - General SAP Guides
SAP Business Technology Platform (BTP) with RISE on AWSConnecting to cloud solutions or SaaS from RISEConnectivity patterns for multi-cloud to RISEHow to implement chargeback capability for connectivity to RISEIntegrating Domain Name System to RISE and Route 53 consideration

Other considerations

This sections provides information about other considerations when connecting to RISE.

SAP Business Technology Platform (BTP) with RISE on AWS

You can use SAP Business Technology Platform BTP services on AWS to extend the functionality of the RISE with SAP. SAP recommends SAP Cloud Connector to connect RISE with SAP VPC with SAP BTP via internet. When both RISE with SAP and SAP BTP run on AWS (in the same AWS region or different AWS regions), the network traffic is encrypted and contained within AWS Global Network, without going through the internet (see the following diagram). This provides better security and performance for any integration use-cases between RISE with SAP and SAP BTP. For more information, see Amazon VPC FAQs - Does traffic go over the internet when two instances communicate using public IP addresses or when isntances communicate with a public AWS service endpoint ?.

Example connections across Regions

As displayed in the preceding diagram, you can configure Transit Gateway to handle both RISE and BTP network traffic. For more information, see How to route internet traffic from on-premise via Amazon VPC?

SAP also offers SAP Private Link Service for SAP BTP on AWS. SAP Private Link connects SAP BTP on AWS with a secure connection without using public IPs in your AWS account.

Connecting multiple accounts using AWS PrivateLink

You can connect to an AWS endpoint service from an SAP BTP application running on Cloud Foundry. By establishing this connection, you can directly connect to AWS services, or for example, to an S/4HANA system. For a complete list of supported AWS services, see Consume Amazon Web Services in SAP BTP.

You can establish a secure and private communication between SAP BTP and AWS services with SAP Private Link Service. By using private IP address ranges (RFC 1918), you reduce the attack surface of the application. The connection does not require an internet gateway. If you do not require this extra layer of security, you can still connect via the public APIs of SAP BTP without SAP Private Link, and benefit from AWS global network. For more information, see Amazon VPC FAQs.

SAP Private Link for AWS currently supports connections initiated from SAP BTP Cloud Foundry to AWS.

For AWS services across AWS Regions, you can create a VPC in the same AWS Region as your SAP BTP Cloud Foundry Runtime, and connect these VPCs via VPC peering or AWS Transit Gateway. For a list of supported Regions, see Regions and API Endpoints Available for the Cloud Foundry Environment.

Connecting multiple accounts in multiple Regions using AWS PrivateLink

SAP Private Link Service is a paid service offered by SAP on SAP BTP. For more information see: SAP Discovery Center – Services – SAP Private Link Service.

Cost associated to AWS Services in the AWS account - managed by the Customer to facilitate cross region connectivity for example the AWS Network Load Balancer, or Transit Gateway vary. For more information on price, see the dedicated pricing pages of the listed AWS Services.

Connecting to cloud solutions or SaaS from RISE

When modernizing the SAP landscape, you may subscribe to several SAP cloud solutions or SaaS from independent software vendors to complement RISE with SAP solution.

When the cloud solutions are running on AWS (in the same AWS region or different AWS regions), the connectivity from RISE with SAP is kept within the AWS global network without requiring internet connectivity. The connectivity is retained through the provided squid proxy server within RISE with SAP VPC.For more information, see Amazon VPC FAQs - Does traffic go over the internet when two instances communicate using public IP addresses or when isntances communicate with a public AWS service endpoint ?.

Connecting to cloud solutions or SaaS from RISE

If your cloud is running on other data centre or with another cloud service provider, then you need internet connectivity.

Connecting to cloud solutions or SaaS from RISE

SaaS cloud solutions do not offer connectivity via VPN, Direct Connect or any other means of private connectivity. You can implement a centralized egress to internet architecture to manage this connectivity. For more information, see Centralized egress to internet .

Connectivity patterns for multi-cloud to RISE

In a complex connectivity scenario, you may need to integrate RISE with SAP setup with on-premises, AWS-hosted systems, and a variety of SaaS solutions and other cloud service providers.

Managing connectivity directly from the AWS environment decouples dependencies with on-premises networking infrastructure, improving availability and resiliency of the overall landscape.

You can use public or private connectivity to connect multi-cloud with RISE.

Connectivity patterns for multi-cloud to RISE

Public connectivity

Connectivity is routed over the public internet. This pattern is typically used for connectivity from RISE with SAP to SaaS solutions that runs across multiple clouds. When building connectivity routed over the public internet, consider the following:

  • ensure that all communication is encrypted

  • protect end-points by using AWS services, such as Elastic Load Balancers and AWS Shield

  • monitor endpoints using Amazon CloudWatch

  • ensure that traffic between two public IP addresses hosted on AWS is routed over the AWS network

Private connectivity

The following three are the options to establish private connectivity between different cloud service providers:

  • Site-to-site VPN encrypted tunnel routed over public internet

  • private interconnect using AWS Direct Connect in a managed infrastructure (use Azure ExpressRoute for Azure and Google Dedicated Interconnect for Google Cloud Platform)

  • private interconnect using an AWS Direct Connect in a facility with a multi-cloud connectivity provider

The following diagram describes the factors to choose a multi-cloud connectivity method.

Connectivity patterns for multi-cloud to RISE

For more information, see Designing private network connectivity between AWS and Microsoft Azure.

How to implement chargeback capability for connectivity to RISE

If you are a company with subsidiaries, you may have different RISE contracts, leading to deployments in separate AWS accounts while requiring an interlinked network connectivity. In this instance, you must deploy Transit Gateway connection in a Landing Zone (multi-account) setup. It can scale your RISE deployment and integrate with multiple RISE with SAP VPCs.

Transit Gateway Flow Logs enables effective cost management. Transit Gateway Flow Logs can be integrated with Cost and Usage Report (CUR) that can be attributed as chargeback to the business units. For more information, see Logging network traffic using Transit Gateway Flow Logs .

How to implement chargeback capability for connectivity to RISE

The preceding diagram displays how Transit Gateway can be used to connect multiple RISE with SAP VPCs and provide chargeback capability through the Flow Logs.

For more information, see the following blogs:

Use the following steps to enable this setup:

  1. Enable Transit Gateway Flow Logs. For more information, see Create a flow log that publishes to Amazon S3.

  2. Setup Cost and Usage Reporting and setup Athena to utilize the reporting. For more information, see Creating Cost and Usage Reports and Querying Cost and Usage Reports using Amazon Athena .

  3. Obtain the Transit Gateway data processing charge per-account.

    1. Decide a cost allocation strategy - distribute costs evenly across all accounts or distribute proportionally across all accounts.

    2. Calculate the total network traffic and percentage allocation per account using AWS Transit Gateway query.

    3. Estimate cost per account, by collecting from CloudWatch that collects Network In(Upload) and NetworkOut(Download).

      1. NetworkIn(Upload) + NetworkOut(Download) per usage account/ total data processed in network account

      2. % of usage x total cost = chargeback cost per usage account

Integrating Domain Name System to RISE and Route 53 consideration

Domain Name System (DNS) translates domain names and IP addresses in both ways such as (www.amazon.com as 1.2.3.4 in IPv4 or 1200:ab00:1024:1::b410:e6b1 in IPv6). There are two methods available to integrate DNS to RISE:

  • DNS Zone Transfer: This method replicates the DNS databases across a set of DNS Servers. It can provide higher availability, redundancy and higher SLA. In a typical RISE environment, you delegate a sub-domain (example. *.sap.customer.com) to the RISE DNS Servers. If one server becomes unavailable, other servers can continue to provide DNS services without interruption. If a customer is using Route 53, which does not support Zone Transfer, customer need to set up Route 53 inbound resolver together with a Route 53 private hosted zone and provide the resolver IPs to SAP for routing purposes, you can find out more in the DNS Conditional Forwarding as below.

  • DNS Conditional Forwarding (also called IP Forward): The DNS servers only forward queries for specific domain names that is not part of its own name space. (example: Amazon Route 53 forwards DNS query of *.sap.customer.com to RISE DNS Servers). This allows for more precise control over how DNS queries are handled, especially in complex network environments. Amazon Route 53 Resolver supports both public and private DNS resolution, facilitates hybrid cloud setups, and enhances availability, performance, and security for AWS resources and on-premises networks.

Here is a reference architecture on how to integrate Amazon Route 53 with RISE.

Integrating Domain Name System Route 53 to RISE

For more details, refer to the following AWS documentation: