High availability and fault tolerance. These two concepts are the safety net that keeps business-critical SAP systems running when things break—a server crashes, a data centre loses power, or an entire AWS Availability Zone goes offline. For the PAS-C01 exam, you must understand how to design these safety nets using SAP’s own tools (like AS/ABAP and HANA System Replication) and AWS services, because the exam loves asking what happens when a single point of failure is removed.
Jump to a section
A simple way to picture High Availability and Fault Tolerance for SAP
Have you ever wondered what happens when a top chef burns their hand right before the dinner rush? The restaurant doesn’t close—another chef steps in from the backup team, and the orders keep flowing. That’s high availability. Now, what if a gas line explodes and destroys the entire kitchen? The restaurant chain doesn’t go out of business—it switches to a second kitchen in a different city, with its own stove, fridge, and staff, already prepped with the same ingredients. That’s fault tolerance.
In SAP on AWS, your “kitchen” is an SAP application or HANA database running on EC2 instances. High availability means if one server (chef) fails, a standby server immediately takes over so there’s barely a pause in service. Fault tolerance means you have a completely separate system in a different AWS Availability Zone—or even a different Region—that can take over entirely if the whole primary site is destroyed by a disaster like a fire, flood, or power outage.
For your PAS-C01 exam, you need to know the specific recipes: AS/ABAP (SAP’s own high availability setup) and HANA System Replication (which copies the database constantly to a standby). AWS adds its own ingredients—Elastic IP addresses, Elastic Load Balancing, and Auto Scaling—to make the kitchen run even when things go wrong. The goal? Your SAP system never closes, even when everything around it breaks.
Let’s start with the core problem: in an IT system, a “single point of failure” (SPOF) is one component whose failure brings the whole system down. If you have only one SAP application server, and that server’s hardware fails, all users are locked out. If you have only one HANA database server, and its disk dies, all data could be lost. High availability (HA) and fault tolerance (FT) are two different strategies to eliminate these SPOFs, and they are tested heavily on PAS-C01.
High availability means you build a system that stays accessible despite failures, typically by having a primary and a standby server. If the primary fails, the standby takes over automatically. This switchover may cause a brief outage—often 30 seconds to a few minutes—but the system comes back. Think of it like a car with a spare tyre: you get a flat, you pull over, change the tyre, and continue. There’s a pause, but you’re not stranded forever.
Fault tolerance means the system can tolerate a failure without any interruption at all—no pause, no dropped sessions. This usually requires redundant components operating in parallel, like an aeroplane with four engines: if one fails, you don’t even notice. In IT, true fault tolerance is expensive and complex, so HA is far more common for SAP.
Now, how does this apply to SAP on AWS? SAP systems have two main layers: the application layer (SAP Central Services, or ASCS, and additional application servers called PAS and AAS) and the database layer (usually SAP HANA). PAS-C01 wants you to know the specific HA approaches for each.
For the application layer, SAP provides a technology called AS/ABAP (Application Server ABAP) with Enqueue Replication. The enqueue service is a critical lock manager that prevents two users from editing the same record simultaneously. If the server hosting this service fails, all locks are lost and the system panics. AS/ABAP HA sets up a cluster of two servers: one active, one passive. They share a virtual hostname and an IP address (using AWS’s Elastic IP or a Network Load Balancer). The passive server runs SAP’s “enqueue replication” service, which keeps a copy of all locks in real time. If the active fails, the passive takes over in under a minute, with most user sessions surviving.
AWS services used here include:
Amazon EC2: the virtual servers themselves.
Elastic IP: a static IP that can be moved from one instance to another.
Amazon Route 53: DNS service that can be configured with health checks to redirect traffic.
Amazon Elastic Load Balancing (specifically Network Load Balancer): to distribute traffic and detect instance health.
Amazon EBS (Elastic Block Store): shared storage for the SAP system files, often using EBS Multi-Attach so both servers can access the same data.
For the database layer, SAP HANA has its own feature called HANA System Replication (HSR). This copies the entire database continuously from a “primary” HANA instance to one or more “secondary” (standby) HANA instances. Replication happens synchronously—meaning every transaction is written to both primary and secondary before the system confirms it’s complete—or asynchronously, where the primary sends data to the secondary but doesn’t wait for confirmation. Synchronous replication gives zero data loss (a critical concept called RPO=0, Recovery Point Objective of zero) but can add latency. Asynchronous replication may lose a few transactions if the primary dies, but it’s faster. For HA within the same AWS Region (multiple Availability Zones), PAS-C01 expects you to choose synchronous replication with automatic failover. For disaster recovery across Regions, asynchronous replication is typical.
To automate failover, SAP uses a cluster manager like Pacemaker on Linux (with SUSE or Red Hat) or Windows Server Failover Clustering. On AWS, you can also use AWS Elastic Disaster Recovery for database-level replication, but native HSR is preferred for HANA.
Finally, you must understand “fencing”—the mechanism that ensures a failed primary server cannot accidentally come back and corrupt the new primary. In AWS, fencing is often implemented with a “STONITH” script that shuts down the failed instance using the AWS API.
In summary, HA and FT for SAP on AWS is a layered defence: application servers are clustered, the database is replicated, storage is shared and redundant, and networking uses static IPs that can float between healthy servers. The exam will test your ability to choose the right combination for a given scenario (e.g., cost vs. uptime, same-Region vs. cross-Region, synchronous vs. asynchronous replication).
1. Identify Single Points of Failure (SPOFs)
List every component in your SAP landscape that, if it fails, stops the entire system. This includes the ASCS server, the HANA database, the storage volume, and the network path. Without this list, you cannot design an HA architecture. Mapping SPOFs forces you to think about what breaks and how to duplicate it.
2. Choose an AWS Region and Availability Zones
Select an AWS Region that is geographically close to your users for low latency. Then choose two separate Availability Zones within that Region for deploying your primary and standby resources. This separation protects against a single data centre outage. For disaster recovery, also choose a second Region hundreds of miles away.
3. Deploy and Configure the ASCS/ERS Cluster
Launch two EC2 instances with the same operating system and SAP software version. Install the cluster manager (Pacemaker on Linux or Windows Failover Clustering). Configure the SAP ASCS (primary) and ERS (enqueue replication server) roles. The ERS runs on the standby node and receives a real-time copy of the lock table from the active ASCS.
4. Configure HANA System Replication
On the primary HANA instance, enable replication to the secondary instance. Choose synchronous replication for intra-Region HA (zero data loss). Set up a separate Pacemaker resource group for HANA that monitors database health and, if the primary fails, promotes the secondary to primary. Test replication by inserting data on the primary and verifying it appears on the secondary.
5. Implement Networking and Traffic Routing
Assign a static Elastic IP to a Network Load Balancer that sits in front of the ASCS cluster. The NLB health check pings the SAP instance port. If the primary fails, the NLB automatically routes traffic to the standby. For database clients, use a virtual hostname that is mapped to the current primary HANA instance via DNS updates during failover. Alternatively, use a database-specific endpoint from the cluster manager.
6. Set Up Monitoring and Alerting
Configure Amazon CloudWatch alarms for CPU, memory, and disk metrics on all EC2 instances. Also set custom SAP-specific metrics via the Amazon CloudWatch agent. If a metric breaches a threshold (e.g., non-healthy HANA service), trigger an SNS notification to pagers or email. This ensures the operations team is aware of a failover event even if it was automatic.
7. Test and Document the Failover Procedure
Force a failure of the primary ASCS instance by stopping the EC2 console, then verify that the ERS node becomes the active ASCS within 60 seconds. Simulate a HANA primary crash by killing the HANA process, and confirm the secondary becomes the new primary with all data intact. Document every step, including commands and expected outputs, so a future team member can perform the same test.
Let’s walk through a realistic scenario. You are an SAP Basis consultant for a mid-size manufacturing company called “PartsCo” that sells car parts globally. PartsCo runs SAP ECC 6.0 on SUSE Linux Enterprise Server (SLES), with a HANA database. Their current setup is a single server in an on-premises data centre. One Friday afternoon, a cooling unit fails, the server room overheats, and the server shuts down. No orders can be entered for eight hours while the server is repaired. PartsCo’s management decides this is unacceptable and asks you to redesign the system on AWS with high availability.
Here is exactly what you do, step by step, as an IT professional:
Assess current architecture. You identify all single points of failure: the single application server (ASCS and PAS on the same machine), the single HANA database server, the single storage array, and the single network switch.
Design the application layer HA. You decide to use an AS/ABAP cluster with two EC2 instances in different Availability Zones in the same AWS Region (e.g., us-east-1a and us-east-1b). Instance A is active (primary), instance B is passive (standby). You install SUSE Linux Enterprise Server for SAP Applications and configure Pacemaker as the cluster manager.
Configure Enqueue Replication. On the active instance, you enable SAP’s enqueue replication service. The system is set so that if the active instance crashes, the standby instance already has a copy of all user locks. You set up a virtual IP address using an Elastic IP, which Pacemaker will move to the healthy instance during a failover.
Implement shared storage. You create two Amazon EFS file systems (or an EBS Multi-Attach volume with a shared filesystem like cluster-aware OCFS2) for the SAP transport directory and the global directory. Both instances mount the same file systems. This way, if instance A fails, instance B has immediate access to all configuration files and patches.
Design the database layer HA. For the HANA database, you launch two EC2 instances, each with high-memory instances (like x1e.32xlarge). You enable HANA System Replication in synchronous mode between the primary (in us-east-1a) and the secondary (in us-east-1b). You set up a separate cluster for HANA using Pacemaker with the resource agent for SAPHana.
Configure automatic failover. You create a “STONITH” (Shoot The Other Node In The Head) resource that uses the AWS CLI to stop the failed instance’s EC2 instance. You also configure health checks on the Network Load Balancer so that if the ASCS service fails, traffic is routed to the standby.
Test everything. You simulate a failure of the primary ASCS server by force-stopping the EC2 instance. You watch Pacemaker detect the failure, move the virtual IP to the standby, and start the ASCS instance there. You then simulate a HANA database failure by killing the HANA process on the primary, and verify that the secondary takes over as the new primary with zero data loss.
Document the architecture. You create a runbook that shows exactly how to recover from a full-AZ failure, including manual steps if automatic failover fails. You also set up Amazon CloudWatch alarms to monitor CPU, memory, and disk I/O on both the primary and standby systems.
Cost optimisation. You recommend using Reserved Instances for the primary servers to save up to 60% compared to On-Demand, and you suggest using a single smaller standby instance for the HANA system if non-disruptive testing can be done during maintenance windows.
This entire process takes about two weeks for a two-person team. After implementation, PartsCo’s SAP system has 99.95% uptime, and even when a server fails, the outage lasts less than 60 seconds. The IT team no longer gets called at 3 AM.
PAS-C01 tests your ability to design high availability and fault tolerance for SAP workloads on AWS. Here is what you must know cold, and the traps the exam sets.
Key exam topics:
- AS/ABAP HA with Enqueue Replication: Know that the enqueue service holds lock tables. Replication keeps a copy of locks on the standby. The exam might ask what happens to locks if the primary fails—the answer is they are preserved on the standby.
- HANA System Replication modes: Synchronous (synced), synchronous with full sync (no data loss), and asynchronous (near-zero, but may lose last few transactions). Know the trade-offs: sync is safer but slower, async is faster but riskier.
- Fencing with STONITH: The exam expects you to know that STONITH is used to prevent a split-brain scenario (where two instances both think they are primary). In AWS, STONITH often uses a script that calls stop-instances on the failed node.
- Virtual IP and DNS: The primary exam concept is that a floating Elastic IP or a Network Load Balancer (NLB) with a health check provides a single endpoint for clients. If you see an exam answer that suggests using a public IP tied to a specific instance, that’s wrong because the IP won’t float during failover.
- Multi-AZ vs. Multi-Region: The exam loves testing this distinction. Multi-AZ is for HA (faster, lower cost, lower latency). Multi-Region is for disaster recovery (slower failover, higher cost, protects against Region-wide outages).
- SAP-specific clustering: You must recognise that for SAP Central Services (ASCS), you need a cluster of two nodes with shared storage and enqueue replication. For HANA, you need HANA System Replication plus a cluster manager (Pacemaker).
- AWS services that support SAP HA: Be familiar with Amazon EFS (shared file system), Amazon EBS Multi-Attach, Amazon Route 53 health checks, AWS CloudFormation for templating, and AWS Systems Manager for automation.
Common traps: - The exam will present a scenario where the architect chooses async HSR for an intra-Region HA setup. The correct answer is synchronous because you are in the same Region with low latency—async is only acceptable for cross-Region disaster recovery. - Another trap: failing to mention fencing. If a question asks about preventing data corruption after a failover, the correct answer will involve STONITH or a similar mechanism. - A third trap: confusing an Application Load Balancer (ALB) with a Network Load Balancer (NLB) for SAP. SAP requires NLB because it handles static IP addresses and preserves client source IP, which SAP applications need. ALB does not preserve the source IP in all cases. - Trap: thinking that Auto Scaling replaces HA for SAP. Auto Scaling replaces failed instances, but it does not provide the sub-minute failover that HA requires—it takes minutes to launch a new instance and configure it.
Key definitions to memorise: - RPO (Recovery Point Objective): How much data you can afford to lose (e.g., zero for sync HSR). - RTO (Recovery Time Objective): How long it takes to restore service (e.g., under a minute for HA). - Split-brain: A dangerous state where both servers in a pair think they are the primary, leading to data corruption. Fencing prevents this. - Quorum: A voting mechanism used by cluster managers to maintain a consistent view of cluster membership.
If you see a multiple-choice question asking “What is the AWS service used to move a virtual IP between an active and passive EC2 instance in an SAP HA cluster?”, the answer will often be “Elastic IP”. If it asks about a health-check-based routing, “Network Load Balancer” is the likely choice.
High availability (HA) uses a primary and standby server to restore service within seconds or minutes after a failure, while fault tolerance (FT) uses parallel redundant components to avoid any interruption at all.
SAP Central Services (ASCS) requires an HA cluster with enqueue replication to preserve user locks across a failover, and this cluster relies on a virtual IP address that can move between servers.
HANA System Replication must be synchronous for zero data loss (RPO=0) when used in a single-Region multi-AZ HA setup, and asynchronous when replicating across AWS Regions for disaster recovery.
Fencing (STONITH) is compulsory in any SAP HA cluster on AWS to prevent split-brain scenarios, and it is typically implemented by forcing the failed EC2 instance to stop via the AWS API.
Network Load Balancer (NLB) preserves the client source IP and provides a static endpoint for the SAP application layer, while an Application Load Balancer (ALB) changes the source IP and is therefore unsuitable for SAP.
Multi-AZ protects against data centre failures within a single AWS Region, but only Multi-Region architecture protects against a full Region outage—they are not interchangeable.
Amazon EFS provides a fully managed, shared file system that both nodes in an SAP ASCS cluster can mount simultaneously, which is essential for keeping files synchronised without manual copying.
These come up on the exam all the time. Here's how to tell them apart.
High Availability (HA)
Tolerates failure with a brief downtime (seconds to minutes)
Uses one active and one standby server (active/passive)
Lower cost because standby can be a smaller instance
Fault Tolerance (FT)
Tolerates failure with zero downtime
Uses multiple active components in parallel (active/active)
Much higher cost because all components must be fully redundant at all times
Synchronous HANA System Replication
Transaction is confirmed only after written to both primary and secondary
Zero data loss (RPO=0)
Latency increases because of the round-trip to the secondary
Asynchronous HANA System Replication
Transaction is confirmed after written to primary only
May lose a few recent transactions (RPO > 0)
Lower latency, suitable for cross-Region replication
AS/ABAP Enqueue Replication
Replicates only lock table entries (not full database)
Operates at the SAP application layer
Paired with ASCS cluster for sub-minute failover
HANA System Replication
Replicates the entire HANA database
Operates at the database layer
Can be used independently or with a cluster manager
Multi-AZ (single Region)
Protects against data centre (AZ) failure
Lower latency between sites (within same Region)
Faster failover (seconds to minutes)
Multi-Region (geographical)
Protects against entire AWS Region failure
Higher latency between sites (hundreds of miles apart)
Slower failover (minutes to hours), usually manual for full DR
Elastic IP (EIP)
Single static IP that is moved between instances
Simple to implement for a single service endpoint
Does not provide health checks—must be combined with a script or manual intervention
Network Load Balancer (NLB)
Static IP that fronts multiple instances with health checks
Built-in health checks automatically reroute traffic
Better for environments with multiple application servers or when client source IP preservation is needed
Mistake
High availability and fault tolerance are the same thing, just different brand names.
Correct
High availability means reducing downtime to seconds or minutes after a failure, while fault tolerance means zero downtime—the system keeps running without interruption even during a failure.
This mistake is common because both concepts aim to keep systems running, and many vendors use the terms loosely in marketing. Beginners often don’t realise that true fault tolerance is extremely expensive and rare in practice.
Mistake
If I use AWS Multi-AZ for my RDS database, I don’t need to set up anything special for SAP HANA.
Correct
AWS RDS Multi-AZ is a managed service that only works for Amazon RDS databases. SAP HANA runs on EC2, so you must manually configure HANA System Replication and a cluster manager like Pacemaker.
Many beginners come from a standard web application background where RDS Multi-AZ is a one-click solution. They assume the same applies to SAP, not realising SAP runs on its own infrastructure.
Mistake
Once I set up HANA System Replication, failover happens automatically without any extra configuration.
Correct
HANA System Replication only replicates data. To achieve automatic failover, you need a cluster manager (like Pacemaker or Windows Failover Clustering) that monitors the primary, detects failure, and triggers the takeover script.
SAP’s documentation and whitepapers often describe HSR as a feature that enables HA, but they don’t always stress that automation requires additional software. Beginners assume replication equals automation.
Mistake
I can use Amazon S3 as shared storage for SAP ASCS and ERS files.
Correct
Amazon S3 is not a file system and does not support POSIX file locking or simultaneous read/write from multiple servers, both of which are required for SAP. You must use Amazon EFS or EBS with a cluster-aware filesystem.
S3 is the simplest AWS storage service and beginners often think it can replace any storage need. They overlook that SAP requires low-latency, file-level locking that S3 cannot provide.
Mistake
If I use a Network Load Balancer for SAP, I can put it across AWS Regions for global HA.
Correct
NLB is a Regional service—it cannot span multiple Regions. For cross-Region HA or disaster recovery, you must use Amazon Route 53 with health checks and latency-based routing, or a combination of Global Accelerator and NLB per Region.
Beginners see that NLB can handle traffic to multiple Availability Zones and assume it can also handle multiple Regions. They don’t read the fine print that NLB is scoped to a single Region.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Auto Scaling replaces failed instances after several minutes, but it does not preserve running user sessions or database locks. SAP HA requires sub-minute failover and session preservation, which only a Pacemaker-based cluster with HANA System Replication can provide.
Yes. The standby instance must be running at all times to receive replicated data and be ready for failover. You pay for it at the standard EC2 on-demand or reserved instance rate. However, you may use a smaller instance size for the standby if the workload can tolerate reduced performance during failover.
Enqueue replication works at the application layer—it copies lock tables from the SAP ASCS server to the standby. HANA System Replication works at the database layer—it copies all data in the HANA database from the primary to the secondary. They are complementary and both needed for full SAP HA.
Technically yes, but it is a terrible idea for HA. If that shared instance fails, both the application and database go down. Best practice is to have separate instances for ASCS/ERS and separate instances for HANA, with each pair having its own cluster and replication.
With a properly configured ASCS cluster using enqueue replication, user sessions survive a failover because the lock table is preserved. The users may see a brief pause of 30–60 seconds while the cluster switches over, but they can continue working without re-logging in.
Yes, but only with a cluster-aware filesystem like OCFS2 that supports concurrent writes from multiple nodes. EBS Multi-Attach allows two EC2 instances to attach the same EBS volume simultaneously, which is useful for the SAP transport directory. However, Amazon EFS is simpler and preferred for most SAP clusters.
You've finished High Availability and Fault Tolerance for SAP. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?