The AWS Certified: SAP on AWS – Specialty examination, PAS-C01, is a historical certification rather than an active registration option. AWS announced its retirement in 2024; April 29, 2024 was the last day to sit the exam and AWS described the credential as retired effective April 30. An article inviting a candidate to book PAS-C01 in 2026 would therefore misdirect the reader. The underlying skills still matter, however, because teams continue to design, migrate, secure and operate enterprise SAP landscapes on AWS. This updated roadmap preserves the technical learning purpose of the original article while separating retired exam requirements from present-day professional development.
There are also two different certification organizations in this conversation. AWS previously offered PAS-C01 to assess the ability to run SAP on its infrastructure. SAP itself maintains a distinct certification portfolio covering SAP products and roles, with its own assessment and renewal policies. Earning an SAP-issued credential is not the same as passing an AWS specialty test, and studying AWS architecture does not automatically qualify someone for SAP professional certification. Candidates should decide whether they need SAP application administration, cloud infrastructure design or a blended operations role before choosing an active credential.
What PAS-C01 Used to Assess
The retired PAS-C01 guide described an experienced target candidate who could design, implement, migrate and operate SAP workloads on AWS in line with both AWS architecture guidance and SAP support requirements. Its content was not an introduction to cloud terminology. Scenarios could require knowledge of SAP Basis, NetWeaver, SAP HANA, supported operating systems, database migration tools, sizing, access controls, availability and recovery. A newcomer could use those topics as a skill map, but the historical exam blueprint should not be mistaken for a current exam specification or reused as a current booking checklist.
The central competence remains systems thinking. An SAP landscape has application services, data tiers, identity, network routing, operational schedules and business-critical integrations. Choosing an instance family without confirming SAP and operating-system support is not enough. Neither is copying an arbitrary reference topology from a blog. The decision process must reconcile SAP sizing guidance, permitted deployment patterns, application version dependencies and measurable service-level objectives. The article on SAP workloads on AWS can provide broader architecture context, while current AWS and SAP support documents remain the authority for specific combinations.
Begin With SAP and Operating-System Foundations
A practitioner moving from general AWS knowledge into SAP infrastructure should first map the actual SAP components. Understand which systems support development, quality assurance and production; how the database connects to application servers; where central services and shared file systems reside; and which dependencies determine successful startup and recovery. Review SAP HANA memory sizing, storage throughput requirements, backups, system-copy tools and the difference between a database recovery and a complete business-service recovery. These fundamentals make cloud component choices intelligible rather than arbitrary.
Supportability is more restrictive than technical possibility. An EC2 instance may have enough CPU and memory to launch software but still be unsuitable for a particular SAP product, database, operating system or support arrangement. Check current SAP-certified instance types and supported software versions rather than assuming every large instance will qualify. For SAP HANA, capacity and storage decisions must consider memory, data durability, logging, backup throughput and recovery objectives. A proof-of-concept can explore performance, but it does not replace approval of the production support matrix.
The operating-system layer also matters. Teams need procedures for hardening, patching, time synchronization, host naming, storage mounts, monitoring agents and service restarts. Changes must respect application downtime restrictions and the relationship between SAP application components. Work that seems routine for a stateless web server—replacing a node, rotating credentials or rebuilding an image—may involve more careful sequencing in a stateful enterprise landscape. A learning lab should document the safe order of operations as well as the commands used.
Translate Requirements Into AWS Architecture
Begin with availability and recovery requirements, not a preferred product list. Ask how much disruption the organization can tolerate, what amount of data loss is acceptable, which locations are permitted to host regulated records, and how quickly a tested recovery environment must become operational. Recovery time and recovery point objectives represent distinct operational limits. A multi-AZ design may reduce certain infrastructure failures but does not by itself guarantee application-consistent backups or cross-Region disaster recovery. Define exactly which component and business process each objective covers.
Networking establishes another boundary. A deployment may need routes between on-premises users, identity providers, partner systems and the AWS VPC. Size address ranges, inspect overlaps with existing networks, select private connectivity where required and identify DNS dependencies. Security groups, subnet routing and endpoint policies must permit necessary communication without opening an unrestricted management path. Test whether a recovery exercise still has access to licenses, authentication services, naming infrastructure and external interfaces, not just a running database.
Identity needs separate analysis for human administrators, service principals and machine-to-machine integrations. Use AWS IAM to govern cloud API access and SAP’s appropriate identity and role controls to govern business application actions. The existence of an IAM role does not automatically authorize a user to post financial documents in SAP. Key management, audit records and access recertification likewise cross several boundaries. Document the actual control owner for each layer instead of claiming one cloud feature makes the entire application compliant.
Learn Migration Methods Without Promising Universal Downtime
A migration method depends on source architecture, operating system, database, data volume and permitted interruption. SAP HANA backup and restore may be appropriate in some same-platform scenarios; system copy, export/import or tools such as Software Update Manager with Database Migration Option can address different source and target combinations. These are not interchangeable recipes. Verify prerequisites, compatibility, recovery sequencing and supported use cases in current SAP and AWS technical guidance before selecting a path.
A credible migration plan includes discovery, target sizing, dry runs, interface reconciliation, cutover rehearsal, data checks, operational acceptance and a reversal decision. The business owner must understand what happens to transactions during the cutover window. Maintain evidence of source state and mapping between systems so data integrity can be checked after transition. An estimated duration is a hypothesis until tested with realistic data volume and network conditions. Marketing claims of zero downtime should never be substituted for a measured and approved outage strategy.
Migration can also be an opportunity to remove obsolete dependencies, but modernization creates its own validation burden. Separating an interface from a legacy host, changing authentication flow or moving a scheduled job can affect transaction consistency and batch-processing calendars. Sequence such improvements only when the business risk is understood. Distinguish a largely unchanged relocation from an application transformation; they require different test plans, stakeholder approvals and skills. Engineers should be able to explain why a safer staged approach was selected over an impressive but unproven all-at-once move.
Operate the Platform After Go-Live
An SAP cloud design is incomplete without a runbook for everyday operations. Establish responsibilities for SAP application monitoring, operating-system and infrastructure signals, database backups, certificate rotation, security patching and scheduled maintenance. Test that alerts identify the business service and the affected dependency rather than producing hundreds of unrelated host metrics. Production change windows need application-aware rollback criteria. A successful deployment ends when the organization can sustain its service objectives, not when a new EC2 instance first becomes reachable.
Performance tuning should use measurements from the actual workload. Observe transaction response time, memory utilization, database latency, backup duration and batch-job completion across meaningful business cycles. Scale compute only after distinguishing capacity constraints from poorly tuned queries, blocked interfaces or application defects. Review AWS cost allocation and SAP software licensing separately: cloud infrastructure cost models do not automatically include application entitlements. Use current product pricing and approved capacity plans rather than quoting an unsupported guaranteed saving from migration.
A recovery exercise should verify that business users can perform a representative transaction after recovery, with correct authorizations, integrations and data state. A dashboard that says every host is up is not sufficient evidence. Record observations, unresolved issues and changes required before the next test. This operational evidence can form a useful portfolio for an engineer: it shows a capacity decision, an incident diagnosis and a validated recovery path instead of a claim based solely on course completion.
Choose an Active Learning Route, Not a Retired Booking
For a general cloud architect responsible for SAP infrastructure, a currently offered AWS architecture credential may complement hands-on SAP knowledge, but it does not recreate the discontinued PAS-C01 designation. For an SAP Basis or SAP application role, the appropriate SAP Learning certification and current product learning plans may be more directly relevant. Compare the scope of each present-day credential with the duties in the job description. Always check the issuer’s live catalog, version and renewal rules; do not use a historical PAS-C01 schedule or test fee to make a 2026 registration decision.
Historical material can be valuable when labeled correctly. The retired PAS-C01 technical scope is useful as a retrospective list of SAP-on-cloud competencies, not an active exam registration path. A comparison of SAP on AWS and SAP on Azure can still help a professional articulate cross-platform considerations, but the correct choice still depends on organizational requirements, certified solution combinations and the expected operating model.
A deliberate learning project can begin with an architecture diagram and support matrix, continue to a restricted proof-of-concept and end with recovery evidence. In a training environment, describe why certain subnets are private, how administrative access is controlled, what data is backed up and which SAP components are recovered first. Practice estimating a cutover window with measurement, not optimism. Publish anonymized design rationales and failure analyses rather than sensitive system details. These artifacts demonstrate the type of judgment the retired exam was intended to reward.
How to Evaluate Preparedness
Instead of asking whether an old mock exam score predicts certification, test whether you can defend real technical decisions. Can you distinguish SAP-supported infrastructure from superficially compatible instances? Can you explain how the system behaves during an Availability Zone disruption, a failed database restore, an identity-provider outage or a network route change? Can you identify the owner who must approve each recovery step? These questions expose knowledge gaps that can be addressed with issuer documentation, a lab and review with an experienced SAP platform engineer.
Preparation is especially effective when each scenario includes evidence of both success and failure. For example, a restore may complete technically while a downstream integration remains inaccessible. Document the difference between infrastructure recovery and business service recovery. Trace the symptoms to a specific dependency; correct the configuration; and rerun a narrow acceptance test. The resulting analysis teaches far more than memorizing a static collection of retired exam questions.
The accurate 2026 conclusion is that AWS Certified: SAP on AWS – Specialty is no longer offered, but designing and operating SAP on AWS remains a substantive specialization. Professionals should preserve the old blueprint only as historical context, verify present-day issuer pathways, and invest in support-aware architecture, migration rehearsal, security boundaries and operational recoverability. That combination respects the original topic while providing readers with a useful path that does not rely on a discontinued examination.