Private, resilient links to RISE with SAP, SAP BTP and the rest of your estate.
We design and build the network between your offices, data centres, cloud accounts, the SAP managed RISE with SAP environment and SAP Business Technology Platform. You get private connectivity sized for go-live and daily use, clear routing and DNS, and firewall rules agreed with SAP.
Why connectivity decides how RISE with SAP feels
Under RISE with SAP, SAP runs your SAP Cloud ERP Private systems in its own managed network on AWS, Microsoft Azure or Google Cloud. Your users, interfaces, printers, file transfers and BTP applications all reach that network through links you own. If those links are undersized, single-path or routed over the internet without a plan, users see slow Fiori and SAP GUI sessions, migration data loads overrun, and interfaces fail at the worst time. From Sri Lanka there is no local hyperscaler region, so traffic travels to a region such as Mumbai, Hyderabad or Singapore, and the path matters.
SAP sets its side, you own yours
SAP must approve peering and configure the RISE side. Your hub network, on-premises routing, gateways and firewalls are yours to design and run.
Bandwidth for migration and go-live
Data migration and replication need far more bandwidth than daily use. Temporary VPNs built without a plan often have to be rebuilt later.
DNS and IP planning
RISE uses private address ranges and a DNS subdomain delegated to SAP. Overlapping ranges or missed DNS setup block integrations.
BTP is a separate connection
SAP BTP runs outside the RISE network. It needs its own design using SAP Cloud Connector, public endpoints or SAP Private Link service.
What we do
We plan, build and test every link your SAP landscape depends on, and agree the details with SAP and your carriers.
Connectivity design
We choose between peering, transit hubs, VPN and private circuits for each path, based on bandwidth, resilience and security needs. The design covers future regions, accounts and systems, not only go-live.
Private circuits and VPN
We set up AWS Direct Connect, Azure ExpressRoute or Google Cloud Interconnect with your carrier, and IPsec VPN for backup paths or smaller sites. We design for redundant paths and test failover.
Peering to RISE with SAP
We build the hub network that peers with the SAP managed RISE network, through VPC or VNet peering, AWS Transit Gateway, Azure Virtual WAN or a transit VPC on Google Cloud. We handle the peering requests and settings with SAP.
IP addressing and DNS
We plan non-overlapping address ranges and set up DNS so your systems resolve RISE host names, including the zone delegated to SAP. This avoids rework when new systems are added.
SAP BTP connectivity
We install and configure SAP Cloud Connector, set up destinations, and use SAP Private Link service where BTP applications need private access to services in your own cloud account. Each integration gets the right path.
Firewalls and segmentation
We define the ports and protocols SAP needs, such as RFC, HTTPS and HANA SQL, and apply them on your firewalls and security groups. Rules are documented and match what SAP sets on its side.
How it works
- 1
Discover
We map users, sites, interfaces, data volumes and the SAP systems in scope, and confirm which hyperscaler and region host your RISE environment. We also record existing circuits and firewalls.
1 to 2 weeks - 2
Design
We produce the network design: paths, bandwidth, IP plan, DNS, routing and firewall rules for RISE, BTP and other workloads. SAP reviews the parts that touch its environment.
2 to 3 weeks - 3
Order and build
We order circuits through carriers, build the hub network and gateways as code, and raise peering requests with SAP. VPN backup paths are set up first so projects can start.
4 to 12 weeks, mostly carrier lead time - 4
Test
We test latency, throughput, failover and name resolution from each site and integration. Results are measured against the agreed targets before migration starts.
1 to 2 weeks - 5
Operate
We monitor links, tunnels and peering, and adjust bandwidth as usage grows. Changes follow your change process and are coordinated with SAP.
Ongoing
Connectivity building blocks on each cloud
The native services we use to reach a RISE with SAP environment and SAP BTP on each hyperscaler.
| Need | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Dedicated private circuit | AWS Direct Connect | Azure ExpressRoute, ExpressRoute Direct | Dedicated Interconnect, Partner Interconnect |
| Encrypted VPN | AWS Site-to-Site VPN | Azure VPN Gateway | HA VPN (Cloud VPN) |
| Link to the RISE network | VPC peering, AWS Transit Gateway | VNet peering, VPN VNet-to-VNet | VPC Network Peering, transit VPC |
| Hub and global routing | AWS Transit Gateway, AWS Cloud WAN, Direct Connect gateway | Azure Virtual WAN, hub and spoke | Cloud Router, transit VPC |
| Cloud to cloud links | Direct Connect or VPN through a carrier | ExpressRoute or VPN through a carrier | Cross-Cloud Interconnect |
| Private access from SAP BTP | SAP Private Link service with AWS PrivateLink | SAP Private Link service with Azure Private Link | SAP Private Link service with Private Service Connect |
The SAP side of connectivity
With RISE with SAP, SAP builds and runs the network that hosts your SAP Cloud ERP Private systems, inside its own account, subscription or project on the hyperscaler you choose. You connect to it from your own cloud network, and SAP approves and configures its side. Microsoft and AWS both describe peering from a customer hub as the preferred pattern, with on-premises sites reaching RISE through your existing ExpressRoute, Direct Connect or VPN. SAP BTP is separate: SAP recommends SAP Cloud Connector, which runs on your side and opens outbound-only tunnels, so you do not open inbound firewall ports. SAP Private Link service adds private connections from BTP Cloud Foundry or Kyma applications to services in your own AWS, Azure or Google Cloud account. If you run ECC or SAP S/4HANA yourself on cloud, the same principles apply, but you own both sides of the network.
- Peering design and requests agreed with SAP for the RISE network
- DNS integration with the subdomain delegated to SAP
- SAP Cloud Connector installed, made highly available and monitored
- SAP Private Link service set up for private BTP to cloud service access
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Deliverables
- Network design covering sites, clouds, RISE with SAP and SAP BTP
- IP address plan, DNS design and routing tables
- Private circuits and VPN backup paths built and failover tested
- Hub network and peering to RISE built as code
- SAP Cloud Connector and SAP Private Link service configuration
- Firewall rule set, test report and operating runbook
Frequently asked
Do we need a private circuit, or is VPN enough?
VPN suits smaller sites, backup paths and early project phases. AWS documents a limit of 1.25 Gbps per Site-to-Site VPN tunnel into a RISE VPC, so large user bases, migrations and replication usually justify Direct Connect, ExpressRoute or Interconnect. We size it from your actual traffic.
Who configures the network inside RISE with SAP?
SAP does. It owns the RISE network, approves peering requests and sets its firewall rules. We design and build your side, prepare the requests and settings SAP needs, and test the result with SAP.
How do we connect SAP BTP to our RISE systems?
SAP recommends SAP Cloud Connector, which creates outbound-only tunnels from your network to BTP. When BTP and RISE run on the same hyperscaler, traffic stays on that provider's network. We set up the connector, destinations and access rules.
What is SAP Private Link service for?
It gives applications on SAP BTP a private connection to services in your own AWS, Azure or Google Cloud account, without going over the internet. It is useful when a BTP application must reach a database, API or file service you host privately.
Which region should our network connect to from Sri Lanka?
There is no AWS, Azure or Google Cloud region in Sri Lanka, so links run to a region such as Mumbai, Hyderabad or Singapore. The right choice depends on where your RISE environment and BTP subaccount are hosted. We measure latency from your sites before deciding.
Often paired with this
Plan your move with people who know SAP.
One working session with our cloud and SAP architects. You leave with the options, the risks and a first plan.
- Your landscape reviewed
- The right cloud and region
- A first roadmap
Sources
- Decision tree on connectivity to RISE, AWS
- SAP BTP with RISE on AWS
- Connectivity with SAP RISE, Microsoft Learn
- Network connectivity to RISE with SAP on Google Cloud
- Direct Connect connection options, AWS
- About ExpressRoute Direct, Microsoft Learn
- Dedicated Interconnect overview, Google Cloud
- Connect SAP Private Link service to Google Cloud Private Service Connect
- Explaining the SAP Cloud Connector, SAP Learning
We call our approach to Network & Connectivity to RISE and BTP the Esklane Gate: advice that stays on your side of the table.
AWS, Microsoft Azure, Google Cloud and SAP are trademarks of their respective owners.