RISE with SAP on Azure
Understand RISE with SAP as a managed service on Azure, including private connectivity options, monitoring integration, the shared responsibility model, and how RISE compares to self-managed SAP on Azure IaaS.
What is RISE with SAP?
🏗️ Raj looks puzzled. “Deepak heard about RISE with SAP at a conference and now he keeps asking whether we should just let SAP handle everything. What exactly is RISE?”
☁️ Mei pulls up a diagram. “RISE with SAP is essentially SAP-as-a-service. SAP takes responsibility for the infrastructure, the database, the SAP Basis administration, and even the technical migration. You get S/4HANA running on Azure, but SAP manages the platform. You focus on your business processes and custom applications.”
Think of it like renting a fully managed office vs leasing an empty floor.
Self-managed IaaS is like leasing an empty floor in an office building — you get the space and utilities, but you buy the furniture, set up the network, hire the janitor, and fix things when they break. RISE with SAP is like a managed office — you walk in, the desks are set up, IT is handled, and someone else maintains the building. You just bring your people and start working. You have less control over the layout, but you also have fewer headaches.
RISE vs self-managed: The comparison
This is a high-probability exam topic. You need to know exactly where the responsibility boundary falls.
| Responsibility | RISE with SAP | Self-Managed IaaS |
|---|---|---|
| Infrastructure provisioning | SAP manages (Azure VMs, storage, networking within SAP subscription) | You manage (you deploy and configure Azure VMs) |
| OS patching | SAP manages | You manage |
| HANA database administration | SAP manages (backups, patching, performance tuning) | You manage |
| SAP Basis administration | SAP manages (kernel patching, transport management, system monitoring) | You manage |
| High availability and DR | SAP manages (per contracted SLA) | You design and manage (Pacemaker, HSR, ASR) |
| Business process configuration | You manage | You manage |
| Custom ABAP code | You manage | You manage |
| Integrations with other systems | You manage (SAP provides connectivity options) | You manage |
| Network connectivity to your VNet | Shared — SAP provisions the SAP-side, you configure your side | You manage entirely |
| Cost model | Subscription fee based on usage tier | Pay-as-you-go Azure consumption plus SAP licenses |
| Flexibility and control | Limited — SAP determines VM sizes, patching windows, upgrade cadence | Full — you choose VM sizes, patching schedules, architecture |
🏗️ Raj weighs the options. “So with RISE, I would not need to worry about Linux patching, HANA backups, or setting up Pacemaker clusters. That is tempting.”
☁️ Mei adds context. “True, but you also give up control. If SAP decides to patch on a Thursday and your month-end close runs on Thursdays, you need to coordinate with SAP, not just reschedule it yourself. For PrecisionSteel with your 15 years of custom SAP experience, self-managed might actually be the better fit because your team can handle the Basis work, and you keep full control over the schedule.”
Exam tip: RISE responsibility boundary
The exam loves testing the shared responsibility boundary. Remember: SAP manages everything below the application layer (infrastructure, OS, database, Basis). You manage everything at the application layer and above (business config, custom code, integrations, users). Network connectivity is shared — both sides need to configure their end.
⚠️ Recently changed — exam alert
RISE with SAP and SAP networking for RISE scenarios are areas of increasing exam emphasis, confirmed by the AZ-120 renewal assessment skills list. Key tested concepts: the VNet peering model between SAP-managed and customer Azure environments, the shared responsibility boundary (SAP manages the HANA infrastructure, you manage your Azure networking and identity), and monitoring RISE systems from your own Azure environment using Sentinel and Azure Monitor.
Private connectivity: Connecting RISE to your Azure environment
RISE runs in SAP-managed Azure subscriptions, not yours. Your existing Azure workloads (other apps, Active Directory, monitoring systems) live in your own subscriptions. Connecting the two requires private network paths.
VNet peering
VNet peering creates a direct, private network link between your Azure VNet and the SAP-managed VNet. Traffic stays on the Microsoft backbone — never crosses the public internet.
Requirements for VNet peering with RISE:
- Non-overlapping IP address ranges between your VNet and the SAP-managed VNet
- Both VNets must be in the same Azure region (or use global VNet peering for cross-region)
- SAP initiates the peering from their side; you accept and configure routing on yours
- You may need to configure Network Security Groups (NSGs) to control traffic flow
Azure Private Link
Private Link provides an alternative connectivity model where specific SAP services are exposed as private endpoints in your VNet. This is more granular than VNet peering.
- Each SAP service gets a private IP address in your VNet
- No need for full VNet peering — reduces the network surface area
- Works well when you only need connectivity to specific SAP endpoints (not full network-level access)
When to use which connectivity model
- VNet peering — When you need broad, bidirectional network access between your environment and RISE (e.g., your on-premises users access SAP through your Azure hub, your monitoring tools need to reach SAP systems)
- Private Link — When you only need to expose specific SAP services and want to minimize the network footprint
🏗️ Raj’s junior colleague Yuki (joining from Mei’s team for this discussion) asks: “What about connecting on-premises users to RISE?”
☁️ Mei draws the network flow. “On-premises users typically connect through your existing Azure hub VNet using ExpressRoute or VPN. From there, VNet peering or Private Link reaches the RISE environment. You do not establish direct connectivity from on-premises to the SAP-managed subscription — everything routes through your Azure hub.”
Monitoring RISE environments
Even though SAP manages the infrastructure, you still need visibility into system performance and availability.
- SAP Cloud ALM — SAP’s cloud-based application lifecycle management tool. It is the primary monitoring interface for RISE customers, providing health dashboards, alerting, and incident management.
- Azure Monitor integration — Limited compared to self-managed, because the infrastructure runs in SAP’s subscription. However, you can monitor your connectivity endpoints and network performance from your side.
- SAP Solution Manager — May still be used for some monitoring scenarios during transition, but Cloud ALM is the strategic direction.
Monitoring differences: RISE vs self-managed
With self-managed SAP on Azure, you deploy Azure Monitor for SAP solutions directly onto your VMs and get full infrastructure and application telemetry. With RISE, you rely on SAP Cloud ALM for most monitoring because the infrastructure is in SAP’s subscription. This is one of the trade-offs of the managed model — less operational burden, but also less direct visibility.
Knowledge check
PrecisionSteel is evaluating RISE with SAP. Their team has 15 years of SAP Basis experience and wants full control over patching schedules to align with their manufacturing production calendar. Which deployment model is the better fit?
Mei is designing network connectivity for an organization using RISE with SAP on Azure that needs to connect their on-premises ERP integration servers to the RISE environment. What is the recommended network architecture?
Summary
RISE with SAP is a managed service model where SAP handles infrastructure, OS, database, and Basis administration while you retain responsibility for business processes, custom code, and integrations. Connectivity to your Azure environment uses VNet peering (broad network access) or Private Link (granular service endpoints). Monitoring shifts from Azure Monitor to SAP Cloud ALM. The choice between RISE and self-managed depends on your team’s capabilities, control requirements, and operational preferences.
Next, we dive into migration execution — the hands-on details of DMO, classical migration, and heterogeneous system copies.
🎬 Video coming soon