SAP on Azure Architecture: High Availability, Disaster Recovery, and Operations

SAP on Azure architecture is difficult for one reason above all others: resilience has to work across several independent layers at the same time. An SAP application can have redundant virtual machines and still fail because the database, storage, name resolution, cluster quorum, network path, or recovery procedure was designed as if it were somebody else’s responsibility.

The current Microsoft AZ-120 exam reflects that reality. Microsoft’s April 17, 2026 skills outline covers migration, infrastructure design, high availability and disaster recovery, and the ongoing operation of SAP workloads in Azure. The Microsoft Azure for SAP Workloads Specialty is therefore less about memorizing Azure services than about understanding how SAP availability requirements translate into a cloud operating model.

A good architecture starts with failure and recovery requirements before it starts with virtual-machine sizes.

Define the workload before choosing infrastructure

SAP landscapes are not interchangeable. HANA, NetWeaver, SQL Server-based workloads, development systems, production systems, and RISE-related integrations can have very different performance, availability, storage, and support requirements.

Start with the workload profile: expected users, transaction volume, memory and CPU demand, storage throughput, growth, interface dependencies, maintenance windows, and business-critical periods. Then define the required recovery time and acceptable data loss.

Those requirements should drive VM sizing, storage design, networking, availability architecture, and cost. Oversizing everything “for safety” is not an architecture strategy; neither is minimizing cost before the performance and resilience requirements are understood.

High availability has to cover every critical layer

High availability is about surviving component failure without requiring a disaster-recovery event. For SAP on Azure, that can include redundant application servers, clustered central services, database replication, redundant network paths, and storage behavior that matches the availability design.

The design should explicitly identify the failure domain for each component. What happens if one VM fails? One availability zone? One storage dependency? One network path? A planned maintenance event? If the answer is “Azure will handle it,” the design is not complete enough.

Clustering also requires operational knowledge. Pacemaker, STONITH, SQL clustering, HANA system replication, restart behavior, and health probes are meaningful only when the team understands how they detect failure and which component is allowed to take ownership.

Disaster recovery is a separate architecture problem

High availability and disaster recovery protect against different scopes of failure. A multi-zone design may tolerate a datacenter-scale problem inside one Azure region, but it does not automatically protect against a regional outage or a destructive operational event.

A disaster-recovery strategy must account for compute, database state, storage, identity, DNS, routing, integrations, security controls, and the sequence in which services are restored. Azure Site Recovery can be part of that plan, but application consistency and SAP-specific dependencies still need deliberate treatment.

Test the recovery path. A backup that has never been restored is evidence that a backup job ran, not evidence that the SAP service can recover. A failover procedure should prove that users, interfaces, monitoring, and dependent systems work after the move—not merely that virtual machines boot.

Network design can quietly defeat resilience

SAP workloads often have strict latency and throughput requirements between application, database, and integration tiers. Network design therefore affects both performance and recovery.

Plan address spaces, subnets, routing, DNS, firewalls, load balancing, connectivity to on-premises environments, and any SAP RISE integration as one architecture. If the organization uses ExpressRoute or VPN connectivity, decide what happens when that path is degraded or unavailable.

Hybrid connectivity also affects identity and operations. An SAP system may be running in Azure while authentication, monitoring, backup administration, or external interfaces still depend on systems elsewhere. Those dependencies should appear on the recovery diagram.

Storage choices belong to the performance model

SAP databases place demanding requirements on latency, throughput, durability, and consistency. Storage should be chosen from measured workload needs and supported SAP patterns rather than generic cloud-storage guidance.

Separate database data, logs, shared file systems, backups, and temporary workloads according to their behavior. Understand which layer is replicated, which layer is backed up, and which storage feature contributes to availability versus recoverability.

Performance testing is essential. A VM size may have enough CPU and memory while the storage or network limits prevent the system from meeting the application target. Capacity planning should therefore consider the combined limits of compute, storage, and network rather than reading each specification in isolation.

Landing-zone decisions also matter before migration begins. Subscription structure, resource groups, identity, policy, naming, network boundaries, and operational ownership should be ready before production SAP components arrive. Otherwise, migration teams can create short-term exceptions that become permanent operating debt.

Capacity planning should include quota and regional availability. A target VM family or storage configuration can be technically supported while still being unavailable in the required region or subscription at the necessary scale. Validate capacity assumptions early enough that the migration plan has alternatives.

Moving SAP to Azure is not only a data-movement exercise. The migration method has to preserve acceptable downtime, validation, rollback, connectivity, and supportability.

Different workloads may justify lift-and-shift, database migration, HANA migration, or a more extensive modernization path. The right approach depends on source platform, database, acceptable outage, data volume, target architecture, and business schedule.

