Without proper scaling and performance optimisation, your SAP system would buckle under peak loads — sales orders would fail during Black Friday, payroll would stall at month-end, and user wait times would skyrocket. This chapter explains how to scale SAP systems both vertically (making a single server more powerful) and horizontally (adding more servers), and how to balance traffic and automatically adjust capacity to keep everything running smoothly. For the PAS-C01 exam, understanding these concepts is critical because they directly impact SAP system availability, cost, and user experience.
Jump to a section
A simple way to picture Scalability and Performance Optimization for SAP
The Head Chef at a food truck festival orchestrates the entire operation to serve hungry crowds efficiently.
At the start of the day, the chef decides on the menu for each truck — this is like choosing the right instance type and size for your SAP system (vertical scaling). One truck might have a huge grill for burgers (a large virtual machine with lots of CPU and memory), while another has multiple smaller fryers for chips (a cluster of smaller instances). As the lunch rush hits, the chef watches the queues grow.
To handle the crowd, the chef doesn't just make the single burger grill bigger — that would be like upgrading to a more powerful server, which takes time and has limits. Instead, the chef activates extra trucks: more burger trucks, more chip trucks, each identical and ready to serve. This is horizontal scaling, adding more instances to share the load.
But here's the clever part: the chef doesn't just add trucks randomly. They use a central ordering system (like an Elastic Load Balancer) that directs each customer to the truck with the shortest queue. This ensures no single truck gets overwhelmed while others sit idle. Meanwhile, the chef monitors the crowd size and automatically sends more trucks when queues get long (Auto Scaling). When the rush ends, trucks are sent away to save fuel.
The chef also optimises performance: they pre-prepare ingredients (caching), keep the busiest trucks close to the entrance (content delivery), and run regular maintenance on the grills (performance monitoring and tuning). The goal? Serve every customer quickly, without burning out the staff or wasting resources — exactly what you need to do with SAP systems to keep business users happy and costs low.
Let's start with the basics. In an IT system, a "server" is a powerful computer that runs software and stores data. For SAP, a server might run the SAP application (like SAP S/4HANA) or the database (like SAP HANA). When we talk about scalability, we mean the ability of that system to handle more work — more users, more transactions, more data — without crashing or becoming too slow. There are two main ways to scale: vertical and horizontal.
Vertical scaling means making a single server bigger. Imagine you have a laptop that's running slowly. If you upgrade its RAM (memory) from 8GB to 32GB, you've scaled vertically. In the cloud (Amazon Web Services, or AWS), this means choosing a larger "instance type" — which is a virtual server with specific amounts of CPU, memory, and storage. For SAP, you might move from an instance with 16 virtual CPUs and 128GB of RAM to one with 32 virtual CPUs and 256GB of RAM. AWS offers instance families like the "r5" (memory-optimised) or "m5" (general-purpose) for SAP workloads.
Horizontal scaling means adding more servers to work together. Instead of one big server, you have a group of smaller servers working as a team. This is sometimes called "scale-out." For SAP applications that can run in a distributed fashion (like SAP Web Dispatcher or SAP Application Server instances), you can add more instances to share the load. Each instance handles a portion of the users or transactions.
Now, how do you direct users to the right server? This is where Elastic Load Balancing (ELB) comes in. ELB is an AWS service that automatically distributes incoming traffic across multiple targets — such as Amazon EC2 instances (virtual servers). Think of it as a smart receptionist who sends each visitor to the least busy desk. ELB checks the health of each server: if one crashes or becomes overloaded, ELB stops sending traffic to it and redirects users to healthy servers. For SAP, you might put an Application Load Balancer (ALB) in front of your SAP Web Dispatchers or SAP Fiori front-end servers to balance user requests.
Auto Scaling is the next piece. It's an AWS service that automatically adds or removes servers based on demand. You define a "launch configuration" (what instance type, what software to install, etc.) and a scaling policy (e.g., "if CPU utilisation exceeds 70% for 5 minutes, add one more server"). When demand drops, it removes servers to save costs. For SAP, this is especially useful for non-production environments that don't need full capacity overnight or on weekends, or for handling unpredictable spikes in user activity.
Performance optimization ties everything together. It's not just about adding resources; it's about using them efficiently. Key techniques include:
Caching: storing frequently accessed data in a fast, temporary storage (like Amazon ElastiCache) so the system doesn't have to fetch it from the slower database every time.
Database tuning: optimising queries, indexing tables, and adjusting SAP HANA memory parameters.
Using appropriate storage: AWS offers different storage types — GP3 (general-purpose SSD) for most SAP data, and io2 (provisioned IOPS SSD) for high-performance databases. Choosing the wrong storage can become a bottleneck.
Monitoring: using AWS CloudWatch to track metrics like CPU, memory, disk I/O, and network throughput, and setting alarms to alert when something is wrong.
Why does all this matter? Without scaling, your SAP system fails during peak periods. Without load balancing, one server gets hammered while others sit idle. Without Auto Scaling, you either pay for unused capacity or get caught without enough servers during a spike. For the PAS-C01 exam, you need to know which AWS services support these capabilities, how to configure them for SAP specifically, and what SAP's own sizing guidelines say about instance types and scaling limits.
Assess current system performance
Look at CloudWatch metrics for your SAP instances — CPU, memory, disk I/O, network. Identify the bottleneck. Is the application server CPU pegged? Is the database memory full? This determines whether you need vertical (database) or horizontal (application) scaling.
Choose the scaling method
If the application tier is the bottleneck, plan horizontal scaling with Auto Scaling groups. If the database is the bottleneck, plan vertical scaling by switching to a larger EC2 instance type. Document the target instance size and any downtime required.
Configure Elastic Load Balancing
Create an Application Load Balancer (for HTTP traffic) or Network Load Balancer (for TCP traffic) in front of your application servers. Define a target group containing the instances, set up health checks (e.g., ping the SAP logon page every 30 seconds), and enable session stickiness if needed.
Set up Auto Scaling
Create an Auto Scaling group with a launch template that includes the correct AMI, instance type, and user data scripts to register with the SAP message server. Define a target tracking scaling policy (e.g., keep CPU at 50%). Set minimum, maximum, and desired capacity limits.
Implement performance optimisation
Add caching layers (ElastiCache for frequently accessed data), optimise storage (switch to io2 volumes for SAP HANA if needed), and review database indexes and queries. Monitoring is critical — set CloudWatch alarms for key metrics and create dashboards to track system health.
Test and validate
Use a load testing tool to simulate peak user traffic. Verify that Auto Scaling launches new instances, the load balancer distributes traffic evenly, and response times stay within acceptable limits. Check that new instances are properly registered with the SAP system and that no sessions are lost during scaling events.
Imagine a mid-sized retail company, "GlobalMart," that runs SAP S/4HANA on AWS. They have around 5,000 employees using SAP daily for procurement, inventory, sales, and finance. During the holiday season, traffic doubles as customers flood in and warehouse operations ramp up. Here's what their IT team actually does.
First, they assess the current system. They check the production SAP application server — it's an Amazon EC2 instance of type r5.4xlarge (16 vCPUs, 128GB RAM). For the database, they use an SAP HANA instance on a bigger r5.12xlarge (48 vCPUs, 384GB RAM). They look at CloudWatch metrics and see that CPU utilisation on the application server hits 85% during peak hours, and response times are creeping up.
The team decides to scale horizontally. They create an Auto Scaling group for the SAP application servers (the "dialog instances" that handle user interactions). They set up a launch template that uses an Amazon Machine Image (AMI) with SAP application software pre-installed. The scaling policy says: if average CPU utilisation exceeds 70% for 10 minutes, add one more instance (up to a maximum of 6). At night, when utilisation drops below 30% for 15 minutes, remove one instance (down to a minimum of 2).
To distribute user traffic, they place an Application Load Balancer (ALB) in front of the Auto Scaling group. The ALB has a health check that pings the SAP application URL every 30 seconds. If a server doesn't respond, it's marked unhealthy and traffic is stopped. Users' session stickiness is enabled via a cookie so that once a user lands on a server, they stay there until the session ends.
For the SAP HANA database, which cannot easily scale horizontally, they explore vertical scaling. They schedule a maintenance window to stop the instance, change it to a larger r5.24xlarge (96 vCPUs, 768GB RAM), and start it again. The whole process takes about 15 minutes. They also implement Amazon ElastiCache with Redis to cache frequently accessed pricing data, reducing database load.
Finally, they test everything using a load testing tool. They simulate 2,000 concurrent users and watch the Auto Scaling group add instances, the ALB balance traffic, and response times stay under 2 seconds. They also set up CloudWatch alarms to notify the team if error rates spike or if the Auto Scaling group hits its maximum limit.
This real-world scenario shows the exact workflow: assess, choose scaling method, configure Auto Scaling, set up load balancing, optimise with caching and storage choices, monitor, and iterate. On the exam, you'll be asked which steps to take in which order, and what to configure in each AWS service.
The PAS-C01 exam covers Domain 4.2, "Scale SAP systems horizontally and vertically, optimise performance with Elastic Load Balancing, and Auto Scaling." This section is about 8-12% of the exam weight. The questions are scenario-based — you'll read a description of a company's SAP setup and must pick the best scaling or optimisation solution.
Here are the exact concepts they test and how they try to trick you:
First, know the difference between vertical and horizontal scaling. A common trap: they describe a scenario where the database is the bottleneck (for example, high memory pressure on SAP HANA). The wrong answer suggests adding more application servers (horizontal scaling), which doesn't help the database. The correct answer is to vertically scale the database server to a larger instance type with more memory. For the application tier, horizontal scaling is usually the right answer.
Second, they test Elastic Load Balancing types. You must know the differences between Application Load Balancer (ALB), Network Load Balancer (NLB), and Classic Load Balancer (CLB). ALB works at Layer 7 (application layer) and can route based on URL paths — useful for SAP Fiori or SAP Web Dispatcher. NLB works at Layer 4 (network layer) and is faster but less intelligent — useful for high-throughput scenarios like SAP RFC traffic. CLB is legacy and rarely the correct answer. A common trap: they ask for a solution for "SAP GUI" traffic (which uses a specific port) — the correct answer is NLB, not ALB.
Third, Auto Scaling policies. They test three main types:
Simple scaling: add/remove a fixed number of instances when a threshold is breached.
Step scaling: add/remove instances in steps based on the size of the alarm breach (faster and more precise).
Target tracking scaling: automatically maintain a target metric (e.g., keep average CPU at 50%). This is the easiest and most modern approach.
A common trap: they describe a scenario with sudden, unpredictable spikes (e.g., batch jobs kicking off). The wrong answer uses a scheduled scaling policy (which only works for predictable patterns). The correct answer uses a dynamic scaling policy like target tracking.
Fourth, SAP-specific configuration. You must know that SAP systems use a message server that coordinates application servers. Auto Scaling must register new instances with this message server — they test if you know about custom scripts (like user data scripts) that perform this registration. Also, know that SAP HANA vertical scaling has limits based on instance type — a single HANA instance cannot exceed 12TB of memory on AWS, for example.
Fifth, performance optimisation details:
Storage: GP3 is the default, but for high-throughput SAP HANA you need io2 volumes with provisioned IOPS. A trap: they offer io1 volumes (older, less cost-effective).
Caching: ElastiCache can speed up SAP Fiori launchpad loads or master data lookups.
Monitoring: CloudWatch must collect SAP-specific metrics (e.g., via SAP host agent or custom metrics).
Finally, they test cost optimisation. Scaling up/down costs money; they want you to choose the solution that balances performance and cost. For a development SAP system, you might use a smaller instance and only scale up during testing hours. For production, you need high availability and Auto Scaling across Availability Zones (AZs).
Memorise these definitions for the exam: - "Vertical scaling" = increasing size of a single instance (scale up/scale down). - "Horizontal scaling" = adding/removing instances (scale out/scale in). - "Elastic Load Balancer" = distributes traffic, performs health checks. - "Auto Scaling" = automatically adjusts capacity based on demand. - "SAP sizing" = calculating required instance type based on SAPS (SAP Application Performance Standard) and user count.
Vertical scaling changes the size of a single server; horizontal scaling changes the number of servers.
Elastic Load Balancing distributes incoming traffic across multiple servers to prevent any single server from being overloaded.
Auto Scaling automatically adds or removes servers based on predefined conditions like CPU utilisation or request count.
For SAP HANA databases, vertical scaling is usually preferred over horizontal scaling due to architectural constraints.
Application Load Balancer (ALB) is ideal for HTTP/HTTPS traffic like SAP Fiori; Network Load Balancer (NLB) is best for low-latency TCP traffic like SAP RFC.
You must register new Auto Scaled instances with the SAP message server to ensure they are recognised by the SAP system.
Performance optimisation involves caching (using services like ElastiCache), choosing the right storage type (GP3 vs io2), and database tuning.
Target tracking scaling policies are the simplest way to maintain a specific metric (e.g., keep CPU at 50%).
These come up on the exam all the time. Here's how to tell them apart.
Vertical Scaling
Increases the size of a single server (more CPU, RAM, storage).
Requires downtime or a brief interruption to switch to a larger instance type.
Best for databases like SAP HANA that cannot easily split across multiple servers.
Horizontal Scaling
Adds more servers of the same size to share the workload.
Can be done live with no downtime if behind a load balancer.
Best for stateless application servers (e.g., SAP dialog instances) that can run in parallel.
Application Load Balancer (ALB)
Operates at Layer 7 (application layer) – understands HTTP/HTTPS, URLs, cookies.
Supports content-based routing (e.g., route /sap/bc to one set of servers, /sap/public to another).
Slightly higher latency due to more processing.
Network Load Balancer (NLB)
Operates at Layer 4 (network layer) – routes based on IP and port, no understanding of application content.
Faster and lower latency – great for high-throughput protocols like SAP RFC or Diag.
Cannot perform content-based routing – all traffic to a given port goes to the same target group.
Scheduled Scaling
Scales based on a fixed schedule (e.g., add instances at 9 AM every Monday).
Useful for predictable patterns like monthly payroll runs or known peak times.
Does not react to actual system load – if the pattern changes, it can be wrong.
Dynamic Scaling (Target Tracking)
Scales automatically based on real-time metrics like CPU utilisation or request count.
Useful for unpredictable spikes (e.g., flash sales, holiday rushes).
Adapts to actual load – no need to know the pattern in advance.
GP3 (General Purpose SSD)
Good for moderate-performance workloads – up to 16,000 IOPS and 1,000 MB/s throughput per volume.
Cost-effective for most SAP non-database data (e.g., application logs, transport directories).
Baseline performance is included; extra IOPS cost more.
IO2 (Provisioned IOPS SSD)
Designed for high-performance, consistent I/O – up to 256,000 IOPS per volume.
Required for SAP HANA database volumes where low latency and high throughput are critical.
You pay for provisioned IOPS regardless of whether you use them – more expensive but higher guaranteed performance.
Single-AZ Deployment
All resources are in one Availability Zone (data centre).
Lower cost – no need for replicated resources across zones.
Risk of complete outage if that Availability Zone fails.
Multi-AZ Deployment
Resources (like EC2 instances, database) are spread across multiple Availability Zones.
Higher cost due to duplication and cross-AZ data transfer.
Provides high availability – if one zone fails, traffic shifts to the other zone.
Mistake
Scaling always means adding more servers – bigger is always better.
Correct
Scaling can be vertical (bigger server) or horizontal (more servers). For databases like SAP HANA, vertical scaling is often the only option because databases don't distribute easily across many servers. For application servers, horizontal scaling is usually preferred for cost and resilience.
Beginners hear 'scale' and immediately think 'add more' because that's what's often discussed in general cloud contexts. They don't realise that some systems, especially databases, have architectural limits that prevent simple horizontal scaling.
Mistake
Elastic Load Balancer and Auto Scaling are the same thing.
Correct
They are separate services that often work together. ELB distributes traffic across existing instances; Auto Scaling adds or removes instances based on demand. You can use Auto Scaling without ELB (e.g., for batch processing) and ELB without Auto Scaling (e.g., for a fixed set of servers).
The terms are often used together in the same sentence, so beginners assume they're one service. The exam deliberately asks about each separately to test your understanding of their distinct roles.
Mistake
You can scale SAP HANA horizontally just like application servers.
Correct
SAP HANA does support scale-out configurations (multiple HANA nodes working together), but it's complex, requires specific licensing, and is only possible up to a certain number of nodes. For most scenarios, vertical scaling of the HANA database is the simpler and recommended approach. Application servers can scale horizontally much more easily.
People assume that if one service scales horizontally, all do. They don't appreciate that database consistency and performance requirements make horizontal scaling much harder for databases than for stateless application servers.
Mistake
Once you set up Auto Scaling, you don't need to worry about capacity planning.
Correct
Auto Scaling adjusts within limits you define. You still need to plan the maximum number of instances, choose the right instance types, and ensure your database can handle the peak load from all those instances. Auto Scaling doesn't solve database bottlenecks or instance type selection errors.
There's a myth that 'the cloud handles everything automatically.' Beginners think Auto Scaling is a magic fix, but it only automates the addition/removal of servers — it doesn't make architectural decisions for you.
Mistake
Load balancers always make systems faster.
Correct
Load balancers distribute traffic to prevent overload, but they don't make individual servers faster. If all servers are at capacity, adding a load balancer won't help — you need to scale up or out first. Load balancers also add a small amount of latency (the time to process and forward the request).
The word 'balancing' sounds like optimisation, so people assume it speeds things up. In reality, it's about preventing bottlenecks, not eliminating them.
Mistake
All Elastic Load Balancers work the same way.
Correct
AWS offers three types: ALB (Layer 7, content-based routing), NLB (Layer 4, extreme performance), and CLB (legacy). Each is suited for different scenarios. For SAP, ALB is best for web-based interfaces (Fiori, Web GUI), NLB for high-throughput transaction traffic (RFC, Diag protocol), and CLB is generally deprecated.
The name 'Elastic Load Balancer' makes it sound like one service, but it's three distinct products. The exam tests your ability to choose the right one for the traffic type.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Vertical scaling means making your existing server bigger (more CPU, RAM, storage) — like upgrading from a r5.4xlarge to a r5.12xlarge. Horizontal scaling means adding more servers of the same size — like going from 2 to 4 application servers. For databases (SAP HANA), vertical scaling is common; for applications, horizontal scaling is preferred.
No. A load balancer is only useful when you have multiple servers to distribute traffic across. If you have one server, you don't need it. However, if you plan to scale horizontally later, it's good to set up a load balancer early to avoid reconfiguration.
Yes, if you have a dynamic scaling policy (like target tracking), Auto Scaling will react to increased CPU and launch new instances. However, there's a delay (usually 1-5 minutes) for the new instances to become available. For predictable batch jobs, you might also use scheduled scaling to prepare ahead of time.
Use an Application Load Balancer (ALB) because it works at Layer 7 (HTTP/HTTPS). ALB can route based on URL paths, handle SSL termination, and provide session stickiness — all useful for web-based SAP Fiori interfaces.
The SAP message server is a central component that keeps track of all application servers in the SAP system. When Auto Scaling launches a new instance, that instance must register with the message server so that the system knows it exists and can assign work to it. This is typically done via a script in the launch template's user data.
SAP provides sizing guidelines based on the number of users, transaction volumes, and SAPS (a performance metric). AWS also publishes SAP-certified instance types. For production, you typically use memory-optimised instances (r5 or r6i families) for both app and database, but the database needs significantly more memory. Check the SAP Standard Application Benchmark results for guidance.
It depends. Scaling horizontally with many small instances can be more cost-effective for application servers because you can precisely match capacity and use spot instances. Scaling vertically (a single large instance) might be simpler but can be more expensive if you over-provision. For databases, vertical scaling is usually necessary regardless of cost.
You've finished Scalability and Performance Optimization for SAP. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?