AWS Certified: SAP on AWS – Specialty (PAS-C01) was an advanced credential for professionals who designed, migrated, implemented and operated SAP workloads in AWS environments. The exam is no longer available: AWS retired the certification on April 30, 2024, and April 29 was the last testing day. This article preserves the knowledge model behind PAS-C01 without presenting retired exam preparation or an unavailable appointment as a current offering.
SAP workloads place demands on cloud infrastructure that differ from an ordinary stateless web service. Enterprise transactions, database recovery, certified operating system combinations, predictable performance and tightly controlled change windows all shape the design. Learning how those requirements map to AWS remains worthwhile regardless of whether a historical specialty badge can be newly earned.
What PAS-C01 represented
The original specialty measured the ability to design SAP solutions, migrate existing landscapes, implement workloads, and operate them in AWS. Those responsibilities required deeper understanding than a catalogue of instance types. They joined knowledge of SAP architecture with networking, data protection, storage behavior, account permissions and operational resilience.
The former test domain grouping is useful as historical curriculum, but an old domain percentage or exam-preparation product is not evidence that the certification remains active. AWS announced the SAP on AWS retirement alongside the retirement of Data Analytics and Database Specialty credentials in 2024. SAP-focused technical learning continued separately.
A good historical study exercise begins with one landscape: a transaction-critical SAP application, a database, external partners, a directory service and a reporting system. Trace which components store state and which can restart independently. This distinguishes actual system availability from the number of cloud resources shown as healthy in a diagram.
Supportability and sizing before implementation
Begin with the SAP Product Availability Matrix and current AWS guidance for supported SAP application releases, databases, operating systems and cloud instance families. A virtual machine with large nominal capacity is not necessarily certified for the intended configuration. The architecture review must connect sizing and performance to the permitted combination rather than guess from vCPU counts.
Memory, I/O throughput, storage latency, network behavior and transaction concurrency can all become limits. Measure a representative business workload instead of applying generic database benchmarks. For a stateful ERP workload, a storage change that looks economical in isolation might extend transaction time or backup windows beyond accepted operational targets.
A support plan should identify who owns each dependency. AWS infrastructure, guest operating system, database engine and SAP application layers may involve different support channels and change responsibilities. A failover runbook must state how those teams coordinate when performance is degraded but an instance remains technically available.
High availability and disaster recovery solve different risks
A high-availability design aims to preserve operation through selected component failures. A disaster-recovery plan addresses a broader disruption and sets recovery time and recovery point objectives. Duplicating application nodes without protecting the database and identity systems can leave a workload unavailable despite attractive infrastructure redundancy.
For instance, a replicated database may be reachable after a primary failure while integration services are still bound to an obsolete endpoint. A recovery test should validate real user logon, posting a transaction, batch jobs and connectivity to dependent services, not merely demonstrate successful EC2 status checks.
Failover across Availability Zones and recovery into a different AWS Region offer different fault-domain protection and cost profiles. The architect must also consider data consistency, network routing, replication lag, licensing and operational approval. A drawing with two Regions does not establish that the business can actually resume.
Migration planning starts with cutover constraints
A migration plan needs a discovered inventory, data size, application and database versions, dependencies, allowable downtime, consistency rules and a realistic fallback option. Homogeneous system copy, database migration and application modernization are different changes with different test criteria. Choosing a migration tool before specifying the cutover scenario risks solving the wrong problem.
Large initial datasets may be seeded ahead of time, but the final cutover still requires a way to handle transactions arriving during the transition. Define a freeze or synchronization approach, rehearse final validation, and decide who may declare that the old production environment is no longer authoritative.
The team should test common failure cases: an unfinished job, a missing interface message, unexpected character encoding, an unlicensed dependency or a service that starts with stale connection information. A rollback is useful only if the data consistency and business consequences of reverting are understood.
If moving between clouds is under consideration, the trade-offs in SAP on AWS and SAP on Azure can add context. It is not enough to compare brand names: supportability, skill availability, migration cost, regional requirements and operating procedures determine which platform serves the business.
Security includes SAP and AWS authorization boundaries
The cloud account, operating system, SAP application and database each have distinct administrators and permissions. An IAM role can restrict access to an AWS service without limiting what a privileged SAP user can do inside the application. Conversely, strong application permissions do not protect a storage object from overbroad AWS account access.
An architecture should describe network segmentation, encrypted transfers, secrets management, backup integrity and logging at the right layer. AWS CloudTrail records AWS API activity but does not replace application-level financial or SAP security audit trails. Each evidence source needs an owner and a retention policy aligned with the system’s requirements.
Automated deployment identities should be constrained to the actions they genuinely need. A service role used to fetch a backup must not accidentally have unrestricted infrastructure deletion permissions. Review privileged access especially around maintenance windows and recovery, when temporary exceptions can be overlooked.
Operations determine whether the architecture stays reliable
An SAP on AWS operating model includes patch approvals, database health, storage capacity, backup verification, log correlation, access review and response to business incidents. Monitoring thresholds should reflect transaction and workload outcomes, not only generic instance metrics. An alarm with no response owner is incomplete protection.
For a sample operational runbook, record the dependency order for recovery, expected point and time objectives, relevant dashboards and logs, primary support contacts, rollback decision and confirmation transaction. Rehearse the runbook under controlled failure conditions. Capture what broke, why, and which steps depended on knowledge that was not in the document.
Infrastructure as code can make configuration repeatable, but it must handle secrets, drift and release safety. Cloud automation is not inherently compliant simply because it produces consistent resources. A valid production model pairs version control and approval with observed configuration and operational evidence.
Worked architecture review: a critical SAP database recovery
Assume a manufacturing company hosts a transaction-critical SAP system in one AWS Region. The application tier uses several instances, but its database and interfaces have stricter recovery requirements. A plan that adds application instances without examining database replication will not meet a meaningful availability objective. Start by identifying the supported SAP and database topology, business-critical transactions, external connections and the failure scope the design must survive.
Set recovery time and recovery point targets as distinct requirements. A low recovery-time target means a team needs a rapid and tested failover process; a low data-loss target requires consistent replication or recovery records appropriate to the database. Neither property can be inferred from the number of cloud zones alone. Confirm whether a failover creates changed endpoints, authentication dependencies or a backlog in integration messages.
Run a controlled exercise that interrupts the assumed primary path. Observe how application servers recover connectivity, whether users can authenticate and whether a known set of SAP transactions remains consistent. Include a background job and an external interface because these often depend on state or endpoints not shown in the simplest architecture diagram. Record the actual elapsed time rather than a projected objective.
After restoring operation, confirm that the new topology can receive backups and monitoring and that privileged accounts used during emergency repair are reviewed. A recovery design is incomplete if the first incident leaves the organization running permanently on an unmonitored exception. Define the criteria to return to the preferred architecture and the steps needed for a second failure during that period.
This exercise exposes the continuing value of the historical PAS-C01 focus. The strongest answer is not a brand-specific checklist: it is a traceable relationship among supported architecture, data consistency, access dependencies, failure-domain isolation and proof of recovery under the business constraints.
The SAP on AWS path after the retired exam
An individual who earned PAS-C01 can describe the historical award accurately. Someone learning today should use the current AWS certification catalog for an active credential and current SAP/AWS product documentation for implementation. Do not assume that a newer unrelated exam replaces PAS-C01 one for one.
Historical PAS-C01 practice scenarios may still illustrate sizing, migration or recovery choices when clearly labeled as legacy material. They should not be presented as validated questions for an active SAP specialty test.
The enduring lesson is that enterprise workload migration is a dependency and evidence problem. The most reliable architect explains which configurations are supported, how business transactions are protected and how the organization will recover from the failure it most needs to withstand.