The migration runbook should include prechecks, replication or transfer, cutover, validation, integration testing, and a clear point at which rollback is no longer safe. Practice migrations are valuable because they replace assumed durations with measured ones.

Identity and backup design are part of recoverability

SAP recovery depends on more than compute and database replication. The restored service still depends on identity, secrets, certificates, name resolution, and backup access behaving as expected.

Define which administrators can perform recovery tasks and how those permissions are protected. A recovery plan that assumes every supporting dependency remains available is incomplete.

Backup design should also distinguish data protection from service recovery. Database backups, file backups, configuration, keys, and infrastructure definitions can have different restore procedures. Test whether the combined set is enough to rebuild a usable SAP service.

Operations begin after the migration succeeds

A resilient SAP landscape needs monitoring that can distinguish infrastructure health from application health. Azure Monitor, SAP-specific monitoring, database telemetry, storage metrics, network visibility, backup status, and cluster state all contribute different evidence.

Alerts should point to an operating decision. A dashboard full of metrics does not help if nobody knows which threshold indicates user impact, which team owns the response, or which dependency should be checked first.

Maintenance also matters. Patching, VM resizing, storage growth, backup retention, certificate changes, identity changes, and cluster updates can all introduce outages if they are performed without understanding the dependency chain.

Nonproduction landscapes deserve separate treatment. Development, test, quality, and sandbox systems often have different uptime requirements from production and can provide meaningful savings through scheduling, smaller capacity, or different recovery objectives. Those savings should be intentional rather than copied into production without regard for business impact.

Operational documentation should connect cost to architecture. If a replica, standby region, premium storage tier, or dedicated network path exists for a resilience requirement, record that reason. It becomes much easier to review spend later without accidentally removing something that exists to satisfy an SLA.

SAP infrastructure can be expensive, so cost optimization is important—but only after the workload requirements are clear. Reservations, Savings Plans, right-sizing, storage optimization, and scheduling nonproduction systems can all reduce cost without weakening a production SLA.

Cloud cost management should connect spend directly to workload behavior. A secondary region, additional database replica, or higher storage tier should have a documented resilience or performance reason. Likewise, unused capacity should be challenged when evidence shows it is no longer required.

Optimization should include recovery cost. A design that is cheap during normal operation but cannot obtain sufficient capacity during failover may not meet the real requirement.

Recovery runbooks need business validation

A recovery event is not finished when the infrastructure reports healthy. Application owners still need to confirm that critical transactions, interfaces, scheduled jobs, external integrations, and user access behave correctly in the recovered environment.

Write those validation steps before they are needed. Define which business transactions prove that the service is usable, who performs the checks, and what evidence is required before normal processing resumes.

The recovery design should also include the return path. After a major failover or repair, decide how data will be synchronized, when the primary environment can resume service, and how the team will validate the move without creating unnecessary disruption.

Test architecture as a sequence of failures

A strong AZ-120 lab does not need to reproduce an enterprise SAP estate. It needs enough components to test reasoning. Draw the SAP tiers, map dependencies, define availability and recovery targets, and then walk through failures one by one.

Ask what happens if an application server fails, a database node fails, a zone becomes unavailable, storage performance degrades, ExpressRoute fails, a backup is unusable, or the primary region is lost. For each event, identify detection, failover, validation, ownership, and return-to-normal procedure.

This turns architecture into an operational story. It also exposes hidden single points of failure that are easy to miss in a clean diagram.

Operational ownership should be mapped across SAP, Azure platform, database, network, and business teams. During an incident, unclear ownership can consume more recovery time than the technical failure itself. Runbooks should state who can initiate failover, who validates the database, who confirms application health, and who communicates that service is ready for users.

Change management deserves the same attention. A storage change, cluster update, route modification, or identity policy can affect several SAP layers at once. Review significant changes against the dependency map and include a validation step that checks the user-facing SAP service, not only the Azure resource that was modified.

Before calling the design complete, verify supportability against the specific SAP and Azure components in use. Supported combinations, maintenance requirements, and platform limits can change. Architecture documentation should record those assumptions so future upgrades can be reviewed against them rather than relying on tribal knowledge.

Record support and capacity assumptions beside the architecture. A particular VM family, database version, replication method, or storage pattern may be valid only under specific platform and SAP support conditions. Keeping those assumptions visible makes later upgrades safer and prevents an old design from being copied after the underlying constraints change.

SAP resilience on Azure is strongest when high availability, disaster recovery, performance, networking, storage, migration, and operations are designed together. AZ-120 rewards that systems view. The important question is not whether each Azure component is individually redundant, but whether the complete SAP service can continue or recover within the business requirement when one of its dependencies fails.