# Connectivity
<a name="connectivity-rise"></a>

You must establish connectivity between AWS cloud where your RISE with SAP solution is running and on-premises data centers. You also need a connection for direct data transfer (to avoid routing data via your on-premises locations) and communication between SAP systems and your applications running on AWS cloud. The following image provides an example overview of connectivity to RISE with SAP VPC.

![\[An example RISE with SAP VPC connection between an SAP-managed account and on-premises data centers\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-connectivity.png)


See the following topics for further details:

**Topics**
+ [Roles and responsibility for establishing connectivity](rise-responsibility.md)
+ [Connecting to RISE from on-premises networks](rise-connection-on-premises.md)
+ [Connecting to RISE from your AWS account](rise-accounts.md)
+ [Connect to nearest Direct Connect POP (including Local Zone)](rise-local-zone.md)
+ [Decision tree on connectivity to RISE](rise-decision-tree.md)
+ [Other considerations](other-considerations.md)

# Roles and responsibility for establishing connectivity
<a name="rise-responsibility"></a>

Under RISE with SAP, the SAP Enterprise Cloud Services (ECS) team manages the SAP S/4HANA Private Cloud Environment. The *Supplemental Terms and Conditions* provided by SAP has a section on Excluded Tasks. You are responsible for running such tasks. You can also use a third-party service provider to manage the excluded tasks for you. For further details, see [SAP Product Policies](https://www.sap.com/about/agreements/policies.html).

The primary task required for deploying RISE with SAP is to establish network connectivity to RISE with SAP VPC on AWS. As per the RISE with SAP agreement, you are responsible for establishing a connection to RISE.

We recommend that you spend time understanding the available options on how to connect your on-premises network and/or existing AWS accounts to RISE with SAP VPC on AWS. Review the subsequent sections for more information.

# Connecting to RISE from on-premises networks
<a name="rise-connection-on-premises"></a>

Connectivity to RISE with SAP on AWS from on-premises is supported using AWS VPN or AWS Direct Connect or a combination of the two.

**Topics**
+ [Connecting to RISE using AWS VPN](rise-connection-vpc.md)
+ [Connecting to RISE using AWS Direct Connect](rise-connection-direct-connect.md)
+ [Connecting to RISE using SD-WAN](rise-connection-sd-wan.md)
+ [Implementation steps for connectivity](rise-connection-implementation-steps.md)

# Connecting to RISE using AWS VPN
<a name="rise-connection-vpc"></a>

Enable access to your remote network from RISE with SAP VPC using [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html). Traffic between AWS cloud and your on-premises location is encrypted via Internet Protocol security (IPsec) and transferred through a secure tunnel on internet. This option is efficient, and faster to implement when compared to AWS Direct Connect. For more information, see [Connect your VPC to remote networks using AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html).

You can get a maximum bandwidth of up to 1.25 Gbps per VPN tunnel. For more information, see [Site-to-Site VPN quotas](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html).

To scale beyond the default maximum limit of 1.25 Gbps throughput of a single VPN tunnel, see [How can I achieve ECMP routing with multiple Site-to-Site VPN tunnels that are associated with a transit gateway?](https://repost.aws/knowledge-center/transit-gateway-ecmp-multiple-tunnels) 

When using this option, SAP requires the following details:
+ BGP ASN
+ IP address of your device

You can obtain these details from your AWS VPN device on-premises.

When connecting your remote network directly to RISE using AWS Site-to-Site AWS VPN, the cost for the AWS VPN Connection and the cost for data transfer out are included in the RISE subscription.

For more information see: [AWS Site-to-Site AWS VPN Pricing](https://aws.amazon.com/vpn/pricing/).

Note: Because the cost associated with the lifecycle and operation of a "Customer gateway device" (a physical device or software application on your side of the Site-to-Site AWS VPN connection) varies, this is not taken into consideration in this document.

# Connecting to RISE using AWS Direct Connect
<a name="rise-connection-direct-connect"></a>

Use AWS Direct Connect if you require a higher throughput or more consistent network experience than an internet-based connection. AWS Direct Connect links your internal network to an AWS Direct Connect location over a standard Ethernet fiber-optic cable. You can create different types of virtual interfaces (VIFs) to connect with various AWS services. For example, you can create a Public VIF to communicate with public services like Amazon S3 or a Private/Transit VIF for private resources such as Amazon VPC, while bypassing the internet service providers in your network path. For more information, see [AWS Direct Connect connections](https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithConnections.html).

You can choose from a dedicated connection of 1 Gbps, 10 Gbps, 100 or 400 Gbps or an AWS Direct Connect Partner’s hosted connection where the Partner has an established network link with AWS cloud. Hosted connections are available from 50 Mbps. 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps, and 25 Gbps. You can order hosted connections from an AWS Direct Connect Delivery Partner approved to support this model. For more information, see [AWS Direct Connect Delivery Partners](https://aws.amazon.com/directconnect/partners/).

To connect, use a virtual private gateway in AWS account managed by SAP or a Direct Connect gateway in your AWS account associated with a virtual private gateway in AWS account managed by SAP. For more information, see [Direct Connect gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html). Direct Connect gateway can also connect to a AWS Transit Gateway. For more information, see [Connecting to RISE using your single AWS account](rise-connection-accounts.md).

You must acquire a *Letter of Authorization* from SAP to setup a AWS Direct Connect dedicated connection in the AWS account managed by SAP.

When connecting your remote network directly to RISE using AWS Direct Connect, the cost for data transfer out (egress) is included in the RISE subscription. Costs associated to the capacity (the maximum rate that data can be transferred through a network connection) and the port hours (the time that a port is provisioned for your use with AWS or an [AWS Direct Connect Delivery Partners](https://aws.amazon.com/directconnect/partners/)) are not included in the RISE subscription. AWS Direct Connect does not have setup charges, and you may cancel at any time, however, services provided by your [AWS Direct Connect Delivery Partners](https://aws.amazon.com/directconnect/partners/) or other local service provider may have other terms and conditions that apply.

For more information, see: [AWS Direct Connect Pricing](https://aws.amazon.com/directconnect/pricing/) 

# Connecting to RISE using SD-WAN
<a name="rise-connection-sd-wan"></a>

 **What is SD-WAN** 

 [Software-Defined Wide Area Networking (SD-WAN)](https://en.wikipedia.org/wiki/SD-WAN) is a networking technology that uses software to manage and route traffic across different networks such as Multi-Path Label Switching (MPLS), public internet, or the AWS backbone focusing on improving connectivity and application performance. SD-WAN primarily operates at layer 3 (Network Layer) of the network OSI model offering centralized control, routing, path selection, IP-based policies, and the ability to prioritize specific mission critical applications, such as SAP, making it well-suited for cloud-based RISE with SAP environments.

Although SD-WAN primarily operates at Layer 3, using an overlay network such as broadband internet, it can utilize Layer 2 (Data Link) technologies such as [AWS Direct Connect](https://aws.amazon.com/directconnect/) as the underlay network for transport, and Layer 3 (Network) technologies such as [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html).

In SD-WAN architecture, an SD-WAN headend acts as a hub or centralized network component, while [SD-WAN edge devices](https://en.wikipedia.org/wiki/SD-WAN#SD-WAN_edge) deployed at branch offices, remote sites or data centers which serves as the entry and exit points for WAN Traffic.

You can refer to more detailed information in the [Reference Architectures for Implementing SD-WAN Solutions on AWS](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/sd-wan-deployment-models-ra.pdf?did=wp_card&trk=wp_card).

 **Scenario A: SD-WAN appliances (edge and/or headend/hub) on-premises** 

 [AWS Transit Gateway Connect](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html) allows you to extend your SD-WAN network to AWS using [GRE (Generic Routing Encapsulation)](https://en.wikipedia.org/wiki/Generic_routing_encapsulation) tunnels without needing additional AWS infrastructure. Through [Transit Gateway Connect Peer](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html#tgw-connect-peer), you can establish GRE tunnels between your transit gateway in your AWS account and the SD-WAN appliance on-premises which are connected via AWS Direct Connect connection as underlying transport.

The appliance must be configured to send and receive traffic over a GRE tunnel to and from the transit gateway using the [Connect attachment](https://docs.aws.amazon.com/vpc/latest/tgw/create-tgw-connect-attachment.html). The appliance must be configured to use [BGP (Border Gateway Protocol) ](https://aws.amazon.com/what-is/border-gateway-protocol/)for dynamic route updates and health checks.

Each connection can be configured with its own route table and BGP peer, enabling you to extend your on-premises network segmentation via [Virtual routing and forwarding (VRF)](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) to AWS. The RISE with SAP VPC is attached to the AWS Transit Gateway.

This setup provides a streamlined way to connect your SD-WAN environment with RISE with SAP on AWS using AWS Direct Connect, maintaining network separation while simplifying the overall architecture.

In this scenario, the [overlay network](https://en.wikipedia.org/wiki/Overlay_network) is SD-WAN (with GRE Tunnels) with the headend/hub or edge devices deployed on on-premises, and the underlay transport is AWS Direct Connect

 **Pattern A-1: SD-WAN devices integration with AWS Transit Gateway and AWS Direct Connect with your AWS landing zone** 

![\[SD-WAN devices integration with Transit Gateway and Direct Connect with your landing zone\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-pattern-a-1-sd-wan-tgw-dx-lz.png)


The preceding diagram illustrates a pattern of how you can extend and segment your SD-WAN traffic to AWS without adding extra infrastructure. You can create Transit Gateway connect attachments using an AWS Direct Connect connection as underlying transport in your AWS account.

Outbound from RISE with SAP VPC:

1. Traffic initiated from the RISE VPC to the corporate data center is routed to the Transit Gateway.

1. The Transit Gateway connect attachment uses the Direct Connect connection as the underlay transport and connects the Transit Gateway to the corporate data center SD-WAN device with GRE tunneling and BGP.

Inbound to RISE with SAP VPC:

1. Traffic from the corporate data center SD-WAN device to the RISE VPC is forwarded to the Transit Gateway via the GRE tunnel of the Transit Gateway attachment over the Direct Connect link.

1. Transit Gateway forwards the traffic to the destination RISE with SAP VPC.

 **Pattern A-2: SD-WAN devices integration with AWS Transit Gateway and AWS Direct Connect with no AWS landing zone** 

![\[SD-WAN devices integration with Transit Gateway and Direct Connect with no landing zone\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-pattern-a-2-sd-wan-tgw-dx-no-lz.png)


The preceding diagram illustrates a pattern of how you can extend and segment your SD-WAN traffic to AWS without adding extra infrastructure. In RISE with SAP, you can request SAP to create Transit Gateway connect attachments using a Direct Connect connection as underlying transport. Customers can leverage SAP-managed [Direct Connect gateway (DXGW)](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html) if required.

Outbound from RISE with SAP VPC:

1. Traffic initiated from RISE VPC to the corporate data center is routed to the Transit Gateway.

1. The Transit Gateway connect attachment uses the Direct Connect connection as transport and connects the Transit Gateway to the corporate data center SD-WAN device using GRE tunneling and BGP.

Inbound to RISE with SAP VPC:

1. Traffic from the corporate data center SD-WAN device to the RISE VPC is forwarded to the Transit Gateway via the GRE tunnel of the Transit Gateway attachment over the Direct Connect link.

1. Transit Gateway forwards the traffic to the destination RISE with SAP VPC.

 **Scenario B: SD-WAN appliances (edge and/or headend/hub devices) in AWS ** 

In this scenario, the virtual appliances of the SD-WAN network are deployed in a VPC within AWS. Then, you use a VPC attachment as underlying transport for the Transit Gateway connect attachment between the SD-WAN virtual appliances and the Transit Gateway in your AWS account(s). Similar to Scenario A, Transit Gateway connect attachments support GRE for higher bandwidth performance compared to a VPN connection. It supports BGP for dynamic routing and removes the need to configure static routes. In addition, its integration with [Transit Gateway Network Manager](https://docs.aws.amazon.com/vpc/latest/tgwnm/what-is-network-manager.html) provides advanced visibility through global network topology, attachment level performance metrics, and telemetry data.

Between on-premises and AWS, the [overlay network](https://en.wikipedia.org/wiki/Overlay_network) is SD-WAN with GRE or IPSec tunnels with the headend/hub deployed within AWS, and the underlay transport could be Internet, MLPS, or Direct Connect. Following are the architecture patterns under this scenario:

Note: Network patterns covered in the following sections are applicable only with your existing or a new landing zone setup on AWS. For SD-WAN appliances deployment and connectivity directly with AWS Account – managed by SAP, refer to Pattern A-2.

 **Pattern B-1: SD-WAN appliances in AWS integrated with AWS Transit Gateway Connect with your AWS landing zone** 

![\[SD-WAN appliances integrated with Transit Gateway and Direct Connect with your landing zone\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-pattern-b-1-sd-wan-aws-tgw-dx-lz.png)


The preceding diagram illustrates a pattern of integrating your SD-WAN network with Transit Gateway using [connect attachments](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html) and placing (third-party) virtual appliances of the SD-WAN network in an Appliance VPC within AWS. It’s common to have SD-WAN edge appliances deployed at branch locations, and on-premises data center to create a full mesh topology.

Outbound from RISE with SAP:

1. Traffic initiated from the RISE VPC to the corporate data center is routed to the Transit Gateway.

1. The Transit Gateway connect attachment uses the VPC attachment as transport and connects Transit Gateway to the third-party appliance in the Appliance VPC using GRE tunneling and BGP.

1. The third-party virtual appliance encapsulates the traffic, which uses the SD-WAN overlay – on top of the Direct Connect link – to reach the corporate data center.

Inbound to RISE with SAP:

1. Traffic from branches outside AWS to the RISE VPC reaches the internet gateway of the appliance VPC via the SD-WAN overlay over the internet. Similarly, traffic from the corporate data center to the RISE VPC reaches the virtual private gateway of the Appliance VPC via the SD-WAN overlay over the Direct Connect link.

1. The third-party virtual appliance in the appliance VPC forwards the traffic to the Transit Gateway via the connect attachment.

1. Transit Gateway forwards the traffic to the destination RISE VPC.

 **Pattern B-2: SD-WAN appliances in AWS integrated with AWS Site-to-Site VPN** 

![\[SD-WAN appliances iintegrated with Site-to-Site VPN\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-pattern-b-2-sd-wan-s2svpn.png)


The diagram above illustrates a pattern of integrating your SD-WAN network with Transit Gateway using an AWS Site-Site VPN connection and placing (third party) virtual appliances of the SD-WAN network in an Appliance VPC within AWS. You may use this option when your third-party virtual appliance does not support GRE. It’s common to have SD-WAN edge appliances deployed at branch locations, and on-premises data center to create a full mesh topology.

Outbound from RISE with SAP:

1. Traffic initiated from the RISE VPC to the corporate data center is routed to the Transit Gateway Elastic Network Interface (TGW ENI).

1. The traffic is routed between the Transit Gateway and the third-party virtual appliance using the Site-to-Site VPN connection.

1. The third-party virtual appliance encapsulates the traffic, which uses the SD-WAN overlay – on top of the Direct Connect link – to reach the corporate data center.

Inbound to RISE WITH SAP:

1. Traffic from branches outside AWS to the RISE VPC reaches the internet gateway of the appliance VPC via the SD-WAN overlay over the internet. Similarly, traffic from the corporate data center to the RISE VPC reaches the virtual private gateway of the appliance VPC via the SD-WAN overlay over the AWS Direct Connect link.

1. The third-party virtual appliance in the appliance VPC forwards the traffic to the Transit Gateway via Site-to-Site VPN connection.

1. Transit Gateway forwards the traffic to TGW ENI of the destination RISE VPC.

# Implementation steps for connectivity
<a name="rise-connection-implementation-steps"></a>

This section provides a deeper dive into the implementation steps for connectivity between RISE with SAP and your on-premises environments (without any Customer managed AWS Account usage). The two options we will step into are: first, creating highly resilient deployment for critical workloads, and second, creating cost effective alternative for non-critical workloads.

For each option we’ll provide clarity on the details SAP needs, the steps you will take in your on-premises environment.

## Option 1: Resilient Deployment for Critical Workloads
<a name="option-1-resilient-deployment-for-critical-workloads"></a>

![\[Resilient Deployment for Critical Workloads\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-option-1-resilience-connectivity.png)


 [AWS Direct Connect (DX)](https://aws.amazon.com/directconnect/?nc=sn&loc=0) comes in two connection types, namely [Dedicated](https://docs.aws.amazon.com/directconnect/latest/UserGuide/dedicated_connection.html) and [Hosted](https://docs.aws.amazon.com/directconnect/latest/UserGuide/hosted_connection.html). A Dedicated DX is a physical Ethernet connection associated with a single customer, between the customer’s private network and AWS. Hosted DX is a physical Ethernet connection that an [AWS Direct Connect Partner](https://aws.amazon.com/directconnect/partners/) provisions on behalf of a customer. Learn about [AWS Direct Connect](https://aws.amazon.com/directconnect/) to familiarize yourself with the service.

To set up a resilient Direct Connect solution for your RISE with SAP deployment, follow these implementation steps:

 **Prerequisites** 

Before configuring the Direct Connect connection, ensure your on-premises network is ready. This includes:
+ Reviewing the AWS documentation on [BGP with AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) for detailed guidance on router configuration.
+ Configuring Border Gateway Protocol (BGP) on your routers with MD5 authentication. BGP is a requirement for using Direct Connect.
+ Verifying that your network can support multiple BGP connections for redundancy.

 **Initiate the Setup Process** 

Start by contacting your SAP ECS (Enterprise Cloud Services) representative and request the "AWS Connectivity Questionnaire" for RISE with SAP on AWS Direct Connect setup. This questionnaire will help gather the necessary information to provision the Direct Connect connection.

We advise you to set up redundant connections for high availability by completing the questionnaire for each Direct Connect connection you plan to establish. Review the [Direct Connect Resiliency Recommendations](https://aws.amazon.com/directconnect/resiliency-recommendation/) to understand best practices.

 **Complete the SAP Questionnaire** 

When filling out the AWS Connectivity Questionnaire, specify that you want to set up a resilient AWS Direct Connect configuration.

In the questionnaire, provide the following details about your Direct Connect connection:
+ Whether it’s a new or dedicated Direct Connect connection
+ The Direct Connect provider or partner you’ll be using
+ The specific Direct Connect region/location
+ The minimum number of Direct Connect links required
+ The subnet CIDR blocks for the primary and secondary Direct Connect links (in /30 CIDR format)
+ The VLAN ID
+ The Autonomous System Number (ASN) of your on-premises router
+ The IP address ranges of your on-premises network (to allow for proper firewall configuration)

Additionally, include information about your on-premises router, such as the make, model, and interface details.

Submit the completed questionnaire to your SAP ECS representative. SAP will then use this information to provision the necessary Direct Connect resources in your RISE with SAP environment on AWS.

 **SAP’s Responsibilities** 

After you submit the completed questionnaire, SAP will handle the following tasks (the list below is illustrative only for this context):
+ Create a virtual interface (depending on your DX type: hosted or dedicated)
+ Create the Direct Connect Gateway
+ If you need SAP to provision Transit Gateway in RISE VPC,
  + Setup the Transit Gateway (including the ASN you provided)
  + Create the Transit Gateway attachment for your VPC
  + Update the route tables to allow the Transit Gateway to communicate with the RISE with SAP network VPC
  + Associate the Transit Gateway with the Direct Connect Gateway, including the CIDR of the RISE with SAP network that will be advertised to your network

 **Complete the Setup Process** 

Once you receive the necessary information from SAP, such as the VLAN ID, BGP peer IPs, and optional BGP authentication key, configure your on-premises routers accordingly. This includes setting up the VLAN interface and BGP for the Direct Connect connection. Consult the AWS documentation on [router configuration for Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/router-configuration.html) for detailed instructions.

Configure for active/active topology: Implement routing policies to balance traffic across the redundant Direct Connect connections, leveraging BGP communities or more-specific subnet advertisements to influence path selection from AWS to your on-premises network.

 **Establish and Test the Connections** 

Coordinate with SAP to enable the BGP sessions for both Direct Connect connections. Verify the BGP paths and test failover scenarios by simulating the failure of one connection to ensure traffic properly fails over to the other.

Confirm end-to-end connectivity with SAP for both paths. You can also leverage the [AWS Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) to [perform scheduled failover tests](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_failover.html) and verify the resiliency of your connections. and validate the resiliency of your connections.

 **Maintain the Connections** 

Regularly review and update the Direct Connect configurations as needed. Coordinate any changes with SAP. Monitor the performance and availability of both connections, and refer to the AWS documentation on [Monitoring Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html) for best practices.

By following these steps, you can establish a resilient AWS Direct Connect solution to securely connect your on-premises infrastructure with the RISE with SAP environment on AWS, ensuring high availability and reliable network performance.

## Option 2: Cost Effective Alternative for Non-Critical Workloads
<a name="option-2-cost-effective-alternative-for-non-critical-workloads"></a>

![\[Cost Effective Alternative for Non-Critical Workloads\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-option-2-cost-effective-connectivity.png)


Some AWS customers prefer the benefits of one or more AWS Direct Connect connections as their primary connectivity to AWS, coupled with a lower-cost backup solution. Additionally, they may want an agile and adaptable connection that can be quickly established or decommissioned between network locations globally. To achieve these objectives, they can implement AWS Direct Connect connections with an AWS Site-to-Site VPN backup.

The Site-to-Site VPN connection consists of three key components:

1. Virtual Private Gateway (VGW) - The router on the AWS side

1. Customer Gateway (CGW) - The router on the customer side

1. The S2S VPN connection that binds the VGW and CGW together over two secure IPSec tunnels in an active/passive configuration

For in-depth documentation on establishing the AWS Site-to-Site VPN connection, refer to [Getting started with AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html) in the AWS documentation.

 **Prerequisites** 

This approach builds on the steps outlined in the previous Option 1 for setting up a Resilient AWS Direct Connect solution. After completing those Direct Connect implementation steps, you can add an Site-to-Site VPN connection as a failover option.

While your Direct Connect connections are being provisioned, you can begin preparing your on-premises infrastructure for the VPN setup:
+ Review the AWS documentation on Site-to-Site VPN to understand the requirements and best practices.
+ Ensure your firewalls allow the necessary traffic for the VPN tunnels.
+ Confirm you have two customer gateway devices or a single device capable of managing multiple VPN tunnels.

The addition of an Site-to-Site VPN connection provides a faster and more agile backup to your primary Direct Connect links. It’s a similar process to setting up the Direct Connect, but with a few key differences.

 **Initiate the Setup Process** 

Start by contacting your SAP ECS representative again and request the "AWS Connectivity Questionnaire" for adding an AWS Site-to-Site VPN connection to your RISE on AWS setup. Inform SAP of your intent to implement the VPN as a failover to your Direct Connect links.

 **Complete the SAP Questionnaire** 

When filling out the AWS Connectivity Questionnaire this time, specify that you want to set up an AWS Site-to-Site VPN in addition to the Direct Connect connections.

In the AWS Connectivity Questionnaire, you’ll need to provide the following information about the VPN connection in addition to the details filled out for the DX:
+ Customer VPN Gateway details such as the make and model of your customer gateway device(s)
+ Customer VPN Gateway Internet facing public IP Address
+ Type of Routing (static / dynamic)
+ BGP ASN for Dynamic Routing (Customer gateway ASN for BGP. Only 16 bit ASN is supported.)
+ ASN for the AWS side of the BGP session (16- or 32-bit ASN)
+ Customer Side BGP Peer IP-address (if different from VPN peer IP provided)
+ Second Public IP Address (OPTIONAL: only if active-active mode is used)
+ Customer On-Premises Network IP ranges

Submit the completed questionnaire to SAP. They will then create the VPN connection and provide you with the configuration details.

 **SAP’s Responsibilities** 

After you submit the completed questionnaire, SAP will handle the following tasks (the list below is illustrative only for this context):
+ Create the customer gateway (with your provided information like BGP ASN, IP address, and optional private certificate)
+ Create the AWS Site-to-Site VPN and attach it to the RISE with SAP Transit Gateway and your customer gateway
+ Provide the VPN configuration file for you to set up on your on-premises router
+ If you need SAP to provision Transit Gateway in RISE VPC, SAP will add the necessary route to the Transit Gateway route table and update the security groups

Using the information received from SAP, configure the VPN tunnels on your on-premises router. Implement routing policies to prefer the Direct Connect connection over the VPN as the primary path.

Refer to the AWS documentation on [router configuration for Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/router-configuration.html) for guidance on the necessary settings.

 **Test and Verify Connections** 

Coordinate with SAP to enable the VPN connection and verify end-to-end connectivity. Test failover scenarios by simulating a Direct Connect failure and ensure traffic properly fails over to the VPN.

Confirm with SAP that the failover is working as expected for both the Direct Connect and VPN paths.

 **Maintain the Connections** 

Regularly review and update the configurations for both the Direct Connect and VPN connections. Coordinate any changes with SAP.

Monitor the performance and availability of both connections, and refer to the AWS documentation on [monitoring Direct Connect and VPN for best practices](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html).

By implementing this Direct Connect with Site-to-Site VPN failover solution, you can achieve a highly resilient connectivity setup for your RISE with SAP deployment on AWS, ensuring seamless failover and reliable network performance.

# Connecting to RISE from your AWS account
<a name="rise-accounts"></a>

You can connect to RISE from your AWS account in the following ways.

**Topics**
+ [Amazon VPC peering](rise-connection-peering.md)
+ [AWS Transit Gateway](rise-connection-transit.md)
+ [AWS Direct Connect gateway](rise-connection-direct-connect-gateway.md)
+ [AWS Cloud WAN](rise-connection-cloud-wan.md)
+ [Connecting to RISE using your single AWS account](rise-connection-accounts.md)
+ [Connecting to RISE using a shared AWS Landing Zone](rise-landing-zone.md)

# Amazon VPC peering
<a name="rise-connection-peering"></a>

VPC peering enables network connection between two AWS VPCs using private IPv4 and IPv6 addresses. Instances can communicate over the same network. For more information, see [What is VPC peering?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) 

Before setting up a VPC peering connection, you need to create a request for SAP’s approval. For a successful VPC peering, the defined IPv4 Classless Inter-Domain Routing (CIDR) block must not overlap. Check with SAP for the CIDR ranges that can be used in RISE with SAP VPC.

VPC peering is one-on-one connection between VPCs, and is not transitive. Traffic cannot transit from one VPC to another via an intermediary VPC. You must setup multiple peering connections to establish direct communication between RISE with SAP VPC and multiple VPCs.

VPC peering works across AWS Regions. All inter-Region traffic is encrypted with no single point of failure or bandwidth bottleneck. Traffic stays on AWS Global Network and never traverses the public internet, reducing threats of common exploits and DDoS attacks.

![\[VPC peering connections between multiple accounts in multiple Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-peering.jpg)


Data transfer for VPC peering within an Availability Zone is free, and for across Availability Zones is charged per-GB for "data in" to and "data out". Data transfer for VPC peering for across regions is charged for "out" per-GB. For more information, see [Amazon EC2 pricing](https://aws.amazon.com/ec2/pricing/on-demand/). In your AWS account, use the Availability Zone ID of AWS account managed by SAP to avoid cross-Availability Zone data transfer charges. You can ask for the Availability Zone ID from SAP. For more information, see [Availability Zone IDs for your AWS resources](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html).


|  | 
| --- |
|   **Pricing example - VPC peering across Availability Zones**  ![\[VPC peering across Availability Zones\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-peering-pricing.png) 100GB of data sent from the AWS account – managed by SAP via VPC Peering toward the AWS account – managed by Customer across AZs: 100GB \$1 \$10.01per-GB = \$11 (out - billed to AWS account – managed by SAP) and 100GB \$1 \$10.01per-GB = \$11 (IN - billed to AWS account – managed by Customer) As the cost for data transfer is included In the RISE subscription, the AWS account – managed by Customer will only incur the cost for traffic IN e.g. \$10.01 per-GB.  *[note: the cost example also applies when Sender is AWS account – managed by Customer and Receiver is AWS account – managed by SAP]*   | 
|   **Pricing example - VPC peering across Regions**   *[note: cost between AWS Regions vary. For more information see: [Amazon EC2 pricing Data Transfer](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)]*  ![\[VPC peering across Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-peering-across-regions-pricing.png) 1). 100GB of data sent from the AWS account – managed by SAP via VPC Peering toward the AWS account – managed by Customer across Regions. 100GB \$1 (\$10.01-\$10.138per-GB) = \$11-\$113.8 (out - billed to AWS account – managed by SAP) As the cost for data transfer is included In the RISE subscription the AWS account – managed by Customer will not incur cost for this example. 2). 100GB of data sent from the AWS account – managed by Customer via VPC Peering toward the AWS account – managed by SAP across Regions. 100GB \$1 (\$10.01-\$10.138per-GB) = \$11-\$113.8 (out - billed to AWS account – managed by Customer) As the cost for data transfer is calculated for "data out" the AWS account – managed by Customer will incur the cost for this example.  | 

# AWS Transit Gateway
<a name="rise-connection-transit"></a>

 AWS Transit Gateway is a network transit hub to interconnect Amazon VPCs. It acts as a cloud router, resolving complex peering setup issues by acting as the central communication hub. You need to establish this connection with AWS account managed by SAP only once.

 **Transit Gateway in your own AWS account** 

To establish connection with AWS account managed by SAP, create and share AWS Transit Gateway via AWS Resource Access Manager (RAM) in your AWS account. SAP then creates an attachment to enable traffic flow through an entry in route table. As AWS Transit Gateway resides in your AWS account, you can retain control over traffic routing. For more information, see [Transit gateway peering attachments](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html).

![\[Connections between multiple accounts in multiple Regions using Transit Gateway\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-transit-1.png)


 **Transit Gateway in AWS account managed by SAP** 

When you already have an Transit Gateway in another AWS Region, and cannot create another AWS account with Transit Gateway in the Region that has RISE with SAP account, then SAP can provide the Transit Gateway in the RISE with SAP account that will be managed by SAP. You can enable communication between your Transit Gateway and SAP managed Transit Gateway through Transit Gateway Peering. You cannot connect VPC attachments of VPCs outside of the RISE environment to the SAP-managed Transit Gateway.

For peering attachments, each Transit Gateway owner is billed hourly for the peering attachment with the other Transit Gateway, thus the hourly cost for the peering attachment of the Transit Gateway in the SAP account - managed by SAP (for the purpose of Inter Region Transit Gateway Peering) is part of the RISE subscription. However the hourly cost for the peering attachment of the Transit Gateway in the Customer account – Customer managed is billed to the Customer. For more information, see: [Transit Gateway pricing](https://aws.amazon.com/transit-gateway/pricing/) 


|  | 
| --- |
|   **Pricing example - Transit Gateway across VPCs in different Regions**   *[note: cost between AWS Regions vary. For more information see: [Amazon EC2 pricing Data Transfer](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)]*  ![\[Transit Gateway across VPCs in different Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-transit-different-regions-pricing.png) 1). 100GB of data sent from a VPC in Region X in the AWS account – managed by SAP via the Transit Gateway that resided in the AWS account – managed by SAP, towards a peered Transit Gateway, in a different Region Y, that resided in the AWS account – managed by Customer ending at a VPC in the AWS account – managed by Customer: 100GB \$1 \$10.02per-GB = \$12 (Transit Gateway data processing) \$1 100GB \$1 (\$10.01-\$10.138per-GB) = \$11-\$113.8 (Region out) = \$13-\$115.8 (Total - billed to AWS account – managed by SAP) Data processing is charged to the VPC owner who sends the traffic to Transit Gateway. As the sending VPC is residing in the AWS account – managed by SAP and the cost for data transfer is included in the RISE Subscription, thus the AWS account – managed by Customer will not incur data transfer cost for this example. As data processing charges do not apply for data sent from a peering attachment to a Transit Gateway and inbound inter-Region data transfer charges are free, no further Data Transfer charges apply to the AWS account – managed by Customer. The AWS account – managed by Customer will only be billed for the price per Transit Gateway peering attachment per hour. Data out of an AZ will always go via Transit Gateway endpoint in that AZ to reach other VPC, so there is no cross AZ Data Transfer costs. 2). 100GB of data sent from a VPC in region Y in the AWS account – managed by Customer via the Transit Gateway that resided in the AWS account – managed by Customer, towards a peered Transit Gateway, in a different region X, that resided in the AWS account – managed by SAP ending at a VPC in the AWS account – managed by SAP: 100GB \$1 \$10.02per-GB = \$12 (Transit Gateway data processing) \$1 100GB \$1 (\$10.01-\$10.138per-GB) = \$11-\$113.8 (Region out) = \$13-\$115.8 (Total - billed to AWS account – managed by Customer) Data processing is charged to the VPC owner who sends the traffic to Transit Gateway. As the sending VPC is residing in the AWS account – managed by Customer all data transfer cost for this example are billed to the AWS account – managed by Customer. In addition, the AWS account – managed by Customer will be billed for the price per Transit Gateway peering attachment per hour.  | 

# AWS Direct Connect gateway
<a name="rise-connection-direct-connect-gateway"></a>

 [AWS Direct Connect gateway](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) is a global service that enables you to establish private connectivity between your on-premises networks and multiple Amazon VPCs across different AWS regions. This centralized connection hub allows you to consolidate your network architecture, reduce complexity, and maintain secure, high-bandwidth connections while avoiding public internet for your mission-critical workloads.

 ** AWS Direct Connect gateway in your own AWS account** 

To establish connection with AWS account managed by SAP, create AWS Direct Connect gateway that routes traffic from Private VIF to VPC Private Gateway. As AWS Direct Connect gateway resides in your AWS account, you can retain control over traffic routing.

![\[Direct Connect gateway in your own account\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-direct-connect-gateway.png)


When you have a requirement for connectivity from multiple on-premises sites and/or are using multiple AWS regions for RISE with SAP (i.e. for long range DR), you can simplify the connectivity utilizing Direct Connect Gateway

![\[Direct Connect gateway in your own account with Multi Region\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-direct-connect-gateway-multi-regions.png)


 ** AWS Direct Connect gateway in AWS account managed by SAP** 

If you do not have any requirement to own and manage an AWS account, you can request for SAP to provide the AWS Direct Connect gateway that is part of AWS Account which is managed by SAP.

![\[Direct Connect gateway in your own account with Multi Region\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-direct-connect-gateway-sap-provided.png)


There is no additional charges for AWS Direct Connect gateway itself. You can find out more from the [AWS Direct Connect FAQs](https://aws.amazon.com/directconnect/faqs/#Direct_Connect_Gateway).

# AWS Cloud WAN
<a name="rise-connection-cloud-wan"></a>

 [AWS Cloud WAN](https://aws.amazon.com/cloud-wan/) is a managed wide-area networking (WAN) service designed to simplify the process of building, managing, and monitoring unified global networks that connect cloud and on-premises resources. It enables organizations to centrally connect data centers, branch offices, remote sites, and Amazon Virtual Private Clouds (VPCs) across the AWS global backbone, using a centralized dashboard and policy-driven automation. For more information, see [AWS Cloud WAN documentation](https://docs.aws.amazon.com/network-manager/latest/cloudwan/what-is-cloudwan.html).

 **Connecting to RISE from on-premises using AWS Cloud WAN in your AWS account** 

To establish a connection with RISE Environment (AWS account managed by SAP), create and share AWS Cloud WAN via AWS Resource Access Manager (RAM) in your AWS account. Afterwards, SAP will accept the shared Cloud WAN and create an VPC attachment to enable traffic flow through an entry in route table. As AWS Cloud WAN resides in your AWS account, you can retain control over traffic routing.

Here is high level step-by-step guide to create Cloud WAN global:

1. In AWS Network Manager, create a global network and associated core network.

1. Create a Core Network Policy (CNP) that defines segments, Autonomous System Number (ASN) range, AWS Regions and tags to be used to attach to segments.

1. Apply the network policy.

1. Share the core network using the resource access manager with SAP ECS that manages RISE with SAP Account.

1. Create and tag attachments.

1. Update routes in your attached VPCs to include the core network.

You can find out more details from these documentations:
+  [Quick start: Create an AWS Cloud WAN global network and core network](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-getting-started.html) 
+  [Configure the core network settings in an AWS Cloud WAN policy version](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-core-network-config.html) 
+  [Building a Scalable and Secure Multi VPC AWS Network Infrastructure – Cloud WAN](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/aws-cloud-wan.html) 

![\[Cloud WAN\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-cloudwan-01.jpg)


1.  **Attaching AWS Site-to-Site VPN (S2S VPN) to AWS Cloud WAN** – Create a Site-to-Site VPN connection with Target Gateway Type set to Not Associated. You can create an AWS S2S VPN attachment for AWS Cloud WAN under Site-to-Site VPN connections from the Amazon VPC console. Once the AWS S2S VPN is created, you can [attach it to AWS Cloud WAN core network](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-vpn-attachment-add.html). For more information, see [How Site-to-Site VPN connection can be created for AWS Cloud WAN](https://docs.aws.amazon.com/vpn/latest/s2svpn/create-cwan-vpn-attachment.html).

1.  **Attaching AWS Direct Connect gateway with AWS Cloud WAN** – Create a Direct Connect gateway with a transit virtual interface and attach Cloud WAN to Direct Connect gateway which exist in your AWS Account. For more information, see [AWS Cloud WAN attachment to a Direct Connect gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-global-hybrid-connectivity-with-aws-cloud-wan-and-aws-direct-connect-integration/). For detailed steps to create the transit virtual interface for Direct Connect Gateway, you can refer to AWS documentation - [Create a transit virtual interface to the AWS Direct Connect gateway](https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-transit-vif-dx.html).

You can estimate the costs of deploying AWS Cloud WAN from the [pricing documentation](https://aws.amazon.com/cloud-wan/pricing/). Below are pricing examples for you to consider.

 **Scenario A. AWS Cloud WAN connecting two VPCs in same Region** 

![\[Cloud WAN connecting two VPCs in same Region\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-cloudwan-02.jpg)



|  | 
| --- |
|   **Pricing example – AWS Cloud WAN connecting two VPCs in same Regions**   *[note: cost between AWS Regions vary. For more information see: [Amazon EC2 pricing Data Transfer](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)]*  100GB of data sent from a VPC in Region X in the AWS account – managed by SAP via Cloud WAN that resides in the AWS account – managed by customer ending at a VPC managed by customer. 100GB \$1 \$10.02 per-GB = \$12 (Cloud WAN data processing) (Billed to AWS account – managed by SAP) Apart from data processing there would be VPC attachment cost to AWS account – managed by SAP. [Cloud WAN pricing](https://aws.amazon.com/cloud-wan/pricing/) would vary depending upon region where SAP VPC is attached to Cloud WAN. For example, SAP VPC is in Region US East (N. Virginia). You pay \$10.065 per hour for VPC attachments in the US East (N. Virginia) Region. \$10.065 \$1 730 = \$147.45 (Monthly fixed cost billed to AWS account , managed by SAP) Hence the total cost = \$149.45 Data processing and VPC Attachment costs are charged to the VPC owner who sends the traffic to AWS Cloud WAN. As the sending VPC is residing in the AWS account – managed by SAP and the cost for data transfer is included in the RISE subscription, thus the AWS account – managed by Customer will not incur data transfer and attachment cost for this example. The AWS account - managed by customer will only be billed for the price Cloud WAN per VPC attachment per hour. Data out of an AZ will always go via Cloud WAN endpoint in that AZ to reach other VPC, so there is no cross AZ Data Transfer costs.  | 

 **Scenario B. AWS Cloud WAN connecting two VPCs in different Regions** 

![\[Cloud WAN connecting two VPCs in different Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-cloudwan-03.jpg)



|  | 
| --- |
|   **Pricing example – AWS Cloud WAN connecting two VPCs in different Regions**   *[note: cost between AWS Regions vary. For more information see: [Amazon EC2 pricing Data Transfer](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)]*  100GB of data sent from a VPC in region Y in the AWS account - managed by Customer via AWS Cloud WAN to AWS Account - managed by SAP in different region X. 100GB \$1 \$10.02 per-GB = \$12 (Cloud WAN data processing) \$1 100GB \$1 (\$10.01 - \$10.138 per-GB) = \$11 - \$113.8 (Region out) = \$13 - \$115.8 (Total - billed to AWS account – managed by Customer) Data processing is charged to the VPC owner who sends the traffic to Cloud WAN. As the sending VPC is residing in the AWS account – managed by customer all data transfer costs for this example are billed to the AWS account – managed by Customer. In addition, the AWS account – managed by Customer will be billed for the price per VPC attachment per hour in region Y. VPC attachment charges in Region X would be charged to AWS account – managed by SAP and the charges are included in the RISE subscription.  | 

# Connecting to RISE using your single AWS account
<a name="rise-connection-accounts"></a>

You can establish connectivity between on-premises and RISE with SAP VPC using your AWS account. This method provides you with more control but also requires managing AWS services in your AWS account. You can use any one of the following options.
+  AWS Transit Gateway – Share AWS Transit Gateway resource in you AWS account with AWS account managed by SAP.
+  AWS VPN with AWS Transit Gateway – Create an IPsec VPN connection between your remote network and transit gateway over the internet. For more information, see [How AWS Site-to-Site VPN works](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html) and [Transit gateway VPN attachments](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpn-attachments.html).
+ Direct Connect gateway – Create a Direct Connect gateway with a transit virtual interface. For more information, see [Transit gateway attachments to a Direct Connect gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-dcg-attachments.html).

  To strengthen the security, see [How do I establish an AWS VPN over an AWS Direct Connect connection?](https://repost.aws/knowledge-center/create-vpn-direct-connect) 

The following image shows this option within the same AWS Regions.

![\[Example connections in a single Region\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-own.jpg)


The following image shows this option across different AWS Regions.

![\[Example connections across Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-own-regions.jpg)


When you choose AWS Site-to-Site VPN and/or AWS Direct Connect to establish connectivity between on-premises and RISE with SAP VPC using a Transit Gateway in the AWS account - managed by the Customer, either in the same AWS Region or a different AWS Region than the RISE with SAP VPC, the following applies.

 **Hourly cost:** 

As the AWS Site-to-Site VPN is residing in the AWS account – managed by Customer and is attached to the Transit Gateway that resides in the AWS account – managed by Customer, the cost for the VPN connection and the cost for the Transit Gateway attachment are billed to the AWS account – managed by Customer

As the Direct Connect and Direct Connect Gateway is residing in the AWS account – managed by Customer and is attached to the Transit Gateway that resides in the AWS account – managed by Customer the cost for the AWS Direct Connect ports hours and the cost for the Transit Gateway attachment are billed to the AWS account – managed by Customer.

For peering attachments, each Transit Gateway owner is billed hourly for the peering attachment with the other Transit Gateway.

 **Data processing charges:** 

Data processing charges apply for each gigabyte sent from a VPC, Direct Connect or VPN to/via the Transit Gateway.

Depending on the source and destination the data processing charges vary and will be billed to the AWS account – managed by Customer, or are already included in the RISE subscription (For a cost estimation example: see below)

For more information see:
+  [AWS Site-to-Site VPN Pricing](https://aws.amazon.com/vpn/pricing/) 
+  [AWS Direct Connect Pricing](https://aws.amazon.com/directconnect/pricing/) 
+  [Transit Gateway pricing](https://aws.amazon.com/transit-gateway/pricing/) 


|  | 
| --- |
|   **Pricing example – Transit Gateway in VPCs in the same region via VPN or Direct Connect**   *[note: cost between AWS Regions vary. For more information see: [Amazon EC2 pricing Data Transfer](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)]*  ![\[Transit Gateway in VPCs in the same region via VPN or Direct Connect\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-transit-same-regions-via-vpndxc-pricing.png) 1). 200GB of data sent from a VPC in the AWS account – managed by SAP via the Transit Gateway that resided in the AWS account – managed by Customer via a VPN or Direct Connect in the AWS account – managed by SAP towards On-Premises: 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) \$1 100 GB \$1 \$10.09per-GB = \$19 (VPN data transfer out, with the first 100 GB are free, then \$1 0.09 per-GB) = \$113 (Total data transfer out billed to AWS account – managed by SAP) or 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) \$1 200GB \$1 (\$10.02-\$10.19per-GB) = \$14-\$138 (Direct Connect data transfer out) = \$18-\$142 (Total data transfer out billed to AWS account – managed by SAP) Data processing is charged to the VPC owner who sends the traffic to Transit Gateway. As the sending VPC is residing in the AWS account – managed by SAP and the cost for data transfer is included in the RISE Subscription, therefore the AWS account – managed by Customer will not incur Data Transfer cost in this example. 2). 200GB of data sent from On-Premises via a VPN or Direct Connect in the AWS account – managed by Customer via the Transit Gateway that resided in the AWS account – managed by Customer towards VPC in the AWS account – managed by SAP: 200GB \$1 \$10.00per-GB = \$10 (VPN data transfer in) \$1 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) \$1 \$10 (VPN data transfer in) = \$14 (Total data transfer in billed to AWS account – managed by Customer) or 200GB \$1 \$10.00per-GB = \$10 (Direct Connect data transfer in) \$1 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) = \$14 (Total data transfer in billed to AWS account – managed by Customer) Data transfer into AWS is free and this also applies to VPN and Direct Connect therefore the only data processing charge is the data processing of the Transit Gateway. As Transit Gateway resides in the AWS account – managed by Customer the cost for data transfer is billed to the AWS account – managed by Customer  | 
|   **Pricing example – Transit Gateway in VPCs in the different regions via VPN or Direct Connect**   *[note: cost between AWS Regions vary. For more information see: [Amazon EC2 pricing Data Transfer](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)]*  ![\[Transit Gateway in VPCs in the different regions via VPN or Direct Connect\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-transit-different-regions-via-vpndxc-pricing.png) 1). 200GB of data sent from a VPC in the AWS account – managed by SAP via the Transit Gateway that resided in the AWS account – managed by SAP that is peered with an Transit Gateway in a different Region in the AWS account – managed by Customer via a VPN OR Direct Connect in the AWS account – managed by Customer towards On-Premises: 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) \$1 200GB \$1 (\$10.01-\$10.138per-GB) = \$12-\$127.6 (Region out) \$1 100GB \$1 \$10.09per-GB = \$19 (VPN data transfer out, with the first 100 GB are free, then \$1 0.09 per-GB) = \$115-\$140.6 (Total data transfer out billed to AWS account – managed by SAP) or 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) \$1 200GB \$1 (\$10.01-\$10.138per-GB) = \$12-\$127.6 (Region out) \$1 200GB \$1 (\$10.02-\$10.19per-GB) = \$14-\$138 (Direct Connect data transfer out) = \$110-\$169.6 (Total data transfer out billed to AWS account – managed by SAP) Data processing is charged to the VPC owner who sends the traffic to Transit Gateway. As the sending VPC is residing in the AWS account – managed by SAP and the cost for Data Transfer is included in the RISE subscription, therefore the AWS account – managed by Customer will not incur Data Transfer cost in this example. 2). 200GB of data sent from On-Premises via a VPN or Direct Connect in the AWS account – managed by Customer via the Transit Gateway that resided in the AWS account – managed by Customer via a peered Transit Gateway in a different region in the AWS account – managed by SAP towards a VPC in the AWS account – managed by SAP: 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) \$1 200GB \$1 \$10.00per-GB = \$10 (VPN data transfer in) \$1 200GB \$1 (\$10.01-\$10.138per-GB) = \$12-\$127.6 (Region out) = \$16-\$131.6 (Total data transfer in billed to AWS account – managed by Customer) or 200GB \$1 \$10.02per-GB = \$14 (Transit Gateway data processing) \$1 200GB \$1 \$10.00per-GB = \$10 (Direct Connect data transfer in) \$1 200GB \$1 (\$10.01-\$10.138per-GB) = \$12-\$127.6 (Region out) = \$16-\$131.6 (Total data transfer in billed to AWS account – managed by Customer) Data transfer into AWS in is free and this also applies to VPN and Direct Connect therefore the data processing charge is the data processing of the Transit Gateway and the inter-region data transfer charges. As Transit Gateway resides in the AWS account – managed by Customer, the cost for data transfer is billed to the AWS account – managed by Customer.  | 

# Connecting to RISE using a shared AWS Landing Zone
<a name="rise-landing-zone"></a>

Modern SAP landscapes have several connectivity requirements. Services are accessed across on-premises and AWS Cloud as well as across a variety of SaaS solutions and other cloud service providers.

Creating an [AWS Landing Zone](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html) facilitates secure, scalable, and well-architected foundation for RISE with SAP connectivity. It provides the following benefits:
+ Streamlined SAP network integration with standardized architecture
+ Enhanced business continuity through redundant connectivity options
+ Strengthened security posture with layered network controls
+ Centralized management of network resources and policies
+ Ability to reuse [AWS Direct Connect](https://aws.amazon.com/directconnect/) connections across broader AWS solutions
+ Optimized network performance with reduced latency
+ Enhanced governance through AWS native services

A Landing Zone is designed to help organizations achieve their cloud initiatives by automating the set-up of an AWS environment that follows [AWS Well Architected](https://aws.amazon.com/architecture/well-architected/) framework. It provides scalability to cater to all scenarios, from the simplest connectivity, where only RISE with SAP connectivity to on-premises environments is required, to complex requirements with connectivity to multiple SaaS solutions, multiple CSPs and on-premises connectivity.

The key components and benefits of a Landing Zone include:
+  **Multi-account structure** – it sets up an organized hierarchy using [AWS Organizations](https://aws.amazon.com/organizations/) with separate accounts for production, development, and shared services, ensuring clear separation of concerns and improved security boundaries.
+  **Network Architecture** - it establishes a centralized [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) as the network hub with standardized VPC configurations which connects the RISE with SAP account with other AWS accounts. It also supports integration with AWS Direct Connect and [AWS Site-to-Site VPN](https://aws.amazon.com/vpn/site-to-site-vpn/) to connect your on-premises with RISE with SAP account while maintaining network segmentation and security controls.
+  **Security Framework** - it implements comprehensive AWS security services integration with centralized logging and monitoring, including network firewall implementation and identity and access management controls.
+  **Automation and Management** - it uses Infrastructure as Code deployment through [AWS Control Tower](https://aws.amazon.com/controltower/) or [AWS CDK](https://aws.amazon.com/cdk/) and [Landing Zone Accelerator (LZA)](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/) for automated account provisioning, standardized configurations, and consistent policy enforcement across the environment.
+  **Logging and Monitoring** - it configures AWS services including [AWS Config](https://aws.amazon.com/config/), [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), [Amazon GuardDuty](https://aws.amazon.com/guardduty/) for centralized logging, monitoring, and auditing of resource changes and security events.
+  **Security Controls** - it implements AWS security best practices through Config Rules, CloudTrail trails, and Security Hub standards while enabling network firewall capabilities.
+  **Customization Options** - it allows for customization based on specific organizational requirements, including integration with existing infrastructure and addition of AWS services through the Landing Zone Accelerator configuration.

We recommend using an AWS Landing Zone for RISE with SAP connectivity.

 **Choosing Your Implementation Approach** 

 AWS offers two solutions for implementing a Landing Zone for RISE with SAP connectivity, each designed to meet different organizational needs.

 [AWS Control Tower](https://aws.amazon.com/controltower/) provides a streamlined solution through its console-based interface, enabling quick deployment with standardized controls. This approach suits organizations seeking rapid implementation with built-in governance and compliance controls, particularly those starting their cloud journey or requiring straightforward SAP connectivity.

 [Landing Zone Accelerator (LZA)](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/) extends AWS Control Tower’s capabilities through Infrastructure as Code, offering extensive customization and automation. This solution serves enterprises with complex SAP networking requirements, multiple regions, or significant scaling plans. Organizations with established DevOps practices will benefit from LZA’s configuration-driven approach.

Both solutions deliver secure, scalable foundations for RISE with SAP connectivity. Choose Control Tower for rapid deployment and visual management, or LZA for enhanced customization and automation capabilities.

![\[Connecting to RISE with a shared landing zone\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-rise-landing-zone.png)


 **Building an AWS Landing Zone** 

You can implement AWS Landing Zones using AWS Control Tower and the Landing Zone Accelerator, which provides an automated process for building a secure, scalable, multi-account environment, including management and governance services.

For detailed implementation steps or LZA, AWS provides the [Guidance for Building an Enterprise-Ready Network Foundation for RISE with SAP on AWS](https://aws.amazon.com/solutions/guidance/building-an-enterprise-ready-network-foundation-for-rise-with-sap-on-aws/). It includes validated architecture patterns, security configurations, and operational procedures specifically designed for RISE with SAP deployments. In a simple scenario, a Landing Zone contains a minimal footprint focused on network connectivity that is typically centred around AWS Transit Gateway. For more information, see [AWS Landing zone](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/aws-landing-zone.html).

The following is a general overview of the process:

1.  **Define requirement** – understand your organization’s security, compliance, and operational requirements. This will help determine the appropriate guardrails, controls, and services to be included in the Landing Zone. Review AWS Connectivity Questionnaire provided by SAP Enterprise Cloud Services (ECS) team.

1.  **Design architecture** – plan the overall architecture, including the number of accounts (management, shared services, workload accounts), network design (VPCs, subnets, routing), shared services (logging, monitoring, identity management), and security controls (IAM, service control policies, guardrails). For LZA implementations, include planning for [configuration file structure](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/using-configuration-files.html) and customization needs.

1.  **Setup AWS Control Tower** – Control Tower helps in setting up and governing a multi-account AWS environment based on best practices. It allows you to create and provision new AWS accounts and deploy baseline security configurations across those accounts. For LZA implementations, this serves as the foundation for additional customization.

1.  **Deploy Landing Zone Accelerator (Optional)** - If implementing LZA, deploy the installer stack using either AWS CDK or [AWS CloudFormation](https://aws.amazon.com/cloudformation/). Implement standardized configuration files for networking, security, and RISE with SAP connectivity requirements.

1.  **Configure AWS Organizations** - Organizations enables you to centrally manage and govern your AWS accounts. Configure Organizations in Control Tower by creating the necessary organizational units (OUs) and service control policies (SCPs). For LZA implementations, ensure OUs align with [configuration file structure](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/using-configuration-files.html).

1.  **Deploy Core and Shared Services Accounts** - create and configure the core accounts, such as the management account, shared services accounts (for logging, security tooling), and any other required shared accounts. Deploy shared services, such as CloudTrail, Config, and [AWS Security Hub](https://aws.amazon.com/security-hub/) in the shared services account.

1.  **Deploy Network Architecture** - set up the network architecture, including VPCs, subnets, route tables, and Transit Gateway for hub-spoke model. For LZA implementations, configure Direct Connect and/or Site-to-Site VPN through [network configuration files](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/using-configuration-files.html). Include [AWS Network Firewall](https://aws.amazon.com/network-firewall/) setup if required.

1.  **Configure IAM** - establish IAM roles, policies, and groups for controlling access and permissions across the Landing Zone accounts.

1.  **Implement Security Controls** - deploy security services and guardrails, such as Security Hub, [AWS Network Firewall](https://aws.amazon.com/network-firewall/), [AWS GuardDuty](https://aws.amazon.com/guardduty/), and [AWS Config](https://aws.amazon.com/config/) Rules.

1.  **Configure Observability and Monitoring** - set up centralized logging and monitoring solutions, such as [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), and AWS Config.

1.  **Share Transit Gateway Details with SAP** - using AWS connectivity questionnaire. Accept incoming transit gateway association requests and configure routing between RISE with SAP VPC and landing zone. Test connectivity and failover scenarios.

1.  **Deploy Workload Accounts** - deploy workload accounts with your Landing Zone. Create separate AWS accounts for different workload types such as separating development, test and production environments, or Generative AI workloads utilizing Amazon Bedrock, or Data Analytics workloads utilizing Amazon SageMaker.

1.  **Implement Operational Procedures** - establish monitoring, alerting, and backup procedures. Document operational procedures and implement change management processes. Given the complex nature of multi-account environments and the need to maintain consistent security and operational standards across the organization it is advised to set up automated testing and validation.

1.  **Automate and Maintain** - use CloudFormation templates or AWS CDK to automate deployment and maintenance. For LZA implementations, maintain configuration files and regularly update LZA version. Establish processes for ongoing maintenance, updates, and compliance checks. This includes keeping the LZA version up-to-date with latest releases and regular check to ensure compliance with security and compliance standards.

1.  **Manage Costs** - monitor network transfer costs, optimize connectivity paths, and implement cost allocation tags. Regularly review resource utilization and configure budgets and alerts.

Best Practices:
+ Start implementation at least 6-8 weeks before planned go-live
+ Implement redundant connectivity options for high availability
+ Use Landing Zone Accelerator for standardized deployment
+ Follow [AWS Well-Architected framework](https://aws.amazon.com/architecture/well-architected/) guidelines
+ Regularly review and update security controls
+ Maintain documentation and operational procedures
+ LZA implementations can automate most of this setup through [configuration files](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/using-configuration-files.html).

Costs associated to a Customer Managed AWS Landing Zone vary depending on the AWS Services that are used. The AWS Services as described in this paragraph have their own pricing model. For more information on price, see the dedicated pricing pages of the listed AWS Services. See [AWS Pricing Calculator](https://calculator.aws/#/) to configure a cost estimate that fits your business needs.

Regularly review and update the landing zone configuration to ensure it continues to meet evolving business needs and security requirements.

# Connect to nearest Direct Connect POP (including Local Zone)
<a name="rise-local-zone"></a>

 AWS Direct Connect point-of-presence (POP) is a physical cross-connect that allows users to establish a network connection from their own premises to an AWS Region or AWS Local Zone. You can use the nearest Direct Connect POP (for example, in an AWS Local Zone) to benefit from lower setup and running costs, with the same or lower network latency to your RISE with SAP VPC that runs on the parent AWS Region. For more information, see [AWS Direct Connect Traffic Flow with AWS Local Zone](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/direct-connect-traffic-flow-local-zone-ra.pdf).

Here is an example scenario - You are based in Philippines, and you would like to deploy RISE with SAP in AWS Singapore Region. You can use Direct Connect POP in Manila to setup Direct Connect from your on-premises data centre or offices. This strategy provides a lower network latency compared to a connecting directly to the AWS Region in Singapore.

The following diagram displays RISE connectivity through nearest AWS Direct Connect POP.

![\[Connect to RISE through the nearest Direct Connect POP (including Local Zone)\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-rise-direct-connect.png)


The following are some considerations when using AWS Direct Connect POP:
+ Use separate VPCs for Region (RISE with SAP VPC) and Local Zones based non-SAP workloads
+ Use Direct Connect Gateway in AWS Direct Connect POP and Private VIF connectivity
+ Use Direct Connect Gateway in AWS Direct Connect POP and Transit VIF connectivity for Region VPCs (RISE with SAP VPC).This is done because Direct Connect Gateway does not exists in AWS Direct Connect POP, and AWS Transit Gateway exists only in AWS Regions.

If resilience is critical, setup a secondary Direct Connect to the AWS Region running RISE with SAP VPC or use AWS Site-to-Site VPN to the AWS Region connectivity option. These services operate within the parent AWS Region, serving as a failover connectivity option ensuring uninterrupted connectivity in the event of disruptions or failures.

![\[Example connections across Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-rise-direct-connect-2.png)


Cost of data transferred between a Local Zone and an Availability Zone within the same AWS Region, "in" to and "out" from Amazon EC2 in the Local Zone varies. For more information see: [EC2 - On-Demand Pricing - Data Transfer within the same AWS Region](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer_within_the_same_AWS_Region) 

# Decision tree on connectivity to RISE
<a name="rise-decision-tree"></a>

You must establish required connectivity to proceed with RISE with SAP on AWS. The following are a few connectivity patterns described in the preceding sections:
+ direct to RISE VPC, supported with Site-to-Site VPN
+ direct to RISE VPC, supported with Direct Connect
+ connectivity through your AWS account via VPC Peering
+ connectivity through Transit Gateway, supporting multi-account deployments
+ connectivity through SAP-managed Transit Gateway supporting multi-account deployments

You must also consider if you want to connect:
+ directly to an AWS Region where the RISE with SAP VPC is going to be deployed
+ or through AWS Local Zone (nearest AWS Direct Connect POP) to benefit from lower setup and running costs, with the same or lower network latency to connect to your RISE with SAP VPC

The decision tree displayed in the following diagram helps you decide which connectivity is suitable based on your requirements, such as future plan of additional AWS or RISE accounts, dedicated line (security, performance), and bandwidth needs.

![\[Example connections across Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-decision-tree.png)


Note:

1. ECMP requires Transit Gateway for S2S VPN.

1. Direct Connect Gateway is recommended to connect to multiple AWS regions. This simplifies the connectivity setup and avoids TGW peering between AWS regions.

# Other considerations
<a name="other-considerations"></a>

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

**Topics**
+ [SAP BTP with RISE on AWS](rise-btp.md)
+ [Connecting to SaaS from RISE](rise-saas.md)
+ [Connectivity patterns for multi-cloud](rise-multi-cloud.md)
+ [Implement chargeback for connectivity to RISE](rise-chargeback.md)
+ [Connectivity to Overlay IP in RISE on AWS](rise-oip.md)
+ [Integrating DNS to RISE and Route 53](rise-dns.md)

# SAP BTP with RISE on AWS
<a name="rise-btp"></a>

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 instances communicate with a public AWS service endpoint ?](https://aws.amazon.com/vpc/faqs/).

![\[Example connections across Regions\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-btp-internet.png)


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-premises via Amazon VPC?](https://guide.aws.dev/articles/ARUIFmbCauTQeyJogByCa5xg/how-to-route-internet-traffic-from-on-premise-via-aws-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 PrivateLink\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-btp-services.jpg)


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](https://help.sap.com/docs/private-link/private-link1/consume-amazon-web-services-in-sap-btp-beta).

You can establish a secure and private communication between SAP BTP and AWS services with [SAP Private Link Service](https://help.sap.com/docs/private-link/private-link1/what-is-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](https://aws.amazon.com/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](https://help.sap.com/docs/btp/sap-business-technology-platform/regions-and-api-endpoints-available-for-cloud-foundry-environment).

![\[Connecting multiple accounts in multiple Regions using PrivateLink\]](http://docs.aws.amazon.com/sap/latest/general/images/connectivity-btp-regions.jpg)


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](https://discovery-center.cloud.sap/serviceCatalog/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 SaaS from RISE
<a name="rise-saas"></a>

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 instances communicate with a public AWS service endpoint ?](https://aws.amazon.com/vpc/faqs/).

![\[Connecting to cloud solutions or SaaS from RISE\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-saas1.png)


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\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-saas2.png)


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](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html).

# Connectivity patterns for multi-cloud
<a name="rise-multi-cloud"></a>

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\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-multi1.png)


 **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\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-multi2.png)


For more information, see [Designing private network connectivity between AWS and Microsoft Azure](https://aws.amazon.com/blogs/modernizing-with-aws/designing-private-network-connectivity-aws-azure/).

# Implement chargeback for connectivity to RISE
<a name="rise-chargeback"></a>

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](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-flow-logs.html).

![\[How to implement chargeback capability for connectivity to RISE\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-chargeback.png)


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:
+  [Using AWS Transit Gateway Flow Logs to chargeback data processing costs in a multi-account environment](https://aws.amazon.com/blogs/networking-and-content-delivery/using-aws-transit-gateway-flow-logs-to-chargeback-data-processing-costs-in-a-multi-account-environment/) 
+  [How-to chargeback shared services: An AWS Transit Gateway example](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/) 

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](https://docs.aws.amazon.com/vpc/latest/tgw/flow-logs-s3.html#flow-logs-s3-create-flow-log).

1. Setup Cost and Usage Reporting and setup Athena to utilize the reporting. For more information, see [Creating Cost and Usage Reports](https://docs.aws.amazon.com/cur/latest/userguide/cur-create.html) and [Querying Cost and Usage Reports using Amazon Athena](https://docs.aws.amazon.com/cur/latest/userguide/cur-query-athena.html).

1. 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.

   1. Calculate the total network traffic and percentage allocation per account using [AWS Transit Gateway](https://catalog.workshops.aws/cur-query-library/en-US/queries/networking-and-content-delivery#aws-transit-gateway) query.

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

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

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

# Connectivity to Overlay IP in RISE on AWS
<a name="rise-oip"></a>

An Overlay IP is a private IP address assigned to an EC2 instance that is outside the VPC’s CIDR block. It’s used for [high availability and failover scenarios in SAP deployments on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-oip-sap-on-aws-high-availability-setup.html), allowing traffic to be directed to the active instance even if it is in a different Availability Zone. This IP address is routable and managed through routing tables, enabling seamless failover without changing the application’s configuration.

Overlay IP is very important in RISE construct for the following scenarios:
+ SAP GUI connectivity to SAP Message Server which is part of the ASCS instance
+ Application Server connectivity to SAP Enqueue Server which is part of ERS instance
+ Client connectivity to HANA Database when it runs XS and XS Advanced Applications

The Overlay IP is moved by HA Cluster software from primary node to secondary node (or vice versa) when there is an availability issue with primary node or primary availability zone. All the client connectivity must be rerouted when this event occurs so users can continue with their business activities.

There are two ways to connect to this Overlay IP addresses, which is through [Network Load Balancer (NLB)](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-oip-overlay-ip-routing-with-network-load-balancer.html) and [AWS Transit Gateway (TGW)](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-oip-overlay-ip-routing-using-aws-transit-gateway.html). You can refer to more details in this [SAP on AWS High Availability with Overlay IP Address Routing guide](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html).

 **NLB Configuration** 

RISE with SAP High Availability deployment strategy spans across two Availability Zones and involves several key networking components. When setting up this configuration, SAP implements NLBs specifically for two critical Overlay IPs, one for the database and another for ASCS. To manage DNS resolution, SAP includes CNAMEs within their RISE managed DNS system, which correspond to the Amazon NLB addresses (ending in .amazonaws.com).

When connecting to RISE with SAP VPC through VPC Peering, you can only access the system using Network Load Balancer (NLB) addresses. Direct access through Overlay IP addresses is not available.

 **Transit Gateway Configuration** 

When you are utilizing TGW, SAP’s default setup is to propagate routes only for the VPC CIDR range they’re actively using. This leads to an important requirement for customers to manually configure static routes for the CIDR range used by the Overlay Ips (which is outside of the VPC CIDR range). This additional configuration is crucial because it enables direct access to these Overlay IPs through the TGW. Without this static route configuration, traffic would be forced to take a less efficient path through the Network Load Balancer rather than going directly via TGW.

This routing configuration is a critical detail that customers should keep in mind during their SAP deployment, as it can significantly impact the efficiency of their network traffic flow from end-users and other external systems outside of RISE with SAP.

![\[Overlay IP in RISE\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-oip.png)


# Integrating DNS to RISE and Route 53
<a name="rise-dns"></a>

This documentation offers guidance on Domain Name System (DNS) integration options for “RISE with SAP” deployments on AWS, focusing on enterprise scenarios where customers want to enable name resolution between RISE with SAP workloads and their existing workloads across AWS and external environments.

A bi-directional DNS integration is essential for connecting RISE with SAP systems to various AWS cloud and on-premises resources and enterprise infrastructure. In manufacturing environments, a common use case involves connecting SAP applications to shop floor equipment. For example, SAP might need to communicate with printers located on the production floor to generate labels, work orders, or shipping documents. This requires the ability to resolve internal hostnames like “printer-line1.factory.company.local” within the RISE with SAP environment.

Conversely, external systems and applications usually require a DNS lookup to access resources in the RISE with SAP environment, particularly when calling ODATA API endpoints to execute business transactions such as generating a work orders. Integration scenarios between RISE with SAP systems and existing enterprise systems typically require internal network connectivity due to compliance and security requirements. This is particularly true for RISE with SAP deployments, which is why the following sections focus on DNS resolution within private networks.

Integration scenarios between RISE with SAP systems and existing enterprise systems typically require internal network connectivity due to compliance and security requirements. This is particularly true for RISE with SAP deployments, which is why the following sections focus on DNS resolution within private networks.

 **Architectural options** 

When integrating RISE with SAP with your existing DNS setup, you have two primary architectural options, which is Conditional DNS Forwarding and DNS Zone Transfer. You also have to consider DNS Zone Delegation aspect. These options and considerations are designed for AWS-only deployments and hybrid scenarios where AWS connects with external environments (e.g. on-premises or another cloud provider).

The selection of a DNS integration architecture depends on your service reliability needs, existing DNS infrastructure capabilities, and acceptable operational complexity level, with managed services generally demanding less maintenance and expertise than self-operated DNS infrastructure.

For DNS integration with RISE with SAP, we recommend implementing conditional DNS forwarding with [Amazon Route 53](https://aws.amazon.com/route53/) resolver endpoints. Route 53 provides a highly available, scalable DNS service that minimizes operational overhead. This approach eliminates the need to setup and operate your own DNS servers, further reducing operational complexity. Furthermore, Route 53 offers straightforward integration with your existing environments and monitoring capabilities through Amazon CloudWatch. However, if you have specific requirements or technical limitations, you can refer to alternative approaches detailed in subsequent sections.

The recommended DNS segregation pattern is to implement dedicated subdomains for each environment (e.g., aws.corp.com, dc.corp.com, and sap.corp.com), keeping DNS resolution local to each environment with conditional cross-environment forwarding. This approach optimizes performance by keeping local DNS requests within their respective environments, reducing latency, and improving system resilience while simplifying DNS management. It’s particularly effective in reducing the impact of network link failures between environments.

 **Common Infrastructure Requirements** 

Before implementing DNS integration approach, ensure the following prerequisites are in place (see also subsequent diagrams):

1. Network Connectivity: AWS Transit Gateway (or Cloud WAN or VPC Peering) connecting external environments through AWS Direct Connect or AWS Site-to-Site VPN, your AWS environment, and the RISE with SAP VPC.

1. Domain Delegation: During RISE with SAP setup, SAP requires delegation of a sub-domain (sap.<customer>.<domain>) to RISE DNS servers in the RISE with SAP VPC. This enables end users and applications to access RISE with SAP systems through your organization’s domain.

 **Conditional DNS Forwarding (recommended approach)** 

Conditional DNS Forwarding allows for selectively forwarding queries for specific domain names to another DNS server for resolution (e.g. Amazon Route 53 forwards DNS queries of sap.corp.com to RISE DNS Servers). We recommend implementing conditional DNS forwarding, unless technical constraints prevent this approach. The primary advantage of this approach is that customers can leverage Route 53 instead of setting up and operating own DNS infrastructure on AWS. This results in a simplified integration path while benefiting from Route 53 highly available and reliable global infrastructure.

The reference architecture below outlines the components needed for this approach:

![\[DNS Forwarding in RISE\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-dns-forwarding.png)


1. Network Connectivity: refer to Common Infrastructure Requirements

1. Domain Delegation: refer to Common Infrastructure Requirements

1. Create Route 53 resolver endpoints (Inbound and Outbound) in your central Networking VPC to handle DNS queries between your AWS accounts and RISE with SAP account. Please follow [the best practices for operating Resolver endpoints](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver.html). We recommend deploying multiple endpoints across all availability zones and monitoring their utilization in CloudWatch to allow for proactive scaling. Provide SAP with details of your on-premises DNS server and the IP addresses of your Route 53 Resolver endpoints (needed for forwarding and firewall configuration).

1. Configure the Route 53 Resolver rules in your workload VPCs to forward DNS queries as follows:

   1. SAP-bound DNS queries: Forward to Outbound endpoint to resolve queries through SAP DNS servers

   1. Corporate data center-bound DNS queries: Forward to Outbound endpoint to resolve queries through on-premises DNS servers

1. Configure your on-premises DNS server to forward DNS queries as follows:

   1. SAP-bound queries: Forward to the SAP DNS server (alternatively, zone transfer of sap.<customer>.<domain> from SAP DNS server)

   1.  AWS-bound queries: Forward to the Inbound endpoint

1. SAP DNS servers are configured as follows:

   1. Corporate data center-bound DNS queries: Forward to on-premises DNS server

   1.  AWS-bound DNS queries: Forward to the Inbound endpoint

Ensure your Workload VPCs have all relevant resolver rules associated with them for DNS forwarding through your central Networking VPC. We recommend using Route 53 Profiles to manage these configurations, as they enable consistent DNS settings across multiple VPCs and AWS accounts. This approach simplifies DNS management by allowing you to define and apply standardized DNS configurations throughout your AWS infrastructure.

Please note that for DNS resolution in hybrid environments, DNS delegation can be an alternative approach to conditional forwarding. While conditional forwarding is generally recommended for RISE with SAP environments, DNS delegation might be beneficial in specific scenarios, particularly in environments with many distributed DNS resolvers without a centralized upstream resolver. However, for scenarios involving SAP DNS servers, additional technical considerations apply as outlined in the DNS Zone Delegation section.

 **DNS Zone Transfer** 

With zone transfers, the DNS database of an authoritative DNS server is replicated across a set of secondary DNS servers. You can implement zone transfers directly between your on-premises DNS servers and the SAP DNS servers in your RISE environment. However, if you want to extend zone transfers to include your AWS DNS namespace (e.g., aws.<customer>.<domain>) for communication between on-premises and your Workload VPCs, you’ll need to operate your own DNS servers (such as BIND) in your AWS environment. This is because Route 53 doesn’t support zone transfers. Keep in mind that this approach increases operational complexity compared to using Route 53 with DNS forwarding.

Please consult your SAP Cloud Architect or your AWS Account Team for details on this approach. For best practices regarding running your own BIND DNS server, please refer to [this link](https://kb.isc.org/docs/bind-best-practices-authoritative).

The following diagram shows a reference architecture for integrating the RISE environment with your existing DNS landscape ( on-premises / AWS ) through zone transfers.

![\[DNS Zone Transfer in RISE\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-dns-zonetransfer.png)


1. Network Connectivity: refer to Common Infrastructure Requirements

1. Domain Delegation: refer to Common Infrastructure Requirements

1. Setup a central DNS server in your Networking VPC (e.g. BIND on EC2) or decentralized in each Workload VPC by [modifying VPC DHCP options sets accordingly](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html). Please provide SAP with the details of your on-premises DNS Server and the AWS-hosted DNS servers (needed for zone transfer and firewall configuration).

1. Configure your AWS-hosted DNS server as follows:

   1. SAP-bound queries: Zone transfer of sap.<customer>.<domain> from SAP DNS server

   1. Data center-bound queries: Zone transfer of dc.<customer>.<domain> from on-premises DNS server

1. Configure the on-premises DNS server as follows:

   1. SAP-bound DNS queries: Zone transfer of sap.<customer>.<domain> from SAP DNS server

   1.  AWS-bound DNS queries: Zone transfer of aws.<customer>.<domain> from AWS-hosed DNS server

1. SAP DNS servers are configured as follows:

   1. Customer data center-bound DNS queries: Zone transfer of dc.<customer>.<domain> from on-premises DNS server

   1.  AWS-bound DNS queries: Zone transfer of aws.<customer>.<domain> from AWS-hosed DNS server

 **DNS Zone Delegation** 

For customers operating many DNS resolvers distributed across multiple environments without a centralized DNS resolver service, configuring and maintaining DNS forwarding rules or zone transfers can become operationally challenging. DNS zone delegation allows you to define authority for specific subdomains at a single point in the DNS hierarchy, simplifying DNS management across your infrastructure.

Using Amazon Route 53 Resolver endpoints with DNS delegation enables you to build and maintain a unified private DNS namespace spanning on-premises and AWS environments.

However, zone delegation with SAP DNS servers in RISE environments comes with specific technical considerations. Without a centralized upstream resolver, zone delegation to SAP DNS servers increases concurrent query load due to reduced cache efficiency. Additionally, all DNS resolvers require direct network paths to SAP DNS servers, potentially requiring additional connectivity configurations. Please consult with SAP ECS before implementing this approach.

There are 2 main scenarios:

 **Scenario 1. Parent domain in Route 53 on AWS ** 

For customers who run the majority of their workloads in the cloud and operate their private DNS root zone on AWS with Route 53, you can delegate subdomains to external DNS servers. This includes delegating to both SAP DNS servers (e.g., sap.corp.com) and on-premises DNS servers (e.g., dc.corp.com).

![\[DNS Zone Delegation with parent domain in route 53\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-dns-zonedelegation01.png)


1. Network Connectivity: refer to Common Infrastructure Requirements

1. Domain Delegation: refer to Common Infrastructure Requirements

1. Set up Route 53 Resolver endpoints (Inbound and Outbound) in your central Networking VPC

1. Configure the IPs of your on-premises and SAP DNS servers as NS records in the Private Hosted Zone (PHZ) of your parent domain (e.g. corp.com) and associate the PHZ with your Workload VPCs ([Route 53 Profiles](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) can help with the management of PHZ associations and resolver rules). If your DNS servers are part of the same domain (e.g. ns.dc.corp.com), you also need to configure [glue records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-name-servers-glue-records.html) in the parent domain. Create Route 53 Resolver delegation rules for the relevant subdomains (dc.corp.com) and associate them with your Workload VPCs (see diagram above).

1. Configure conditional DNS forwarding at your on-premises resolvers to allow for resolution of the parent domain and SAP domain (SAP will need to do the same on their side)

 **Scenario 2. Parent domain on-premises** 

For customers who are in the beginning of their cloud journey and still maintain their root zone on-premises, DNS delegation provides an efficient way to integrate both SAP and AWS environments while maintaining DNS control on-premises.

![\[DNS Zone Delegation with parent domain in on-premises\]](http://docs.aws.amazon.com/sap/latest/general/images/rise-dns-zonedelegation02.png)


1. Network Connectivity: refer to Common Infrastructure Requirements

1. Domain Delegation: refer to Common Infrastructure Requirements

1. Set up Route 53 Resolver endpoints (inbound and outbound) in your central Networking VPC

1. Configure a PHZ for aws.corp.com and associate it your central Networking and Workload VPCs. Configure conditional DNS forwarding rules to allow your VPC to resolve queries for workloads on-premises and your RISE with SAP systems (SAP will need to do the same on their side).

1. Update the corp.com zone with delegation (NS) records for sap.corp.com and aws.corp.com (for example ns1.corp.com) in your domain’s authoritative nameserver on-premises.

Configure IPs of your AWS Route 53 Resolver inbound endpoint and SAP DNS servers as target records in your ns1.corp.com zone file. If your DNS servers are part of the same domain, you also need to configure glue records in the parent domain.

Please consult the Route 53 documentation for more details on the zone delegation feature. The following blog post provides you with a more in-depth step-by-step guide on how to make use of Route 53 delegation feature for private DNS: [Streamline hybrid DNS management using Amazon Route 53 Resolver endpoints delegation](https://aws.amazon.com/blogs/networking-and-content-delivery/streamline-hybrid-dns-management-using-amazon-route-53-resolver-endpoints-delegation/).

For more information on the above described integration approaches, please reach out to your SAP Cloud Architect or your AWS Account Team.