# 13 – Select the optimal compute solution
**How do you select the optimal compute solution for your SAP workload?** Evaluate and estimate the performance requirements using metrics from the SAP tools and existing workloads. Map the compute requirements to the SAP supported instances best suited to your workload. Consider any specific storage or network requirements for the instance types as well as the availability of the required instance types in your chosen AWS Region and Availability Zones.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-13.html)
For more details, see the following information:
+ AWS Documentation: [Amazon EC2 Instance Types for SAP](https://aws.amazon.com/sap/instance-types/)
+ SAP Documentation: [Certified and Supported SAP HANA Hardware](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=v:deCertified;ve:23)
+ SAP Note: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products](https://launchpad.support.sap.com/#/notes/1656099) [Requires SAP Portal Access]
+ SAP Note: [1656250 - SAP on AWS: Support prerequisites](https://launchpad.support.sap.com/#/notes/1656250) [Requires SAP Portal Access]
# Best Practice 13.1 – Evaluate or estimate performance requirements
Future hardware requirements can be estimated by examining the capacity and usage patterns of existing SAP systems. SAP provides several tools for sizing hardware for new and existing systems. To further validate sizing estimates, proof of concept (POC) deployments and performance testing can be used.
**Suggestion 13.1.1 – Reference SAPS performance metrics of source hardware**
SAP benchmarks hardware using [SAP Application Performance Standard (SAPS)](https://www.sap.com/about/benchmark/measuring.html), which is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. Consult your existing hardware vendor and the SAP benchmark directory to obtain SAPS values for your on-premises server hardware.
A sizing based on SAPS is appropriate for a migration that introduces minimal changes to the underlying capacity requirements, often referred to as a lift and shift migration.
**Suggestion 13.1.2 – Reference SAP EarlyWatch Alert reports and monitoring tools for historical usage details**
[SAP EarlyWatch Alert](https://support.sap.com/en/offerings-programs/support-services/earlywatch-alert.html) reports provide utilization information of your SAP application, such as peak memory and CPU usage. A holistic analysis of these reports spanning several peak events, such as month-end closing and large batch loads, can provide valuable insights into system usage.
In addition to EarlyWatch alert reports, infrastructure level monitoring tools can provide more granularity and further insights.
**Suggestion 13.1.3 – Use SAP HANA sizing reports to estimate compute requirements**
When migrating to SAP HANA, use SAP provided tools for estimating the size of the target compute. The output generated by these tools details the hardware sizing requirements for your SAP HANA database.
+ SAP Documentation: [SAP HANA Administration Guide for HANA Platform](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/bdf26308bb571014b7bcd3bcd586aecd.html)
+ AWS Documentation: [SAP HANA Sizing](https://docs.aws.amazon.com/sap/latest/sap-hana/migrating-hana--.html)
+ SAP Note: [1793345 – Sizing for SAP Suite on HANA](https://launchpad.support.sap.com/#/notes/1793345) [Requires SAP Portal Access]
+ SAP Note: [1872170 – ABAP on HANA sizing report (S/4HANA, Suite on HANA...)](https://launchpad.support.sap.com/#/notes/1872170) [Requires SAP Portal Access]
+ SAP Note: [2296290 – New Sizing Report for SAP BW/4HANA](https://launchpad.support.sap.com/#/notes/2296290) [Requires SAP Portal Access]
+ SAP Note: [1958910 - EarlyWatch Alert For HANA Database](https://launchpad.support.sap.com/#/notes/1958910) [Requires SAP Portal Access]
**Suggestion 13.1.4 – Use SAP Quick Sizer for greenfield implementations and functional changes**
SAP Quick Sizer can be used for sizing new SAP implementations or for those undergoing changes (for example, increased user base, new functionality or modules). The tool helps you to translate your application’s requirements into hardware specifications. For best results, technical and functional teams should collaborate to input values into the Quick Sizer tool.
We recommend the use of SAP expert sizing to validate the sizing of complex implementations.
For more information on SAP tools and services, refer to the following:
+ SAP Documentation: [SAP: Sizing Benchmarks](https://www.sap.com/about/benchmark/sizing.html)
**Suggestion 13.1.5 – Use proof of concept deployments for sizing accuracy**
You can take advantage of the flexibility of AWS services to right-size your SAP workloads and scale as business demands change. Use proofs of concept (POCs) to test migrations to cloud and analyze the performance requirements. This can help right-size the workloads for both cost and performance.
# Best Practice 13.2 - Select EC2 instances suitable for SAP workloads
AWS works with SAP to ensure that AWS services are suitable to implement and operate SAP software across a wide selection of instance types. Use guidance from the relevant SAP notes and documentation to identify suitable instances. EC2 instance families offer different ratios of CPU and memory, as well as storage and network throughput characteristics suitable for running SAP workloads. Map your requirements to the appropriate instance type using performance metrics, SAPS figures, and compute estimates. Confirm availability of these instances in your selected Region and Availability Zone.
**Suggestion 13.2.1 – Follow SAP guidance on supported databases, operating systems, and AWS services**
AWS offers services that can be used for the deployment of SAP products. SAP Note: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products](https://launchpad.support.sap.com/#/notes/1656099) describes which SAP products, database and operating system combinations and Amazon EC2 instance types are currently supported.
You can determine the availability of individual instance types within a specific AZ using the AWS CLI [to describe instance type offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html).
+ AWS Documentation: [Amazon EC2 Instance Types for SAP](https://aws.amazon.com/sap/instance-types/)
+ SAP Documentation: [SAP NetWeaver benchmarks](https://www.sap.com/dmc/exp/2018-benchmark-directory/#/sd?filters=v:4a9e824336e2837bf9081e423d576dba)
**Suggestion 13.2.2 – Use hardware metrics and SAPS to guide selection**
Each SAP supported Amazon EC2 instance family provides a specific vCPU to memory ratio. You should evaluate each instance family based on your requirements to understand the performance profile. The current generation of Amazon EC2 instances (based on [AWS Nitro](https://aws.amazon.com/ec2/nitro/) ) offers the best performance and should be used if available and certified for the deployment scenario.
SAP application servers can use either the general purpose (`m*`) or memory optimized (`r*`) instances. Where there is a requirement for a higher vCPU to memory ratio, consider using compute optimized (`c*`) instances. For AnyDB database servers, memory optimized (`r*`) instances are a good fit for the required core to memory ratio, but additional analysis should be done to validate the sizing, especially if your deployment is subject to per-CPU licensing. For SAP HANA databases that run in memory, memory optimized (`r*`, `x*`, `u*`) are your only options.
**Suggestion 13.2.3 – Use SAP HANA hardware directory and memory requirement to select EC2 instances for SAP HANA**
AWS has SAP HANA certification for a subset of Amazon EC2 instances to run SAP HANA workloads. Details of these instances, and the IaaS application types supported (OLAP, OLTP, SAP Business One, Scale-Out) can be found in [Certified and Supported SAP HANA Hardware](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23) and [Amazon EC2 Instance Types for SAP](https://aws.amazon.com/sap/instance-types/).
Database size and actual working memory usage will determine the memory requirement and instance selection.
For non-production workloads, additional options exist. Refer to the blog:
+ SAP on AWS Blog: [Smaller X1e instances for SAP HANA non-production workloads](https://aws.amazon.com/blogs/awsforsap/smaller-x1e-instances-for-sap-hana-non-production-workloads/)
**Suggestion 13.2.4 – Be aware of EC2 instance features and throughput characteristics**
Amazon EC2 instances have different features and throughput characteristics which should be evaluated based on your use case, particularly for workloads with high I/O and throughput requirements. These include enhanced networking capabilities through the [Elastic Network Adapter (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html#ena-performance), I/O performance, Amazon EBS optimization, and suitability for placement groups. For a full list of features, see:
+ AWS Documentation: [General Purpose Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose-instances.html)
+ AWS Documentation: [Memory Optimized Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-optimized-instances.html)
+ AWS Documentation: [Compute Optimized Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/compute-optimized-instances.html)
# Best Practice 13.3 – Select architectures which allow for independent scaling of systems or components
SAP systems and components should have the flexibility to scale without being constrained. This might be accomplished within the allocated hardware or by using horizontal scaling of some components. Consider which architectures allow for this scaling and evaluate any associated trade-offs.
**Suggestion 13.3.1 – Consider cross-system or cross-component performance impact**
Isolate individual systems or components (for example, Central Services, application servers, and database) to avoid negative performance impact between components. Deploying multiple smaller instance sizes can provide options for instance reuse, workload-based scaling, and capacity on-demand. There are exceptions when trying to optimize the use of resources for cost reasons. Refer to the cost pillar for more details.
**Suggestion 13.3.2 – Consider capacity flexibility for peak performance**
By selecting architectures which allow for scaling of components, such as the application servers, it will be possible to adapt your capacity to match with performance requirements. This allows your SAP systems to scale for exceptional demand including month end processing or seasonal peaks.
# Best Practice 13.4 – Choose location to minimize latency
Deploy your SAP instances in Regions and Availability Zones that minimize latency for key business processes impacting end users, critical interfaces, and intra-system traffic.
**Suggestion 13.4.1 – Select Region and cloud connectivity to optimize performance**
Choose a Region based on proximity to your SAP end users and corporate data center. Select and size any cloud connectivity options (such as Direct Connect and VPN) to accommodate your data transfer requirements.
Use SAP performance tools to understand the breakdown of user response time (such as network, GUI, application, and database) and evaluate the impact of any changes to the network round trip time as a result of increased latency. We recommend you focus on high frequency, low latency interfaces between systems in different locations.
If increased latency impacts certain end user groups, consider the use of end user compute services and accelerators.
+ AWS Documentation: [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ AWS Documentation: [What is AWS Global Accelerator? - AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ SAP on AWS Blog: [Deploying SAP GUI on Amazon AppStream 2.0](https://aws.amazon.com/blogs/desktop-and-application-streaming/deploying-sap-gui-on-amazon-appstream-2-0/)
**Suggestion 13.4.2 – Be aware of SAP guidelines for intra-system latency**
SAP provides guidance for acceptable network latency for two traffic patterns: between SAP application servers and the database, and between SAP HANA database servers (primary and secondary) for the purposes of data replication. AWS regional networks generally meet or exceed these requirements.
**Network Latency between SAP application servers and database (Pattern 1)**
The following SAP guidance for database to application server connectivity is based on systems running in a single data center, which does not reflect the resiliency benefits of a Multi-AZ deployment. An Availability Zone is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region separated by a meaningful distance (at least 10km).
Resilient SAP architectures in AWS typically involve deploying infrastructure across multiple AZs, including SAP application server and database instances.
If you have SAP transactions or batch jobs with time-critical performance requirements and that make a significant number of database calls, we recommend that you run these jobs on SAP application servers located in the same AZ as the database. This can be achieved by using SAP Logon Groups (transaction SMLG) for end users and a batch server group (transaction SM61) for background processing jobs. This helps ensure that the latency sensitive parts of the SAP workload run on application servers with the lowest latency to the database. Use tools such as NIPING to measure latency.
+ SAP Note: [1100926 - FAQ: Network performance](https://launchpad.support.sap.com/#/notes/1100926) [Requires SAP Portal Access]
+ SAP Note: [2543171 - Latency issue between application server and database](https://launchpad.support.sap.com/#/notes/2543171) [Requires SAP Portal Access]
**Network Latency between SAP HANA primary and secondary servers (Pattern 2)**
The network latency between the primary and secondary instances will be a factor in the redo log shipping wait time. For synchronous replication, SAP recommends that this wait time should be in the low single millisecond range. This requirement can be achieved across AWS Availability Zones. Use tools such as NIPING to measure latency.
+ SAP Documentation: [SAP HANA system replication network requirements](https://www.sap.com/documents/2016/06/18079a1c-767c-0010-82c7-eda71af511fa.html)
**Suggestion 13.4.3 – Use placement groups for SAP HANA scale out**
To meet the SAP certification for internode communication in an SAP HANA scale-out deployment, it is necessary to use a cluster placement group.
+ AWS Documentation: [Placement groups - Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-cluster)