

# 4 – Validate and improve your SAP workload regularly
<a name="design-principle-4"></a>

 **How will you validate your SAP workloads continue to operate efficiently?** Aim to improve your SAP workload regularly and take advantage of new service releases from AWS. Dedicate time and resources to maintain your SAP workload. Aim for continual incremental improvement to evolve the efficiency of your SAP workload. Plan to patch, make small changes and re-evaluate previous design decisions with corrective actions which improve performance, resilience or cost effectiveness. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-4.html)

# Best Practice 4.1 – Understand and plan for lifecycle events of your SAP workload
<a name="best-practice-4-1"></a>

 SAP workloads are highly reliant on SAP to provide new software and vulnerability patching, operating system and database kernels, and escalation for support. SAP regularly publishes information about SAP software releases: Release types, maintenance durations, planned availability, and upgrade paths in their [Product Availability Matrix (PAM)](https://support.sap.com/en/release-upgrade-maintenance.html) and SAP Notes. You should obtain specific details each of your SAP applications and track these locally to understand if your SAP software is current, supported and when it will be end of life from a maintenance perspective. 

The PAM also offers information about platform availability and compatibility: including database platform and operating systems supported which should guide you in patching and upgrading these underlying components of your SAP workload. Operating System vendors also have their own patching and support lifecycle which should be taken into account when planning SAP maintenance and lifecycle events such as upgrades.

 **Suggestion 4.1.1 - Create an operational roadmap for your SAP applications taking into account key support and lifecycle dates** 

 List all of your SAP software applications, kernel versions. operating systems, and database versions in a central register and consolidate with PAM information on supported versions and maintenance windows. Use this list as a consolidated view to plan patching, upgrades and platform changes in all components required to keep SAP current and within support. 
+  SAP Documentation: [SAP Release & Maintenance Strategy: Product Availability Matrix](https://support.sap.com/en/release-upgrade-maintenance.html) [Requires SAP Portal Access] 

 **Suggestion 4.1.2 - Maintain a calendar for expiring of credentials, certificates and licenses** 

 Alongside the major SAP lifecycle events and patching mentioned previously, ensure you have an operational calendar which plans minor system events. Examples of these maintenance events could be expiry of system credentials, expiry of certificates (for example, for STRUST integration between systems) and any license renewal work or updates required (for example, temporary SAP or database licenses for migration, development or POC purposes). 
+  AWS Documentation: [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) 

 **Suggestion 4.1.3 - Plan for upgrades or alternatives before SAP software becomes end of life** 

 Create an SAP landscape roadmap visualizing your key SAP lifecycle events and operational upkeep - patching, software upgrades, migrations and re-platforming if required. Communicate this lifecycle calendar to business and technical stakeholders. Plan investment to fund these SAP lifecycle activities/projects. Plan in advance with your business stakeholders where maintenance windows can occur and downtime or restarts will be required. 
+  SAP Documentation: [SAP Roadmap Explorer](https://www.sap.com/products/roadmaps.html) 

 **Suggestion 4.1.4 - Stay up to date and subscribe to key SAP notes for support advice** 

 Subscribe to key SAP notes and Knowledge Base Articles (KBAs) for your SAP workload such that you will be notified upon any changes or updates to supportability and advice. Use “Favorite” SAP notes functionality to keep a list of frequently accessed and important notes for your SAP workload to make them easily accessible and comparable. 
+  [SAP Support Portal - Favorite SAP Notes](https://launchpad.support.sap.com/#/mynotes?tab=Favorites) [Requires SAP Portal Access] 

# Best Practice 4.2 – Regularly perform patch management for software currency
<a name="best-practice-4-2"></a>

Perform regular patch management to gain features, address issues, and remain compliant with governance. Consider patches at the operating system, database and SAP application layer. Understand whether your patching process will be to patch your existing servers, or provision and patch a new server. Automate patch management to reduce errors caused by manual processes, reduce the level of effort to patch and reduce the application downtime required for major SAP, database, and kernel patching.

 **Suggestion 4.2.1 - Implement SAP patch management procedures to regularly review SAP Security Notes and newly released patches** 

Consider patches at the operating system, database and SAP application layer.
+  AWS Documentation: [AWS Security Bulletins](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc) 
+  SAP Documentation: [SAP EarlyWatch Alert](https://support.sap.com/en/offerings-programs/support-services/earlywatch-alert.html) 
+  SAP Documentation: [SAP Security News](https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html) 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-4-2.html)

 For further discussion on this item see [Security]: [Best Practice 6.2 - Build and protect the operating system](best-practice-6-2.md). 

 **Suggestion 4.2.2 - Consider automated tools to align and automate patches across your SAP landscape** 

 Tools such as AWS Systems Manager and OpsWorks can assist you to align, plan, test, and deploy patching across your SAP workload. Consider an automated approach to patching to minimize effort and maintenance windows.
+  AWS Documentation: [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html?ref=wellarchitected) 
+  SAP Lens [Security]: [Best Practice 6.2 - Build and protect the operating system.](best-practice-6-2.md) 

# Best Practice 4.3 – Regularly test business continuity plans and fault recovery
<a name="best-practice-4-3"></a>

SAP systems are generally business critical and depended upon for major customer facing transactions. Enabling the quick resumption of IT operations and minimizing data loss during a fault or disaster situation is critical for operational excellence. Business continuity plans (BCP) and fault recovery procedures are required to ensure that your operations team and systems know what to do, when to do it, and workload service can be resumed promptly in case of a fault.

Critical to the successful resumption of services is that your BCP procedures and fault recovery plans are regularly tested, improved upon and refined as your systems and support team evolves. Testing your BCP and recovery plans outside of real crisis situations ensures that when a real system fails or disaster does occur, you can be confident in your ability to successfully resume service and that you will meet your recovery time objective (RTO) and recovery point objective (RPO).

 **Suggestion 4.3.1. - Create a BCP and fault recovery testing calendar** 

Create a calendar which schedules regular (at least annually) BCP and fault scenario recovery testing for your SAP workload. Involve technology operational teams, support personnel and business stakeholders in this test so that procedures are understood and expectations are aligned. Aim to test your systems in as real a situation as possible.

 Consider testing the following scenarios and validating recovery metrics for each of them: 
+ SAP application service failure

   *(for example, SAP application service fails to start due to a configuration change)* 
+ Single instance host failure

   *(for example, SAP application server EC2 instance becomes unreachable)* 
+ Single storage volume failure

   *(for example, a single EBS volume becomes unreachable)* 
+ Network failure and switch over to redundant connection

   *(for example, your on-premises Direct Connect connection is unreachable)* 
+ Automated failover between primary and secondary clustered components

   *(for example, SUSE HAE cluster forces primary HANA database to move to the secondary database in an alternate Availability Zone)* 
+ Manual fail over between primary and secondary components

   *(for example, manual invocation of Oracle DataGuard switch over to secondary database in an alternate Availability Zone)* 
+ Load balancing between multiply redundant components

   *(for example, primary web dispatcher fails in a high availability pair across Availability Zones)* 
+ Recovery of your SAP application in an alternate AWS Region (if required)
+ Recovery from backup in event of ransomware

   *(for example, recovering your entire SAP ERP system from Amazon S3 WORM backup)* 

 **Suggestion 4.3.2 - Regularly review and update BCP and fault recovery procedures as part of workload changes** 

 As your workload evolves and changes over time, ensure that BCP and recovery procedures are considered in these changes. When a code or infrastructure change might affect your RTO or RPO, ensure that documentation and configuration is updated, and the new BCP and recovery process is tested as part of the release process or regular test calendar. 
+  AWS Documentation: [Business Continuity Plan (BCP) Definition](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html) 
+  AWS Documentation: [Architecture Guidance for Availability and Reliability of SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) 
+  SAP Lens [Reliability]: [Best Practice 11.4 - Conduct periodic tests of resilience](best-practice-11-4.md) 

# Best Practice 4.4 – Perform regular workload reviews to optimize for resiliency, performance, agility, and cost
<a name="best-practice-4-4"></a>

When running SAP on AWS, plan and dedicate time and resources for continual incremental improvement to evolve the effectiveness and efficiency of your workload. AWS regularly releases new services, approaches, improved SLAs, and price reductions that you can take advantage of to optimize your SAP workload. Understand and validate whether new service releases are applicable to your SAP workload and, where appropriate, implement them in your production environment to evolve your workload.

 **Suggestion 4.4.1 - Plan regular reviews of your SAP workload** 

Work with your AWS team, AWS Partner, or internal experts to periodically review your SAP workload using the Well-Architected Framework SAP Lens (this document). Plan to review your workload at least every once a year. Identify, validate, and prioritize improvement activities and issue remediation and incorporate this into your backlog.

Consider harvesting your learnings from operational incidents into curated questions with best practices guidance. Create Operational Readiness Review (ORR) runbooks to assist when deploying new SAP landscapes, applications, or workloads.
+ AWS Whitepaper (this document): [SAP Lens for Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/sap-lens.html)
+ AWS Whitepaper: [Operational Readiness Reviews (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)

 **Suggestion 4.4.2 - Review Amazon EC2 instance sizing and performance** 

Review the CPU usage and memory utilization of your SAP workload by validating historical CloudWatch metrics. Review each SAP component for low CPU or memory utilization and consider right sizing EC2 instances to better match workload requirements. Consider newly released and SAP-certified EC2 instance types for performance fit and cost optimization. Plan to take advantage of new improvements in your operational backlog.

 See [Cost Optimization](cost-optimization.md) for Amazon EC2 usage in SAP workloads. 
+  AWS Documentation: [Amazon EC2 instance types for SAP](https://docs.aws.amazon.com/sap/latest/general/ec2-instance-types-sap.html)

 **Suggestion 4.4.3 - Review Amazon EBS sizing and performance** 

 Review storage usage across your SAP workload by validating volume consumption, throughput and IOPS usage from CloudWatch historical metrics. Review each SAP component for oversized storage or low throughput/IOPS utilization and consider right sizing Amazon EBS storage sizes and types in order to better match workload requirements. Consider newly released and SAP certified Amazon EBS types for performance fit and cost optimization. Plan to take advantage of new improvements in your operational backlog 
+  AWS Documentation: [Right Sizing](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/) 
+  SAP Lens [Cost Optimization]: [Best Practice 18.4 - Evaluate the cost impact of storage options based on the required characteristics](best-practice-18-4.md) 

 **Suggestion 4.4.4 - Review new services that improve agility or improve efficiency in your SAP workload operations** 

Review new supporting service releases that could improve operations in your SAP workload. If you have a technical account manager (TAM) as part of an AWS Support agreement, they can assist you in a new service briefing and optimization discussion.

Consider new releases such as shared file storage, interface services (for example, AWS Transfer, API Gateway), security services (for example, Amazon GuardDuty, AWS Firewall), backup tools (for example, AWS Backint) and automation tools (for example, Launch Wizard for SAP).

 Plan to take advantage of new improvements in your operational backlog. 
+  AWS Documentation: [“What’s New” Feed](https://aws.amazon.com/new/) 
+  AWS Documentation: [Proactive Services from Support](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) 

 **Suggestion 4.4.5 - Monitor SAP on AWS blogs and announcements** 

 Consider subscribing to the SAP on AWS Blog feed and AWS “What’s New” feed to stay up to date with newly released service announcements, innovation approaches and price reductions. 
+  [SAP on AWS Blog Feed](https://aws.amazon.com/blogs/awsforsap/) 

 **Suggestion 4.4.6 - Plan periodic enhancement work to take advantage of new and improved AWS services** 

Ensure that your operational budget allows for planned support team effort for implementation and testing of new AWS services and workload evolution on a periodic basis.