# Other considerations This sections provides information about other considerations when connecting to RISE. **Topics** + [ # SAP BTP with RISE on Amazon ](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 Amazon ](rise-oip.md) + [ # Integrating DNS to RISE and Route 53 ](rise-dns.md) # SAP BTP with RISE on Amazon You can use SAP Business Technology Platform BTP services on Amazon 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 Amazon (in the same Amazon region or different Amazon regions), the network traffic is encrypted and contained within Amazon 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 Amazon service endpoint ?](https://www.amazonaws.cn/vpc/faqs/). ![\[Example connections across Regions\]](http://docs.amazonaws.cn/en_us/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 Amazon. SAP Private Link connects SAP BTP on Amazon with a secure connection without using public IPs in your Amazon account. ![\[Connecting multiple accounts using PrivateLink\]](http://docs.amazonaws.cn/en_us/sap/latest/general/images/connectivity-btp-services.jpg) You can connect to an Amazon endpoint service from an SAP BTP application running on Cloud Foundry. By establishing this connection, you can directly connect to Amazon services, or for example, to an S/4HANA system. For a complete list of supported Amazon 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 Amazon 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 Amazon global network. For more information, see [Amazon VPC FAQs](https://www.amazonaws.cn/vpc/faqs/). SAP Private Link for Amazon currently supports connections initiated from SAP BTP Cloud Foundry to Amazon. For Amazon services across Amazon Regions, you can create a VPC in the same Amazon Region as your SAP BTP Cloud Foundry Runtime, and connect these VPCs via VPC peering or Amazon 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.amazonaws.cn/en_us/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 Amazon Services in the Amazon account - managed by the Customer to facilitate cross region connectivity for example the Amazon Network Load Balancer, or Transit Gateway vary. For more information on price, see the dedicated pricing pages of the listed Amazon Services. # Connecting to SaaS from RISE When modernizing the SAP landscape, you may subscribe to several SAP cloud solutions or SaaS from independent software vendors to complement RISE with SAP solution. When the cloud solutions are running on Amazon (in the same Amazon region or different Amazon regions), the connectivity from RISE with SAP is kept within the Amazon 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 Amazon service endpoint ?](https://www.amazonaws.cn/vpc/faqs/). ![\[Connecting to cloud solutions or SaaS from RISE\]](http://docs.amazonaws.cn/en_us/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.amazonaws.cn/en_us/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.amazonaws.cn/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html). # Connectivity patterns for multi-cloud In a complex connectivity scenario, you may need to integrate RISE with SAP setup with on-premises, Amazon-hosted systems, and a variety of SaaS solutions and other cloud service providers. Managing connectivity directly from the Amazon 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.amazonaws.cn/en_us/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 Amazon services, such as Elastic Load Balancers and Amazon Shield + monitor endpoints using Amazon CloudWatch + ensure that traffic between two public IP addresses hosted on Amazon is routed over the Amazon 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 Amazon Direct Connect in a managed infrastructure (use Azure ExpressRoute for Azure and Google Dedicated Interconnect for Google Cloud Platform) + private interconnect using an Amazon 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.amazonaws.cn/en_us/sap/latest/general/images/rise-multi2.png) For more information, see [Designing private network connectivity between Amazon and Microsoft Azure](https://www.amazonaws.cn/blogs/modernizing-with-aws/designing-private-network-connectivity-aws-azure/). # Implement chargeback for connectivity to RISE If you are a company with subsidiaries, you may have different RISE contracts, leading to deployments in separate Amazon 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.amazonaws.cn/vpc/latest/tgw/tgw-flow-logs.html). ![\[How to implement chargeback capability for connectivity to RISE\]](http://docs.amazonaws.cn/en_us/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 Amazon Transit Gateway Flow Logs to chargeback data processing costs in a multi-account environment](https://www.amazonaws.cn/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 Amazon Transit Gateway example](https://www.amazonaws.cn/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.amazonaws.cn/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.amazonaws.cn/cur/latest/userguide/cur-create.html) and [Querying Cost and Usage Reports using Amazon Athena](https://docs.amazonaws.cn/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 [Amazon 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 Amazon 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 Amazon](https://docs.amazonaws.cn/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.amazonaws.cn/sap/latest/sap-hana/sap-oip-overlay-ip-routing-with-network-load-balancer.html) and [Amazon Transit Gateway (TGW)](https://docs.amazonaws.cn/sap/latest/sap-hana/sap-oip-overlay-ip-routing-using-aws-transit-gateway.html). You can refer to more details in this [SAP on Amazon High Availability with Overlay IP Address Routing guide](https://docs.amazonaws.cn/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.amazonaws.cn/en_us/sap/latest/general/images/rise-oip.png) # Integrating DNS to RISE and Route 53 This documentation offers guidance on Domain Name System (DNS) integration options for “RISE with SAP” deployments on Amazon, focusing on enterprise scenarios where customers want to enable name resolution between RISE with SAP workloads and their existing workloads across Amazon and external environments. A bi-directional DNS integration is essential for connecting RISE with SAP systems to various Amazon 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 Amazon-only deployments and hybrid scenarios where Amazon 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://www.amazonaws.cn/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: Amazon Transit Gateway (or Cloud WAN or VPC Peering) connecting external environments through Amazon Direct Connect or Amazon Site-to-Site VPN, your Amazon environment, and the RISE with SAP VPC. 1. Domain Delegation: During RISE with SAP setup, SAP requires delegation of a sub-domain (sap..) 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 Amazon. 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.amazonaws.cn/en_us/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 Amazon accounts and RISE with SAP account. Please follow [the best practices for operating Resolver endpoints](https://docs.amazonaws.cn/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.. from SAP DNS server) 1. Amazon-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. Amazon-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 Amazon accounts. This approach simplifies DNS management by allowing you to define and apply standardized DNS configurations throughout your Amazon 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 Amazon DNS namespace (e.g., aws..) for communication between on-premises and your Workload VPCs, you’ll need to operate your own DNS servers (such as BIND) in your Amazon 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 Amazon 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 / Amazon ) through zone transfers. ![\[DNS Zone Transfer in RISE\]](http://docs.amazonaws.cn/en_us/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.amazonaws.cn/vpc/latest/userguide/VPC_DHCP_Options.html). Please provide SAP with the details of your on-premises DNS Server and the Amazon-hosted DNS servers (needed for zone transfer and firewall configuration). 1. Configure your Amazon-hosted DNS server as follows: 1. SAP-bound queries: Zone transfer of sap.. from SAP DNS server 1. Data center-bound queries: Zone transfer of dc.. from on-premises DNS server 1. Configure the on-premises DNS server as follows: 1. SAP-bound DNS queries: Zone transfer of sap.. from SAP DNS server 1. Amazon-bound DNS queries: Zone transfer of aws.. from Amazon-hosed DNS server 1. SAP DNS servers are configured as follows: 1. Customer data center-bound DNS queries: Zone transfer of dc.. from on-premises DNS server 1. Amazon-bound DNS queries: Zone transfer of aws.. from Amazon-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 Amazon 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 Amazon ** For customers who run the majority of their workloads in the cloud and operate their private DNS root zone on Amazon 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.amazonaws.cn/en_us/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.amazonaws.cn/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.amazonaws.cn/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 Amazon environments while maintaining DNS control on-premises. ![\[DNS Zone Delegation with parent domain in on-premises\]](http://docs.amazonaws.cn/en_us/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 Amazon 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://www.amazonaws.cn/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 Amazon Account Team.