Best Practice 10.2 – Select an architecture suitable for your availability and capacity requirements

There are standard architectural patterns for SAP availability to suit the requirements of most customers deploying SAP on AWS. Use the following suggestions to determine what patterns best meet your availability and capacity requirements. Evaluate the risk and impact of each failure scenario against your business requirements.

Additional information on availability in SAP can be found in the whitepaper Architecture Guidance for Availability and Reliability of SAP on AWS.

Suggestion 10.2.1 – Identify all components and AWS services that are required for your SAP system

Identify all the required technical components of your SAP system, starting with the core (database, application servers, central services, global file systems) and extending to optional components (for example, Web Dispatchers, SAProuter, Cloud Connector). Determine the required AWS services to support these components and review the shared responsibility model for resiliency.

Suggestion 10.2.2 – Use SLAs, durability, availability, and historical data as a guide to the likelihood of failure

Likelihood of failure is subjective. Published service level agreements (SLAs) and past performance can only be used to guide the risk of potential future failure. However, the assumed frequency of various scenarios remains a useful data point. Something which is statistically likely to happen once a year might have a greater impact on design decisions than a failure that is yet to occur.

The following information can be used to better understand the services:

The likelihood of failure of other supporting services should also be evaluated including, but not limited to, domain name services, load balancers, and serverless functions.

More information can be found in the Architecture Guidance for Availability and Reliability of SAP on AWS whitepaper.

Suggestion 10.2.3 – Assess options for clustering, resilience, and load balancing

An SAP system can be distributed across multiple hosts, with differing mechanisms for ensuring availability. For example, a clustering solution can be used to protect single points of failure (for example, the SAP database and SAP Central Services). The SAP application tier can be scaled horizontally and load balancing can be used to make the web dispatcher highly available.

Suggestion 10.2.4 - Determine the availability of EC2 instance families within Availability Zones

Some Amazon EC2 instance families (for example, X and U) are not available across all AZs. Check with your AWS account team or AWS Support to confirm that the EC2 instance families you want to use are available in the intended Availability Zones. Note that the logical AZ identifiers might be different across different accounts. See the AWS documentation for more information.

Suggestion 10.2.5 – Investigate strategies for ensuring capacity

The best way to help ensure capacity is to have a similarly sized instance available in case of failure. Other strategies include cloud native options (for example, On-Demand Instances, EC2 instance recovery) or re-allocating shared capacity.

We recommend that you make a capacity commitment in at least two AZs for Amazon EC2 instances that support SAP single points of failure so that the capacity is available at the time you need it.

Amazon EC2 capacity can be reserved using Zonal Reserved Instances or On-Demand Capacity Reservations. Both Zonal Reserved Instances and On-Demand Capacity Reservations can be shared between AWS accounts within the same AWS organization, which allows for the approach of using sacrificial capacity from another environment in the event of significant failure (for example, a complete AZ failure).

Further guidance on capacity reservations is available in:

Suggestion 10.2.6 – Design your VPC across multiple Availability Zones

Design your VPC and subnets to ensure that instances can be provisioned in multiple Availability Zones, even if your initial design only relies on one or two AZs. This builds resilience into your design and helps ensure that connectivity and access to services can be confirmed in advance.