SAP Operations on AWS: Monitoring and Management is the practice of keeping an SAP system running reliably, efficiently, and securely on the Amazon Web Services cloud. It matters for your PAS-C01 exam because the exam tests your ability to select the right AWS tools and SAP tools to detect problems before they cause downtime, automate repairs, and prove compliance — all without needing to be in the same room as the server.
Jump to a section
A simple way to picture SAP Operations on AWS: Monitoring and Management
First, the head chef installs thermometers in every refrigerator, oven, and hot-holding unit, and then the health inspector arrives without notice to check the logs. This is exactly the relationship between an SAP system administrator and the team monitoring the system on AWS.
Imagine you run a high-end restaurant. The kitchen is your SAP system — it runs the core business, like managing inventory, processing orders, and handling financials. The AWS environment is the entire restaurant building. Now, to make sure the kitchen is always running safely and to pass surprise health inspections (regulatory compliance, system uptime, performance), you need a few key tools.
First, you install sensors — that is Amazon CloudWatch. It constantly measures the temperature of your fridges (CPU utilisation), how full the walk-in cooler is (disk space), and how many orders are being fired (transaction throughput). You check a live dashboard showing every temperature reading and alarm. If a fridge door is left ajar, an alert goes off immediately, just like a CloudWatch alarm for high memory usage.
Second, you have a master control panel for all your kitchen equipment — that is AWS Systems Manager. From one screen, you can remotely adjust the thermostat on an oven in the far corner (run a command on a server), update the recipe software on a tablet (patch the operating system), or lock the storeroom door (apply a security policy) without ever walking over.
Third, you have your own specialist tools — the SAP-specific tools like SAP Solution Manager and SAP Focused Run. These are like the head chef's personal notebook and recipe-tasting routine. They understand the unique language of SAP: they check if a specific business process (like paying an invoice) is taking too long, or if a table in the database is getting corrupted. They are experts in the restaurant's signature dishes, not just general kitchen hygiene.
Managing a restaurant this way means you never fail a health inspection, you spot a failing compressor before the ice cream melts, and you can prove to the owner that everything is running perfectly. On AWS, these three layers — CloudWatch, Systems Manager, and SAP tools — give an administrator the same control and visibility over their SAP system.
When a business runs its SAP system on AWS, it is trusting a massive, complex application with its most critical operations — from paying employees to tracking every product in a warehouse. That application runs on virtual servers inside AWS, and those servers have a heartbeat. The job of monitoring and management is to constantly listen to that heartbeat and to take action when something sounds wrong.
Monitoring means collecting data about the system's health: how fast the processors are working, how much memory is being used, how much disk space is free, and how fast the network is moving data. Management means using that data to make changes: restarting a service that has crashed, applying a security patch, or scaling up a server to handle more users. These two activities work together. Without monitoring, you are flying blind. Without management, you are a doctor who can diagnose a disease but has no medicine.
There are three main tool categories that the PAS-C01 exam expects you to understand:
Amazon CloudWatch: This is the core monitoring service. It collects metrics (measurements) from your AWS resources. For an SAP system, you would configure CloudWatch to track CPU usage, memory utilisation, disk I/O (input/output operations per second), and network traffic. You create alarms that trigger when a metric crosses a threshold, like sending an email when disk space drops below 20%. CloudWatch can also collect custom metrics, such as the number of users logged into SAP or the response time of a specific transaction.
AWS Systems Manager: This is a management service that gives you a unified interface to control your EC2 instances (the virtual servers running SAP). A key feature is Session Manager, which lets you open a secure shell to a server without needing to open inbound ports or manage SSH keys. Systems Manager also includes Patch Manager (to apply security updates automatically), Run Command (to execute scripts on many servers at once), and Fleet Manager (to view and manage all your instances from one console).
SAP-specific tools: SAP provides its own monitoring and management software. SAP Solution Manager is an SAP application that monitors the health of all your SAP systems, manages changes, and tracks incidents. SAP Focused Run is a more modern, highly scalable tool for large landscapes. These tools understand SAP proprietary protocols: they can see into the SAP application layer, check logs like syslog and dev_w0, and alert on problems like short dumps (program crashes) or failed background jobs. They integrate with AWS by sending their own alerts to CloudWatch.
The exam will test your knowledge of which tool to use in which scenario. For example, if you need to see the CPU trend over the last month, you use CloudWatch. If you need to install a security patch on 50 SAP servers without logging into each one, you use Systems Manager Patch Manager. If you need to know why a specific SAP program crashed with an ABAP short dump, you use SAP Solution Manager.
Why does all this exist? Before cloud computing, a company would have a physical server in a data centre. An administrator would walk to the server room to check the blinking lights or install a patch. On AWS, servers might be in different continents. Monitoring and management tools replace that physical walk with a digital dashboard and automated actions.
1. Install the Required Agents
On each EC2 instance that runs SAP, you must install the AWS Systems Manager Agent (SSM Agent) and the Amazon CloudWatch Agent. The SSM Agent enables Session Manager and patching. The CloudWatch Agent collects custom metrics (like memory utilisation) and log files. Without these agents, the services cannot manage the instances.
2. Configure CloudWatch Metrics and Alarms
Define which metrics matter: CPU, memory, disk I/O, disk space, and network throughput. Create CloudWatch alarms for critical thresholds, such as disk space below 20% or CPU above 90% for ten minutes. An alarm can send a notification to an SNS topic (email or SMS) or trigger an action like an EC2 instance recovery.
3. Set Up SAP-Specific Monitoring in Solution Manager or Focused Run
Configure SAP Solution Manager or SAP Focused Run to monitor the SAP application layer. This involves setting up RFC connections to the managed SAP systems, defining alert thresholds for ABAP short dumps, slow transactions, and failed batch jobs. These tools provide a business-oriented view of health that CloudWatch cannot match.
4. Create Systems Manager Maintenance Windows for Patching
Define a weekly maintenance window that includes a pre-patch script to stop the SAP application services (like SAPMNT and disp+work), then apply OS patches using Patch Manager, then reboot if needed, and finally run a post-patch script to start SAP services again. This ensures patching does not corrupt data or cause unplanned downtime.
5. Integrate SAP Alerts with CloudWatch via Custom Metrics
Write a script (or use the SAP AWS Connector) to pull critical SAP alerts (e.g., database connection loss, license expiry) from Solution Manager and push them as custom metrics to CloudWatch. Then create CloudWatch alarms on these custom metrics. This bridges the gap between SAP application health and AWS infrastructure monitoring.
6. Enable CloudTrail and Configure Dashboard
Ensure AWS CloudTrail is recording all API calls (like who stopped an instance or changed a security group). Create a CloudWatch dashboard that combines infrastructure metrics, custom SAP metrics, and CloudTrail logs for a single-pane-of-glass view. This dashboard is used for both day-to-day operations and audit compliance.
Let us follow a real-world scenario: Maria is an SAP Basis administrator for a mid-sized retail company that runs SAP S/4HANA on AWS. She manages a landscape of six EC2 instances: one for the SAP application server, one for the database (HANA), two for development and test systems, and two for production and disaster recovery.
One Tuesday morning, Maria gets a page (alert) from CloudWatch at 2:00 AM. The alarm reads: "High CPU utilisation on the HANA database server." She opens the AWS Management Console and looks at the CloudWatch dashboard. She can see a graph showing the CPU spiking to 95% for the last 30 minutes. The memory graph also shows high consumption. She knows this could mean a runaway query or a bad report.
Maria then opens AWS Systems Manager. She uses Session Manager to open a secure command-line session to the HANA server — no SSH keys needed, no open ports. She runs a HANA SQL command to check which queries are running. She finds that a material planning report is consuming huge resources, likely because a user accidentally ran it without parameters for the entire company.
She has a few options:
She can use SAP Solution Manager to check the SAP alerts for that specific HANA system. It might show a performance alert for the same report.
She can use Systems Manager Run Command to execute a script that kills the problematic connection directly on the server.
She can use CloudWatch to set up a new composite alarm that combines CPU and memory to better detect this pattern in the future.
Maria kills the report via the SQL command. She then uses Systems Manager Patch Manager to check if any security patches are due on the production server — it shows that a missing Linux kernel patch is available. She schedules the patch for the next maintenance window on Sunday night, using Systems Manager Maintenance Windows.
Later, she logs into SAP Focused Run to review the day's health. It shows that a background job for inventory reconciliation failed overnight. She reruns the job. She then opens CloudWatch Logs to examine the application logs of the failed job and finds a permission error — a temporary file path was too long. She corrects the path in the SAP system.
At the end of the week, Maria runs a compliance report using AWS Config (which is related but not the same as CloudWatch) to prove to auditors that all servers have the required patches and that no unauthorised changes were made. This report is possible because Systems Manager tracked all the patching activity, and CloudWatch logs captured all the session activity.
This scenario shows that an administrator does not just watch a single screen. They move fluidly between CloudWatch (the what), Systems Manager (the how), and SAP tools (the why) to keep the system healthy.
The PAS-C01 exam tests your ability to pick the correct monitoring and management tool for a given situation. It does not test your ability to memorise every checkbox in the AWS Console. Instead, it gives you scenario-based multiple-choice questions where you must choose the best combination of tools.
The exam focuses heavily on these concepts:
CloudWatch metrics and alarms: You will be asked what to do when a metric breaches a threshold. The common correct answer is to create a CloudWatch alarm that triggers an action (like sending an SNS notification or stopping an EC2 instance). A trap is to suggest using EC2 Auto Scaling for an SAP system, but SAP systems often require manual or planned scaling, not automatic scaling triggered by CPU.
Systems Manager Session Manager vs. EC2 Instance Connect or bastion hosts: The exam loves to test this. Session Manager is the preferred secure method because it does not require opening inbound ports (SSH port 22) and works with AWS Identity and Access Management (IAM) policies. A trap answer will suggest using a bastion host (a middleman server) or opening SSH ports to a known IP. The correct answer is Session Manager.
The difference between SAP Solution Manager and SAP Focused Run: The exam may present a scenario with a very large SAP landscape (hundreds of systems). Focused Run is built for scale and offers higher performance monitoring and alerting. Solution Manager is for smaller landscapes and is more traditional. Know that Focused Run uses its own dedicated database (HANA) and is often used by managed service providers.
Integration of SAP tools with AWS: Questions will ask how to get SAP alerts into CloudWatch. The correct answer is typically to install the SAP Cloud Connector or use SAP Focused Run's integration with Amazon CloudWatch. A trap is to suggest writing a custom script that does not use the standard integration path.
Maintenance windows and patching: The exam asks about safe patching strategies for critical SAP systems. The correct pattern is to use Systems Manager Maintenance Windows, which allow you to define a schedule for patching, include a pre-patch script to stop SAP services, and a post-patch script to restart them. A trap is to suggest applying patches immediately without a window.
EC2 instance recovery and monitoring health: Amazon CloudWatch alarms can be configured to automatically recover an EC2 instance if it is impaired (status check fails). This is a specific feature tested for SAP HA scenarios. Remember that instance recovery preserves the instance ID and private IP, but not automatically the Elastic IP assignment.
Log collection: CloudWatch Logs agent vs. Systems Manager Agent (SSM Agent). The CloudWatch Logs agent sends specific log files (like /var/log/syslog) to CloudWatch Logs. The SSM Agent is for Systems Manager features like Run Command and Session Manager. Both agents must be installed on the EC2 instance.
Key definitions to memorise for the exam:
Status check: Two checks per EC2 instance: system status check (AWS hardware/software failure) and instance status check (guest OS failure).
CloudWatch alarm states: OK, ALARM, INSUFFICIENT_DATA.
Systems Manager documents (SSM documents): Scripts or commands that define the actions to take.
SAPshort dump: An SAP program crash, logged in ABAP or Java stack.
SM21: Transaction code for SAP system log (direct observation of events).
DBACOCKPIT: Transaction for database monitoring in SAP.
A common trap: confusing Amazon CloudWatch Logs with AWS CloudTrail. CloudTrail records API calls made to AWS (who launched an instance), while CloudWatch Logs stores application and system logs from within the instance. The exam may ask which service is used to monitor instance-level operating system logs.
Amazon CloudWatch collects and visualises metrics and logs from SAP servers, while AWS Systems Manager lets you remotely execute commands and apply patches without opening network ports.
SAP Solution Manager and SAP Focused Run are separate SAP tools; Focused Run is designed for high-volume, large-scale landscapes and integrates natively with AWS services.
Systems Manager Session Manager is the most secure and recommended way to access SAP EC2 instances because it uses the SSM Agent and IAM policies, not open SSH ports.
A CloudWatch alarm can automatically recover an impaired EC2 instance within the same Availability Zone, preserving the instance ID and private IP address but not the Elastic IP.
To patch SAP servers safely on AWS, you must define a Systems Manager Maintenance Window that stops the SAP application stack before patching the OS and restarts it afterwards.
The most effective monitoring strategy for SAP on AWS combines three layers: CloudWatch for infrastructure-level metrics, Systems Manager for management actions, and SAP Solution Manager or Focused Run for application-level health checks.
CloudWatch Logs stores application logs from within the SAP instance, while AWS CloudTrail records API calls made to the AWS control plane; they serve different purposes and are both tested on the exam.
Status checks (system and instance) are built-in health checks for EC2; instance status check failure can trigger an alarm, but application-level SAP crashes (short dumps) require SAP-specific monitoring tools to detect.
These come up on the exam all the time. Here's how to tell them apart.
Amazon CloudWatch
Focuses on collecting and visualising metrics and logs
Primarily a monitoring service (what is happening?)
Alarms can trigger actions but cannot execute complex scripts on instances
AWS Systems Manager
Focuses on executing actions: patching, connecting, running commands
Primarily a management service (how do I fix it?)
Can run arbitrary scripts and commands on many instances simultaneously
SAP Solution Manager
Traditional, comprehensive tool for operations and change management
Designed for smaller to medium landscapes (up to ~50 SAP systems)
Includes a full IT service management module
SAP Focused Run
Modern, lightweight tool focused purely on monitoring and alerting
Designed for large landscapes (100+ SAP systems) with high scalability
Uses its own dedicated HANA database for fast analytics
Systems Manager Session Manager
No inbound ports required; communication is agent-outbound
Authentication and authorisation done through IAM policies
All session activity can be logged to CloudWatch or S3
SSH Access (Open Port 22)
Requires inbound port 22 to be open in the security group
Authentication via SSH keys, which must be managed and rotated
No automatic logging; requires separate tools like auditd
Mistake
CloudWatch can automatically restart a crashed SAP application service.
Correct
CloudWatch can detect a crashed instance via a status check alarm and automatically recover the EC2 instance, but it cannot restart a specific service like SAP's disp+work. For service-level restart, you need a Systems Manager document or a custom script triggered by a CloudWatch alarm.
Beginners assume any monitoring can fix any problem. They do not distinguish between host-level (EC2) and application-level (SAP) problems.
Mistake
You must open SSH port 22 to the internet to manage SAP servers on AWS.
Correct
AWS Systems Manager Session Manager lets you log into servers without opening any inbound ports. It uses the Systems Manager Agent (SSM Agent) installed on the instance and authenticates via IAM.
This mistake is common because in on-premises environments, SSH is the standard way to access Linux servers. The cloud paradigm shift to agent-based management is not obvious to beginners.
Mistake
SAP Solution Manager and SAP Focused Run are the same thing with different names.
Correct
They are different products. Solution Manager is the older, comprehensive platform for operations, monitoring, and change management. Focused Run is a newer, streamlined, high-performance monitoring tool for very large landscapes. They are not interchangeable.
SAP documentation uses overlapping terms. Beginners see both described as 'monitoring tools' and assume they are redundant offerings.
Mistake
If you set up a CloudWatch alarm on CPU, you do not need any other monitoring for an SAP system.
Correct
CPU is just one metric. SAP systems can fail due to database locks, full storage volumes (where disk metrics are separate), memory leaks in the application layer, or specific SAP transaction issues. You need a combination of CloudWatch metrics, SAP-specific alerts from Solution Manager, and custom metrics.
CloudWatch is the first tool people learn about, so they overestimate its coverage. They do not yet understand that SAP has its own internal health checks that cannot be replaced by generic OS-level measurements.
Mistake
AWS Systems Manager Patch Manager will automatically patch SAP without any service interruption.
Correct
Patch Manager patches the operating system. If the SAP services are running, a OS patch may require a reboot, which will stop SAP. You must use a Maintenance Window that includes steps to stop SAP services before patching and start them after.
The name 'Patch Manager' implies a simple 'click to patch' action. Beginners do not understand that patching the underlying OS affects the running application.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. CloudWatch monitors the infrastructure (CPU, memory, disk) but cannot see inside the SAP application to check for failed jobs, short dumps, or business process delays. SAP Solution Manager provides that application-level visibility. For the exam, think of them as complementary, not substitutes.
Yes. Session Manager works over an outbound connection initiated by the SSM Agent. The EC2 instance does not need a public IP or an internet gateway. It only needs outbound access to the Systems Manager endpoint (or VPC Endpoint). This is one of the key security advantages the exam tests.
A status check is a built-in, automatic test that checks if the EC2 instance and the underlying hardware are working. A CloudWatch alarm is a custom rule you define that watches a specific metric (like CPU) and takes an action when a threshold is crossed. Status checks can be used as a metric for a CloudWatch alarm.
AWS handles only the operating system and the hypervisor. Patching the SAP application (like applying an SAP kernel update or support package stack) is your responsibility. Systems Manager can help run the scripts, but you must provide the correct SAP patches and command sequences.
CloudWatch can trigger an action (like a Lambda function) based on an alarm, but it cannot directly execute commands on an instance. The typical pattern is: CloudWatch alarm triggers an SNS topic, which triggers a Lambda function, which uses Systems Manager Run Command to run an SAP start/stop script on the instance.
An SAP short dump is a program crash that stops the SAP application from processing further. On AWS, short dumps are not detected by CloudWatch. You must use SAP Solution Manager or Focused Run to be alerted, because they understand the SAP application log (transaction ST22).
You've finished SAP Operations on AWS: Monitoring and Management. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?