INTRODUCTION
The question I get asked more than any other from customers who’ve just signed their RISE with SAP contract: “Great, we picked AWS — now how do we actually connect to it?”
It’s a fair question. RISE with SAP is a PaaS model — you tell SAP which hyperscaler you want, which applications, which connectivity model, and SAP provisions and manages the AWS accounts on your behalf. We’re talking 2,000+ customer AWS accounts at this point. But SAP managing the infrastructure doesn’t solve the connectivity problem on your end. Your users still need to reach S/4HANA. Your on-premises ERP still needs to send IDocs to the new system during migration. Your custom applications in your own AWS account need API access to the RISE-managed landscape.
That’s the real challenge: how do you connect *your* world — whether that’s your own AWS VPC, your on-premises data center, or both — to the SAP-managed environment that you don’t directly control?
AWS gives you four main options, and the right choice depends on where your workloads live, how much bandwidth you need, and how quickly you need connectivity up and running:
VPC Peering — direct link from your VPC to the SAP-managed VPCTransit Gateway — centralized routing when you have complex network topology on your sideSite-to-Site VPN — encrypted tunnel over the internet, fast to deployAWS Direct Connect — dedicated physical connection for consistent performance
Let me walk through each one from the perspective of what actually matters for SAP RISE connectivity.
Quick Overview
Here’s how I frame the options when a customer asks “which one should we use?”:
Option
Think of it as…
Good for
VPC Peering
A direct cable between your room and SAP’s room
Simple setups, one customer VPC connecting to SAP’s VPC
Transit Gateway
A central switch connecting many rooms
Multiple customer VPCs, shared services, complex routing
Site-to-Site VPN
An encrypted tunnel over the internet
On-premises access, fast deployment, migration phases
Direct Connect
A private leased line
High bandwidth, latency-sensitive workloads, production steady-state
Let me break each one down.
VPC Peering: The Straightforward Option
How It Works
VPC Peering creates a direct network link between two VPCs — in this case, between your customer VPC and the SAP-managed VPC in the RISE account. No gateway device in the middle, no extra hops. Traffic flows directly using private IP addresses, staying entirely on AWS’s backbone network.
For customers who have a single VPC with their own workloads that need to talk to the SAP RISE environment, this is often the simplest path.
Architecture
Performance & Scalability
Bandwidth: No AWS-imposed bandwidth limits – uses full network speed available to your instancesLatency: Low latency, traffic stays on AWS backbone networkMTU: 9001 bytes (jumbo frames) within the same region, 8500 bytes for inter-region peeringConnections per VPC: 50 active peering connections (default), adjustable up to 125Scalability Pattern: Full-mesh topology required – for N VPCs, you need N(N-1)/2 peering connections
Important Limitation: VPC Peering does NOT support transitive routing. If VPC A peers with VPC B, and VPC A peers with VPC C, VPC B cannot communicate with VPC C through VPC A. Each pair requires its own direct peering connection.
Security
Traffic remains on AWS private backbone network, never traverses the public internetSecurity groups and network ACLs control traffic flow between peered VPCsEncryption in transit can be configured at the application layerCross-account peering supported with proper IAM permissionsCannot share edge resources (Internet Gateways, NAT, VPN, Direct Connect, Gateway Endpoints)
Cost Structure
VPC Peering Connection: FREE – No charge to create or maintain peering connections
Data Transfer:
Within same Availability Zone: FREECross-AZ (same region): ~$0.01 per GB in each directionInter-region: ~$0.02 per GB (varies by region pair)
Cost Example: 3 VPCs with 1TB cross-AZ traffic = ~$10/month (data transfer only)
When It Makes Sense for SAP RISE
You have one customer VPC that needs to reach the SAP-managed environmentYour workloads and the SAP landscape are in the same region (ideally same AZ for lowest latency)You don’t need to route on-premises traffic through this connectionYou want minimal operational overhead
When to Look at Other Options
You need on-premises users or systems to reach the SAP environmentYou have multiple customer VPCs that all need SAP connectivity (peering each one individually gets messy)You need centralized network security policies or traffic inspection
Transit Gateway: Centralized Hub-and-Spoke Networking
How It Works?
Transit Gateway is a regional router that acts as a central hub. Your VPCs, VPN connections, and Direct Connect gateways all attach to it, and it handles routing between them. Instead of peering everything to everything, each network connects once to the Transit Gateway.
For SAP RISE connectivity, Transit Gateway becomes relevant when the customer side is complex — multiple VPCs for different business units, on-premises connectivity combined with cloud-to-cloud traffic, or centralized security inspection requirements.
Key Parts
Performance & Scalability
Bandwidth: Up to 100 Gbps per Availability Zone with automatic scalingAttachments: Support for 5,000 attachments per Transit GatewayRoute Tables: 20 route tables per gateway with 10,000 total routesLatency: Minimal additional latency compared to VPC PeeringMTU: 8500 bytesMulticast: Native support with 20 domains and 1 Gbps per flow
Scalability Advantage: For 50 VPCs, VPC Peering requires 1,225 connections vs Transit Gateway needs only 50 attachments (97% reduction)
Why Customers End Up Here
The typical scenario: a customer has their own AWS presence with multiple VPCs — maybe one for their custom applications, one for shared services, one for a data lake — and they all need to reach the SAP RISE environment. Plus, on-premises users need access too.
Without Transit Gateway, you’d peer each customer VPC separately to the SAP VPC, set up a separate VPN for on-premises, and manage routing across all of them independently. Transit Gateway lets you connect everything to one hub and manage routing centrally.
Route tables on Transit Gateway also let you enforce segmentation. You can allow the application VPC to reach SAP but prevent the dev VPC from touching the production SAP landscape. Network teams and auditors appreciate this.
Architecture
Cost Structure
Attachment Fee: $0.05 per hour per attachment (~$36.50/month per VPC, VPN, or Direct Connect attachment)
Data Processing: $0.02 per GB of data processed through the gateway
When It Makes Sense for SAP RISE
Multiple customer VPCs that all need to reach the SAP-managed environmentYou’re combining cloud-to-cloud with on-premises-to-cloud connectivityYou need centralized routing control and network segmentationYou already use Transit Gateway for your internal AWS networking
Worth Noting
If you just have one customer VPC connecting to SAP’s VPC and no on-premises requirement, Transit Gateway is overkill. VPC Peering does the job at a fraction of the cost and complexity
Site-to-Site VPN: Encrypted Hybrid Connectivity
How It Works
Site-to-Site VPN creates an encrypted IPsec tunnel between an on-premises network and AWS over the public internet. Two tunnels per connection for redundancy. You can have it running in hours — no physical infrastructure to order.
For SAP RISE, this is how most customers get their on-premises users and systems connected to the SAP-managed landscape when they can’t wait weeks for Direct Connect provisioning
Performance & Scalability
Standard Bandwidth: Up to 1.25 Gbps per tunnelLarge Bandwidth: Up to 5 Gbps per tunnel (requires Transit Gateway attachment)Scaling Beyond 5 Gbps: Use ECMP (Equal-Cost Multi-Path) routing with multiple tunnelsLatency: Variable, dependent on internet path qualityAccelerated VPN: 30-60% latency reduction with AWS Global AcceleratorRedundancy: Two tunnels per connection for 99.95% SLA
The SAP Context
For on-premises users accessing Fiori launchpad, running SAP GUI transactions, or triggering RFC calls — VPN bandwidth is usually sufficient. These are interactive, low-volume patterns.
Where it gets tight: if you’re running data migration workloads (SLT replication, DMLT loads) from on-premises to the RISE environment during a cutover window, 1.25 Gbps might not cut it. A 2TB dataset at that speed takes about 4.5 hours. On a cutover weekend with limited downtime, that may or may not work depending on your change window
Architecture
Cost Example (5 Gbps Setup)
VPN Connection: ~$432/monthTransit Gateway Attachment: ~$36/monthData Processing: ~$20/monthData Transfer Out (1TB): ~$83/monthTotal: ~$571/month
When It Makes Sense for SAP RISE
On-premises users need access to RISE environment now and Direct Connect would take 4-8 weeksMigration testing: You need hybrid connectivity for functional testing, user acceptance testingLow-to-moderate bandwidth needs: RFC calls, IDoc exchanges, interactive user sessionsAs a backup: Primary path is Direct Connect, VPN provides automatic failover
When It’s Not Enough
Sustained data replication workloads where latency jitter causes timeoutsProduction scenarios where “sometimes it’s slow” gets escalatedAnything requiring more than 5 Gbps sustained
The pattern I see most often: VPN goes live in week one while Direct Connect is ordered. Both run in parallel during migration. Once Direct Connect proves stable, VPN becomes the backup path — but stays active.
AWS Direct Connect: Dedicated Physical Connections
How It Works?
Direct Connect is a physical fiber connection from your data center or colocation facility directly to AWS. No internet in the path. Your traffic gets a dedicated pipe with predictable latency and no contention from other traffic.
For SAP RISE customers who’ve moved past the migration phase and need steady-state production connectivity — especially those with latency-sensitive integrations or high-volume data flows — this is the go-to.
Direct Connect Virtual Interfaces (VIFs)
Once you have a Direct Connect physical connection, you configure Virtual Interfaces (VIFs) to route traffic to AWS resources. This section focuses on Private VIF and Transit VIF for private VPC connectivity.
Private VIF: Direct VPC Access
Connects Direct Connect to one or more VPCs using private IPs via Virtual Private Gateway or Direct Connect Gateway (up to 10 VPCs). MTU: 9001 bytes. Best for simple, point-to-point connectivity.
Transit VIF: Hub-and-Spoke via Transit Gateway
Connects Direct Connect to Transit Gateway through Direct Connect Gateway, enabling access to 5,000+ VPCs through hub-and-spoke architecture. MTU: 8500 bytes. Best for complex, multi-VPC deployments.
Aspect
Private VIF
Transit VIF
Architecture
VGW or DX Gateway
DX Gateway + Transit Gateway
Max VPCs
10
5,000+
MTU
9001 bytes
8500 bytes
Best For
Simple, few VPCs
Complex, many VPCs
How to Choose between Private and Transit VIF
If you have a straightforward setup — on-premises connecting to your VPC and the SAP RISE VPC — Private VIF keeps things simple with fewer moving parts and slightly better MTU.
If you already have Transit Gateway managing multiple VPCs and VPN connections, use Transit VIF to keep the architecture consistent. The 500-byte MTU difference is irrelevant for SAP traffic in practice.
Performance & Scalability
Bandwidth Options: 50 Mbps to 400 Gbps – Dedicated: 1, 10, 100, 400 Gbps – Hosted (via partners): 50 Mbps to 25 GbpsLatency: Low, consistent, and predictableThroughput: Dedicated bandwidth with no oversubscriptionMTU: Up to 9001 bytes (jumbo frames)Reliability: 99.95% SLA for dedicated connections
Architecture
Security
MACsec (Layer 2 encryption): For 1/10/100/400 Gbps, GCM-AES-256, no extra costIPsec over Direct Connect: Combine with VPN for end-to-end encryptionPrivate connectivity: Traffic never traverses public internetPhysical isolation: Dedicated connection separate from other customers
Break-Even: Direct Connect typically becomes cost-effective at 1-5 TB/month data transfer
When Direct Connect Connectivity Makes Sense for SAP RISE
Production connectivity where consistent latency matters (Fiori, SAP GUI from offices)High-volume integration traffic (IDocs, data replication)Customers near an AWS Direct Connect locationPost-migration steady state — you’re past the VPN phase and need something reliable long-term
Comparative Analysis: Side-by-Side Comparison
Performance & Scalability Matrix
Metric
VPC Peering
Transit Gateway
VPN
Direct Connect
Max Bandwidth
Unlimited
100 Gbps/AZ
5 Gbps/tunnel
400 Gbps
Latency
Low
Low
Variable
Very Low
Max Connections
50-125/VPC
5,000
Unlimited
Unlimited
MTU
9001/8500
8500
8500
9001
Transitive Routing
No
Yes
Via TGW
Via TGW
Cost Comparison Scenarios
Scenario 1: Small Scale (3 VPCs, 1 TB/month)
Option
Monthly Cost
VPC Peering
~$10 (Most cost-effective)
Transit Gateway
~$130
Site-to-Site VPN
~$120
Direct Connect
~$300+ (Not cost-effective at this scale)
Scenario 2: Large Scale (100 VPCs, 20 TB/month)
Option
Monthly Cost
VPC Peering
Not feasible (4,950 connections required)
Transit Gateway
~$4,050 (Only practical option)
Site-to-Site VPN
Not sufficient (bandwidth limitations)
Direct Connect
~$1,500-2,500 (Best for high bandwidth)
Decision Framework: Choosing the Right Solution
Decision Tree
Three questions get you to the right answer:
Question 1: Where are your users/systems that need to reach the SAP RISE environment?
In your own AWS VPC → Question 2On-premises (data center, offices) → Question 3Both → You’ll likely combine options
Question 2: How complex is your AWS-side network?
One VPC connecting to SAP → VPC Peering. Simple and cheap.Multiple VPCs, shared services, need centralized routing → Transit Gateway.
Question 3: What’s your timeline and bandwidth need?
Need connectivity this week, under 5 Gbps → Site-to-Site VPNCan wait 4-8 weeks, need consistent performance → Direct ConnectNeed it now AND long-term → VPN immediately, Direct Connect ordered in parallel, VPN becomes backup
Which VIF for Direct Connect?
Simple setup, under 10 VPCs → Private VIFAlready using Transit Gateway → Transit VIF
Common SAP RISE Connectivity Patterns
Pattern 1: Customer Cloud Workloads → SAP RISE
Situation: Customer has their own AWS account with custom applications (middleware, portals, analytics) that call APIs on the S/4HANA system in the SAP-managed account.
Typical choice: VPC Peering between customer VPC and SAP-managed VPC.
Why it works: Low latency for API calls, no bandwidth limits, zero connection fees. Security groups on both sides control exactly which subnets and ports can communicate.
Pattern 2: On-Premises → SAP RISE (During Migration)
Situation: Customer is migrating from on-premises ECC to RISE with SAP S/4HANA. During the transition period, on-premises users need to access the new system, and legacy interfaces (RFC, IDocs) still run between old and new.
Typical choice: Site-to-Site VPN first, with Direct Connect ordered for production go-live.
Why it works: VPN gets you connected in hours. Bandwidth is sufficient for interactive use and moderate interface traffic. Once Direct Connect is provisioned, it takes over as primary and VPN drops to backup.
Pattern 3: Global Enterprise → SAP RISE
Situation: Large customer with offices worldwide, multiple AWS accounts for different business units, on-premises data centers, all needing to reach the centrally managed RISE environment.
Typical choice: Transit Gateway as the hub, Direct Connect from primary data centers via Transit VIF, VPN from smaller offices.
Why it works: Centralized routing and network policy. One place to manage access control, one place to troubleshoot. Direct Connect provides consistent performance for the high-traffic paths, VPN covers the rest.
Pattern 4: Redundant Production Connectivity
Situation: Customer cannot tolerate connectivity outages to their production SAP environment. Business-critical processes (payroll, order processing) depend on it.
Typical choice: Direct Connect as primary + Site-to-Site VPN as backup, with BGP routing configured to prefer Direct Connect.
Why it works: Direct Connect gives you the performance and consistency. VPN gives you the safety net. BGP handles automatic failover. Total additional cost for the VPN backup is $150-500/month — cheap insurance against a fiber cut taking down your SAP access.
Practical Tips
Order Direct Connect Early
I keep repeating this because it keeps catching people out. If your project timeline has a go-live date, count backward 8 weeks and that’s when the Direct Connect order needs to be in. Use VPN in the gap.
Don’t Skip VPN Backup for Production
Direct Connect is reliable — until a backhoe cuts the fiber, or the colocation facility has a power event. A VPN backup for $150-500/month means your SAP production stays reachable during those rare but real outages. Configure BGP path preferences so traffic automatically moves to VPN and back.
Watch Your Data Transfer Costs
Keep tightly-coupled workloads in the same AZ where possible. Cross-AZ transfer adds up fast at scale.Transit Gateway charges $0.02/GB for every byte that passes through it. Large data movements (system copies, backups) should be evaluated — sometimes a direct peering for that specific flow saves money.Use VPC Endpoints for AWS services (S3, DynamoDB) to avoid routing that traffic through Transit Gateway or NAT Gateways.
Security Considerations
Site-to-Site VPN encrypts by default (IPsec). Direct Connect does *not* — add MACsec for 10/100/400 Gbps connections, or layer IPsec on top.Use security groups and NACLs to restrict traffic between peered VPCs to only the ports and protocols you actually need (e.g., RFC ports 33XX, HTTPS 443 for Fiori).Enable VPC Flow Logs. When an integration fails and nobody can explain why, flow logs tell you whether traffic reached the destination or got blocked.
Test Failover Before You Need It
If you have redundant paths (Direct Connect + VPN), simulate a failover *before* production go-live. Verify traffic moves to the backup and — just as importantly — moves back when the primary recovers. Asymmetric routing issues are easier to fix during testing than during an incident.
Conclusion
The connectivity question for SAP RISE comes down to two things: where your users and systems currently live, and how much bandwidth and consistency they need to reach the SAP-managed environment.
For most customers, the journey looks like this:
Cloud-to-cloud only (your VPC → SAP VPC)? Start with VPC Peering.On-premises access needed quickly? Site-to-Site VPN.Production-grade on-premises connectivity? Direct Connect, with VPN as backup.Complex network topology on your side? Transit Gateway to centralize routing.
These aren’t mutually exclusive — plenty of customers combine VPC Peering for cloud-to-cloud traffic with Direct Connect for on-premises access. Pick what fits your current state, but keep an eye on where you’re heading.
INTRODUCTIONThe question I get asked more than any other from customers who’ve just signed their RISE with SAP contract: “Great, we picked AWS — now how do we actually connect to it?”It’s a fair question. RISE with SAP is a PaaS model — you tell SAP which hyperscaler you want, which applications, which connectivity model, and SAP provisions and manages the AWS accounts on your behalf. We’re talking 2,000+ customer AWS accounts at this point. But SAP managing the infrastructure doesn’t solve the connectivity problem on your end. Your users still need to reach S/4HANA. Your on-premises ERP still needs to send IDocs to the new system during migration. Your custom applications in your own AWS account need API access to the RISE-managed landscape.That’s the real challenge: how do you connect *your* world — whether that’s your own AWS VPC, your on-premises data center, or both — to the SAP-managed environment that you don’t directly control?AWS gives you four main options, and the right choice depends on where your workloads live, how much bandwidth you need, and how quickly you need connectivity up and running:VPC Peering — direct link from your VPC to the SAP-managed VPCTransit Gateway — centralized routing when you have complex network topology on your sideSite-to-Site VPN — encrypted tunnel over the internet, fast to deployAWS Direct Connect — dedicated physical connection for consistent performanceLet me walk through each one from the perspective of what actually matters for SAP RISE connectivity.Quick Overview Here’s how I frame the options when a customer asks “which one should we use?”: OptionThink of it as…Good forVPC PeeringA direct cable between your room and SAP’s roomSimple setups, one customer VPC connecting to SAP’s VPCTransit GatewayA central switch connecting many roomsMultiple customer VPCs, shared services, complex routingSite-to-Site VPNAn encrypted tunnel over the internetOn-premises access, fast deployment, migration phasesDirect ConnectA private leased lineHigh bandwidth, latency-sensitive workloads, production steady-stateLet me break each one down.VPC Peering: The Straightforward Option How It WorksVPC Peering creates a direct network link between two VPCs — in this case, between your customer VPC and the SAP-managed VPC in the RISE account. No gateway device in the middle, no extra hops. Traffic flows directly using private IP addresses, staying entirely on AWS’s backbone network.For customers who have a single VPC with their own workloads that need to talk to the SAP RISE environment, this is often the simplest path.Architecture Performance & ScalabilityBandwidth: No AWS-imposed bandwidth limits – uses full network speed available to your instancesLatency: Low latency, traffic stays on AWS backbone networkMTU: 9001 bytes (jumbo frames) within the same region, 8500 bytes for inter-region peeringConnections per VPC: 50 active peering connections (default), adjustable up to 125Scalability Pattern: Full-mesh topology required – for N VPCs, you need N(N-1)/2 peering connectionsImportant Limitation: VPC Peering does NOT support transitive routing. If VPC A peers with VPC B, and VPC A peers with VPC C, VPC B cannot communicate with VPC C through VPC A. Each pair requires its own direct peering connection.SecurityTraffic remains on AWS private backbone network, never traverses the public internetSecurity groups and network ACLs control traffic flow between peered VPCsEncryption in transit can be configured at the application layerCross-account peering supported with proper IAM permissionsCannot share edge resources (Internet Gateways, NAT, VPN, Direct Connect, Gateway Endpoints)Cost StructureVPC Peering Connection: FREE – No charge to create or maintain peering connectionsData Transfer: Within same Availability Zone: FREECross-AZ (same region): ~$0.01 per GB in each directionInter-region: ~$0.02 per GB (varies by region pair)Cost Example: 3 VPCs with 1TB cross-AZ traffic = ~$10/month (data transfer only)When It Makes Sense for SAP RISEYou have one customer VPC that needs to reach the SAP-managed environmentYour workloads and the SAP landscape are in the same region (ideally same AZ for lowest latency)You don’t need to route on-premises traffic through this connectionYou want minimal operational overheadWhen to Look at Other OptionsYou need on-premises users or systems to reach the SAP environmentYou have multiple customer VPCs that all need SAP connectivity (peering each one individually gets messy)You need centralized network security policies or traffic inspectionTransit Gateway: Centralized Hub-and-Spoke NetworkingHow It Works?Transit Gateway is a regional router that acts as a central hub. Your VPCs, VPN connections, and Direct Connect gateways all attach to it, and it handles routing between them. Instead of peering everything to everything, each network connects once to the Transit Gateway.For SAP RISE connectivity, Transit Gateway becomes relevant when the customer side is complex — multiple VPCs for different business units, on-premises connectivity combined with cloud-to-cloud traffic, or centralized security inspection requirements.Key PartsAttachments: Links that plug your VPCs, VPNs, or direct lines into the hub.Route Tables: Rules inside the gateway that decide where incoming data packets should go next.Associations: Binds a specific network attachment to a certain route table.Propagations: Automatically shares network paths so you do not have to type them in by hand.Performance & ScalabilityBandwidth: Up to 100 Gbps per Availability Zone with automatic scalingAttachments: Support for 5,000 attachments per Transit GatewayRoute Tables: 20 route tables per gateway with 10,000 total routesLatency: Minimal additional latency compared to VPC PeeringMTU: 8500 bytesMulticast: Native support with 20 domains and 1 Gbps per flowScalability Advantage: For 50 VPCs, VPC Peering requires 1,225 connections vs Transit Gateway needs only 50 attachments (97% reduction)Why Customers End Up Here The typical scenario: a customer has their own AWS presence with multiple VPCs — maybe one for their custom applications, one for shared services, one for a data lake — and they all need to reach the SAP RISE environment. Plus, on-premises users need access too.Without Transit Gateway, you’d peer each customer VPC separately to the SAP VPC, set up a separate VPN for on-premises, and manage routing across all of them independently. Transit Gateway lets you connect everything to one hub and manage routing centrally.Route tables on Transit Gateway also let you enforce segmentation. You can allow the application VPC to reach SAP but prevent the dev VPC from touching the production SAP landscape. Network teams and auditors appreciate this.Architecture Cost StructureAttachment Fee: $0.05 per hour per attachment (~$36.50/month per VPC, VPN, or Direct Connect attachment)Data Processing: $0.02 per GB of data processed through the gatewayWhen It Makes Sense for SAP RISEMultiple customer VPCs that all need to reach the SAP-managed environmentYou’re combining cloud-to-cloud with on-premises-to-cloud connectivityYou need centralized routing control and network segmentationYou already use Transit Gateway for your internal AWS networkingWorth Noting If you just have one customer VPC connecting to SAP’s VPC and no on-premises requirement, Transit Gateway is overkill. VPC Peering does the job at a fraction of the cost and complexitySite-to-Site VPN: Encrypted Hybrid ConnectivityHow It WorksSite-to-Site VPN creates an encrypted IPsec tunnel between an on-premises network and AWS over the public internet. Two tunnels per connection for redundancy. You can have it running in hours — no physical infrastructure to order.For SAP RISE, this is how most customers get their on-premises users and systems connected to the SAP-managed landscape when they can’t wait weeks for Direct Connect provisioningPerformance & ScalabilityStandard Bandwidth: Up to 1.25 Gbps per tunnelLarge Bandwidth: Up to 5 Gbps per tunnel (requires Transit Gateway attachment)Scaling Beyond 5 Gbps: Use ECMP (Equal-Cost Multi-Path) routing with multiple tunnelsLatency: Variable, dependent on internet path qualityAccelerated VPN: 30-60% latency reduction with AWS Global AcceleratorRedundancy: Two tunnels per connection for 99.95% SLAThe SAP Context For on-premises users accessing Fiori launchpad, running SAP GUI transactions, or triggering RFC calls — VPN bandwidth is usually sufficient. These are interactive, low-volume patterns. Where it gets tight: if you’re running data migration workloads (SLT replication, DMLT loads) from on-premises to the RISE environment during a cutover window, 1.25 Gbps might not cut it. A 2TB dataset at that speed takes about 4.5 hours. On a cutover weekend with limited downtime, that may or may not work depending on your change windowArchitecture Cost Example (5 Gbps Setup)VPN Connection: ~$432/monthTransit Gateway Attachment: ~$36/monthData Processing: ~$20/monthData Transfer Out (1TB): ~$83/monthTotal: ~$571/monthWhen It Makes Sense for SAP RISEOn-premises users need access to RISE environment now and Direct Connect would take 4-8 weeksMigration testing: You need hybrid connectivity for functional testing, user acceptance testingLow-to-moderate bandwidth needs: RFC calls, IDoc exchanges, interactive user sessionsAs a backup: Primary path is Direct Connect, VPN provides automatic failoverWhen It’s Not EnoughSustained data replication workloads where latency jitter causes timeoutsProduction scenarios where “sometimes it’s slow” gets escalatedAnything requiring more than 5 Gbps sustainedThe pattern I see most often: VPN goes live in week one while Direct Connect is ordered. Both run in parallel during migration. Once Direct Connect proves stable, VPN becomes the backup path — but stays active.AWS Direct Connect: Dedicated Physical ConnectionsHow It Works?Direct Connect is a physical fiber connection from your data center or colocation facility directly to AWS. No internet in the path. Your traffic gets a dedicated pipe with predictable latency and no contention from other traffic.For SAP RISE customers who’ve moved past the migration phase and need steady-state production connectivity — especially those with latency-sensitive integrations or high-volume data flows — this is the go-to.Direct Connect Virtual Interfaces (VIFs)Once you have a Direct Connect physical connection, you configure Virtual Interfaces (VIFs) to route traffic to AWS resources. This section focuses on Private VIF and Transit VIF for private VPC connectivity.Private VIF: Direct VPC AccessConnects Direct Connect to one or more VPCs using private IPs via Virtual Private Gateway or Direct Connect Gateway (up to 10 VPCs). MTU: 9001 bytes. Best for simple, point-to-point connectivity.Transit VIF: Hub-and-Spoke via Transit GatewayConnects Direct Connect to Transit Gateway through Direct Connect Gateway, enabling access to 5,000+ VPCs through hub-and-spoke architecture. MTU: 8500 bytes. Best for complex, multi-VPC deployments.AspectPrivate VIFTransit VIFArchitectureVGW or DX GatewayDX Gateway + Transit GatewayMax VPCs105,000+MTU9001 bytes8500 bytesBest ForSimple, few VPCsComplex, many VPCsHow to Choose between Private and Transit VIFIf you have a straightforward setup — on-premises connecting to your VPC and the SAP RISE VPC — Private VIF keeps things simple with fewer moving parts and slightly better MTU. If you already have Transit Gateway managing multiple VPCs and VPN connections, use Transit VIF to keep the architecture consistent. The 500-byte MTU difference is irrelevant for SAP traffic in practice.Performance & ScalabilityBandwidth Options: 50 Mbps to 400 Gbps – Dedicated: 1, 10, 100, 400 Gbps – Hosted (via partners): 50 Mbps to 25 GbpsLatency: Low, consistent, and predictableThroughput: Dedicated bandwidth with no oversubscriptionMTU: Up to 9001 bytes (jumbo frames)Reliability: 99.95% SLA for dedicated connectionsArchitecture SecurityMACsec (Layer 2 encryption): For 1/10/100/400 Gbps, GCM-AES-256, no extra costIPsec over Direct Connect: Combine with VPN for end-to-end encryptionPrivate connectivity: Traffic never traverses public internetPhysical isolation: Dedicated connection separate from other customersBreak-Even: Direct Connect typically becomes cost-effective at 1-5 TB/month data transferWhen Direct Connect Connectivity Makes Sense for SAP RISEProduction connectivity where consistent latency matters (Fiori, SAP GUI from offices)High-volume integration traffic (IDocs, data replication)Customers near an AWS Direct Connect locationPost-migration steady state — you’re past the VPN phase and need something reliable long-termComparative Analysis: Side-by-Side ComparisonPerformance & Scalability MatrixMetricVPC PeeringTransit GatewayVPNDirect ConnectMax BandwidthUnlimited100 Gbps/AZ5 Gbps/tunnel400 GbpsLatencyLowLowVariableVery LowMax Connections50-125/VPC5,000UnlimitedUnlimitedMTU9001/8500850085009001Transitive RoutingNoYesVia TGWVia TGWCost Comparison ScenariosScenario 1: Small Scale (3 VPCs, 1 TB/month)OptionMonthly CostVPC Peering~$10 (Most cost-effective)Transit Gateway~$130Site-to-Site VPN~$120Direct Connect~$300+ (Not cost-effective at this scale) Scenario 2: Large Scale (100 VPCs, 20 TB/month)OptionMonthly CostVPC PeeringNot feasible (4,950 connections required)Transit Gateway~$4,050 (Only practical option)Site-to-Site VPNNot sufficient (bandwidth limitations)Direct Connect~$1,500-2,500 (Best for high bandwidth)Decision Framework: Choosing the Right SolutionDecision TreeThree questions get you to the right answer:Question 1: Where are your users/systems that need to reach the SAP RISE environment?In your own AWS VPC → Question 2On-premises (data center, offices) → Question 3Both → You’ll likely combine optionsQuestion 2: How complex is your AWS-side network?One VPC connecting to SAP → VPC Peering. Simple and cheap.Multiple VPCs, shared services, need centralized routing → Transit Gateway.Question 3: What’s your timeline and bandwidth need?Need connectivity this week, under 5 Gbps → Site-to-Site VPNCan wait 4-8 weeks, need consistent performance → Direct ConnectNeed it now AND long-term → VPN immediately, Direct Connect ordered in parallel, VPN becomes backupWhich VIF for Direct Connect?Simple setup, under 10 VPCs → Private VIFAlready using Transit Gateway → Transit VIFCommon SAP RISE Connectivity PatternsPattern 1: Customer Cloud Workloads → SAP RISESituation: Customer has their own AWS account with custom applications (middleware, portals, analytics) that call APIs on the S/4HANA system in the SAP-managed account.Typical choice: VPC Peering between customer VPC and SAP-managed VPC.Why it works: Low latency for API calls, no bandwidth limits, zero connection fees. Security groups on both sides control exactly which subnets and ports can communicate. Pattern 2: On-Premises → SAP RISE (During Migration)Situation: Customer is migrating from on-premises ECC to RISE with SAP S/4HANA. During the transition period, on-premises users need to access the new system, and legacy interfaces (RFC, IDocs) still run between old and new.Typical choice: Site-to-Site VPN first, with Direct Connect ordered for production go-live.Why it works: VPN gets you connected in hours. Bandwidth is sufficient for interactive use and moderate interface traffic. Once Direct Connect is provisioned, it takes over as primary and VPN drops to backup. Pattern 3: Global Enterprise → SAP RISE Situation: Large customer with offices worldwide, multiple AWS accounts for different business units, on-premises data centers, all needing to reach the centrally managed RISE environment.Typical choice: Transit Gateway as the hub, Direct Connect from primary data centers via Transit VIF, VPN from smaller offices.Why it works: Centralized routing and network policy. One place to manage access control, one place to troubleshoot. Direct Connect provides consistent performance for the high-traffic paths, VPN covers the rest.Pattern 4: Redundant Production ConnectivitySituation: Customer cannot tolerate connectivity outages to their production SAP environment. Business-critical processes (payroll, order processing) depend on it.Typical choice: Direct Connect as primary + Site-to-Site VPN as backup, with BGP routing configured to prefer Direct Connect.Why it works: Direct Connect gives you the performance and consistency. VPN gives you the safety net. BGP handles automatic failover. Total additional cost for the VPN backup is $150-500/month — cheap insurance against a fiber cut taking down your SAP access.Practical TipsOrder Direct Connect EarlyI keep repeating this because it keeps catching people out. If your project timeline has a go-live date, count backward 8 weeks and that’s when the Direct Connect order needs to be in. Use VPN in the gap.Don’t Skip VPN Backup for ProductionDirect Connect is reliable — until a backhoe cuts the fiber, or the colocation facility has a power event. A VPN backup for $150-500/month means your SAP production stays reachable during those rare but real outages. Configure BGP path preferences so traffic automatically moves to VPN and back.Watch Your Data Transfer CostsKeep tightly-coupled workloads in the same AZ where possible. Cross-AZ transfer adds up fast at scale.Transit Gateway charges $0.02/GB for every byte that passes through it. Large data movements (system copies, backups) should be evaluated — sometimes a direct peering for that specific flow saves money.Use VPC Endpoints for AWS services (S3, DynamoDB) to avoid routing that traffic through Transit Gateway or NAT Gateways.Security ConsiderationsSite-to-Site VPN encrypts by default (IPsec). Direct Connect does *not* — add MACsec for 10/100/400 Gbps connections, or layer IPsec on top.Use security groups and NACLs to restrict traffic between peered VPCs to only the ports and protocols you actually need (e.g., RFC ports 33XX, HTTPS 443 for Fiori).Enable VPC Flow Logs. When an integration fails and nobody can explain why, flow logs tell you whether traffic reached the destination or got blocked.Test Failover Before You Need It If you have redundant paths (Direct Connect + VPN), simulate a failover *before* production go-live. Verify traffic moves to the backup and — just as importantly — moves back when the primary recovers. Asymmetric routing issues are easier to fix during testing than during an incident.Conclusion The connectivity question for SAP RISE comes down to two things: where your users and systems currently live, and how much bandwidth and consistency they need to reach the SAP-managed environment.For most customers, the journey looks like this:Cloud-to-cloud only (your VPC → SAP VPC)? Start with VPC Peering.On-premises access needed quickly? Site-to-Site VPN.Production-grade on-premises connectivity? Direct Connect, with VPN as backup.Complex network topology on your side? Transit Gateway to centralize routing.These aren’t mutually exclusive — plenty of customers combine VPC Peering for cloud-to-cloud traffic with Direct Connect for on-premises access. Pick what fits your current state, but keep an eye on where you’re heading. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
