The AWS SAP on AWS Specialty (PAS-C01) validates your ability to design and deploy SAP workloads on AWS. SAP runs on some of the largest and most performance-sensitive enterprise infrastructure in existence — migrating it to AWS requires understanding both the SAP architecture (HANA, S/4HANA, NetWeaver, BW/4HANA) and the AWS services that support it. This exam is for infrastructure architects and SAP basis administrators who bridge both worlds.
Practice this topic
SAP workloads have specific hardware requirements. HANA in-memory database: SAP HANA requires certified hardware with very high memory-to-CPU ratios. AWS certified instances: x1e (up to 3.84 TB RAM — for large HANA scale-up), u-type (High Memory instances — up to 24 TB RAM for the largest HANA deployments), r6i and r7i (memory-optimised, up to 768 GB RAM — for smaller HANA instances). HANA scale-up vs scale-out: scale-up (single large instance, simpler, all data in one node's RAM — up to 24 TB with u-type), scale-out (multiple nodes with HANA shared memory — used when workload exceeds single-instance RAM). NetWeaver application servers: c5 or m5 instances, multi-AZ deployment for HA. Storage: SAP HANA requires EBS io2 Block Express volumes (up to 256,000 IOPS) for the data and log volumes — striping across multiple volumes with LVM for higher aggregate IOPS. Amazon FSx for NetApp ONTAP: supported SAP shared storage for transport directory, /sapmnt, and cluster fencing. EFS for shared NFS mounts.
SAP HANA HA uses HANA System Replication (HSR) — real-time log shipping between primary and secondary HANA nodes. HSR modes: synchronous in-memory (SYNC — zero data loss, secondary confirms before primary commits — use within same AZ for low latency), synchronous with logreplay (SYNCMEM — faster, secondary replays log after confirming — slight data loss risk under failure), asynchronous (ASYNC — secondary may lag primary — use for cross-region DR where sync overhead is too high). Pacemaker cluster: Linux HA cluster manages HANA and SAP virtual IP failover — STONITH fencing prevents split-brain (both nodes thinking they are primary). AWS-specific Pacemaker resources: aws-vpc-move-ip (moves the overlay IP to the surviving node's ENI), aws-vpc-route53 (updates Route 53 record to point to new primary). Overlay IP / Virtual Hostname: SAP application servers and clients connect to a virtual IP that floats between HANA nodes on failover — transparent failover without reconfiguration. For DR: use HANA HSR Tier 2 (multi-tier replication) — primary in Region A replicates to secondary in Region A (synchronous), secondary replicates to DR in Region B (asynchronous).
SAP migrations to AWS. Migration strategies for SAP: Homogeneous migration (same OS, same DB — backup/restore, SAP System Copy tool), Heterogeneous migration (different OS or database — required for moves to HANA from Oracle or DB2), SAP HANA Migration (database migration from AnyDB to HANA — use DMO (Database Migration Option) of SUM (Software Update Manager) — migrates and upgrades simultaneously, reduces downtime window). AWS Migration Hub: track SAP migration progress across accounts. AWS Backup for SAP HANA: native SAP HANA Backint interface — backups stored in S3 with point-in-time recovery. AWS Launch Wizard for SAP: automated guided deployment of SAP HANA, SAP S/4HANA, and NetWeaver — provisions instances, storage, networking, and HA configuration automatically based on sizing inputs. SAP on AWS certified configurations: SAP publishes certified cloud IaaS (AWS) configurations in the SAP Note 2456932 — refer to this note for supported instance types, storage configurations, and HANA memory limits. AWS runs SAP infrastructure on Nitro System bare metal — no hypervisor overhead for maximum HANA performance.
Any AWS instance can run SAP HANA
SAP HANA requires AWS-certified instance types that appear in SAP's product availability matrix (SAP Note 2456932). Running HANA on uncertified instances is unsupported by SAP and voids the support agreement. Instance certification depends on memory, CPU, and network specifications meeting HANA's minimums.
SAP HANA HA and DR are the same configuration
HA (High Availability) protects against component failures within a region — typically synchronous HSR between nodes in the same AZ or across AZs. DR (Disaster Recovery) protects against regional failures — typically asynchronous HSR to a different region. Both are needed for complete protection.
Try free AWS SAP Specialty practice questions with explanations, topic links and progress tracking.