Connectivity and networking cost in RISE.

Network connectivity and the cost of moving data into and out of a RISE tenancy is the most underestimated single category of operating cost in the seven year contract. The RISE proposal usually quotes a per FUE subscription, a defined storage envelope, and a set of platform commitments. What it rarely quotes is the network footprint required to operate the platform alongside the rest of the buyer's estate. The network footprint is often material, sometimes more than ten percent of the annual operating cost, and it is invisible in the original proposal. This article walks through how to bring it into view.

Map every flow that crosses the RISE boundary

The first discipline in modelling network cost is to enumerate every flow that crosses the RISE boundary. Inbound flows from integration platforms, from data lakes, from EDI brokers, from third party SaaS systems. Outbound flows to analytics platforms, to data warehouses, to operational reporting systems, to printers and to mobile users. Each flow has a direction, a volume, a frequency, and a pricing implication under the hyperscaler's egress and ingress tariffs.

The map is the foundation. Without it, the buyer is negotiating a network commitment with no idea what the actual demand looks like. With it, the buyer can quote the network cost line by line, challenge the SAP proposal where it is silent on networking, and surface the operating cost that the seven year TCO should include.

Common omissions in the map include the data movements that support business intelligence dashboards, the regular extractions for tax and audit, the integration with consolidation engines for group reporting, and the operational integrations with logistics partners and bank systems. Each of those flows is part of the running cost of the platform, and each of them needs a price under the chosen hyperscaler's network tariffs.

Understand the hyperscaler egress economics

Each hyperscaler prices egress differently. AWS, Azure, and Google Cloud each publish per gigabyte egress rates that vary by region, by destination, and by traffic profile. The differences between them are not trivial. A workload that moves a hundred terabytes per month between RISE and external analytics carries materially different cost on AWS than on Azure than on Google Cloud, even before any volume discount conversation.

The buyer side discipline is to model the egress under each hyperscaler at the actual volume the integration map produces, then compare the results. The comparison is not the final answer, because egress is one of many considerations in the hyperscaler choice. But the comparison is a meaningful input that the SAP proposal usually does not include, and it shifts the conversation from a list price discussion to a true cost of ownership discussion.

Each hyperscaler also offers committed use or volume discount programmes that reduce egress for known traffic patterns. Buyers who commit to a defined traffic envelope can secure discounts that materially reduce the egress line item. The conversation belongs in the original contract, not in a year two cost reduction exercise after the bill has surprised the finance team.

Use dedicated interconnect for predictable flows

For predictable, high volume traffic between the buyer's network and the hyperscaler, the dedicated interconnect option is usually more cost effective than public egress. AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect each provide private, lower cost connectivity at committed bandwidth tiers. The pricing model is closer to a traditional MPLS link than to per gigabyte egress.

The buyer side discipline is to identify which flows justify dedicated interconnect and to size the interconnect against the actual demand profile. Common candidates include integration flows from on premise systems, data movement to enterprise data lakes, EDI flows with major trading partners, and replication for disaster recovery. The break even on dedicated interconnect versus public egress is usually visible in the modelling and varies by region pair.

The interconnect conversation should happen during RISE contracting, not after. Some interconnect commitments require lead time, port reservation, and physical install at the carrier hotel level. Building the interconnect into the program plan from the beginning reduces the risk of a network shortfall at cutover and gives the buyer a stable cost line from day one.

Address cross region replication explicitly

Cross region replication is one of the largest single egress items in many RISE workloads. The DR posture defined in the contract drives a continuous stream of replication traffic between the primary and the secondary region. Some hyperscalers price intra region replication differently from cross region replication, and the cross region rates can be a multiple of the intra region rates.

The buyer side discipline is to model the replication traffic from the actual database change rate, not from a default assumption. A large finance workload with daily close patterns produces different replication volumes than a manufacturing workload with continuous transactional change. The replication rate, times the per gigabyte tariff, times twelve months, times seven years, often produces a seven year cost that the RISE proposal did not include in its quote.

The conversation should also include the commercial mechanics for adjusting the DR posture. If the business case changes, if the recovery objectives evolve, or if a regulatory framework imposes new constraints, the buyer should be able to adjust the replication posture without renegotiating the entire contract. The order form schedules should provide the mechanism.

Negotiate the BTP network footprint

BTP, the SAP Business Technology Platform, sits alongside the RISE tenant in many implementations. Custom extensions, integration services, side car analytics, and identity bridges often run on BTP and exchange data with the RISE core. The network footprint between BTP and RISE is often inside the SAP network domain and carries little or no egress charge. The footprint between BTP and external systems is a different conversation, and one that is often missed in the RISE proposal.

The buyer side discipline is to map the BTP network footprint alongside the RISE network footprint, identify the flows that cross into and out of BTP, and include them in the egress modelling. Buyers who treat BTP as a separate operating cost from RISE miss the integration cost that links them. Buyers who treat them as a single operating system get a complete picture of the network economics.

The same applies to SAP Cloud services that are not part of the core RISE bundle. Ariba, SuccessFactors, Concur, and others each have integration patterns with the RISE core. Each pattern produces traffic. Each traffic stream has a cost. The order form schedules should reference the integration patterns and the network implications, even if the schedules cannot price every one in advance.

Contract around the network commitments

The final discipline is to write the network commitments into the contract. The egress allowance included in the base subscription, if any. The dedicated interconnect commitments, if applicable. The cross region replication terms, with defined volumes and prices. The mechanism for adjusting the network footprint over time, with predictable commercial terms. The reporting obligation, with visibility into actual network consumption at a frequency that allows the buyer to manage it.

The contract should also address the network performance commitments, separate from the network cost. Latency targets, jitter, packet loss, and bandwidth availability are all measurable and all relevant to the operational experience. SLAs that cover those metrics, with defined remedies for breach, give the buyer the protection that the RISE proposal usually does not include. The breach remedies should be financial, not just credits against future service, because credits against future service have no value if the underlying problem is structural.

Buyers who write the network commitments into the contract treat networking as a managed line item. Buyers who do not write them in find networking is a quarterly surprise, with conversations between the finance team, the SAP account team, and the system integrator that produce no resolution and increasing cost. The contract is the only place where the conversation can be settled in advance.

Conclusion

Network connectivity and egress are the largest single category of underestimated cost in the RISE seven year operating model. The flows that cross the RISE boundary, the hyperscaler egress tariffs, the dedicated interconnect economics, the cross region replication patterns, the BTP and SAP Cloud integrations, and the contractual commitments around network performance are each a place where the proposal is silent and the operating bill is loud. Buyers who model the network footprint before signing, choose the hyperscaler and region with network economics in view, build dedicated interconnect where it earns its place, and write the resulting commitments into the contract keep their seven year TCO close to the proposal number. Buyers who treat networking as an implementation detail find that detail becomes a recurring negotiation that they have no formal leverage to resolve.