SAP S/4HANA on AWS Elastic Compute Cloud – Deployment

Bögelsack, André; Chakraborty, Utpal; Kumar, Dhiraj; Rank, Johannes; Tischbierek, Jessica; Wolz, Elena

doi:10.1007/978-1-4842-8158-1_5

André Bögelsack⁷,
Utpal Chakraborty⁸,
Dhiraj Kumar⁸,
Johannes Rank⁹,
Jessica Tischbierek¹⁰ &
…
Elena Wolz¹¹

934 Accesses

Abstract

SAP S/4HANA is SAP’s modern ERP solution that is powered by in-memory database HANA and is in the core of mission-critical digital business of most big enterprises across the globe. The HANA database which is in the heart of this digital business runs in its full potential when hosted on purpose-built hardware for harnessing its power. And this is one of the reasons SAP has the SAP Integration and Certification Center (SAP ICC) that tests and certifies Infrastructure-as-a-Service (IaaS) platforms, along with other certifications like the storage solution that supports SAP HANA. The list of certified and supported SAP HANA Hardware can be referenced at

Access provided by Autonomous University of Puebla. Download chapter PDF

SAP S/4HANA is SAP’s modern ERP solution that is powered by in-memory database HANA and is in the core of mission-critical digital business of most big enterprises across the globe. The HANA database which is in the heart of this digital business runs in its full potential when hosted on purpose-built hardware for harnessing its power. And this is one of the reasons SAP has the SAP Integration and Certification Center (SAP ICC) that tests and certifies Infrastructure-as-a-Service (IaaS) platforms, along with other certifications like the storage solution that supports SAP HANA. The list of certified and supported SAP HANA Hardware can be referenced at

www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=v:deCertified

AWS offers a wide range of Elastic Compute Cloud (EC2) instances to host and run SAP HANA and S/4HANA application servers, the smallest being with 2 vCPUs and 3.75 GB RAM (VM supporting 1995 SAPS) to as large as 448 vCPUs and 24,576 GB RAM (bare metal supporting 444,330 SAPS). In the scale-out scenario, you can now run SAP S/4HANA workloads of up to 48 TB of memory.

The following section will detail some exemplary scenario to host and run SAP S/4HANA workload in the AWS Hyperscaler Cloud.

Exemplary Architecture

The SAP S/4HANA system can be deployed on highly available, fault-tolerant, and affordable way with AWS Infrastructure-as-a-Service model. In this chapter, you will have a clear understanding of how to provision an SAP S/4HANA system with different types of architecture on AWS with a specific availability SLA.

The common architecture discussed are

Single-AZ and single-node architecture
Single-AZ and multinode architecture
Multi-AZ, single-node SAP S/4 high availability architecture

Deployment Scenarios

Single-AZ and Single-Node Architecture

This is the default cost-minimized architecture to deploy an SAP system on AWS. Figure 5-1 shows a diagram illustrating this architecture.

The main features of this deployment are

The SAP system is deployed in a single availability zone.
You get 99.99% (four nines) VM availability SLA that means the maximum EC2 instance can be unavailable for 4.32 minutes per month.
This is a self-healing architecture. In case the underlying EC2 fails because of any hardware issue, AWS reboots that EC2 and automatically brings it up on another healthy hardware with the same configuration. You only need to take care of the application part.

The VM availability SLA should not be mixed with the SAP S/4HANA application availability SLA. During the reboot, it is to be noted that AWS does not guarantee on your application data; if data gets corrupted, then the only option is to restore the data to bring the services back to normal. This is the default cost-minimized architecture which is the best for non-production workload and also can be used for noncritical production workload.

In this setup, the SAP application and the HANA DB are deployed in the same VPC, the same availability zone, and normally the same subnet. Network segmentation totally depends on customer requirements like

Microsegmentation: Different subnets for each SAP SID.
Prod/non-prod segmentation: Production applications and databases are provisioned in one subnet, and non-prod applications and databases are provisioned in a different subnet.

The best practice is to put the SAP and DB in different subnets to restrict the direct access to the database. SAP applications (PAS and AAS) and HANA databases are installed as per the SAP standard installation guide. VM and OS requirements for SAP deployment are explained in detail in the next section.

Single-AZ and Multinode Architecture

This SAP S/4 deployment is illustrated in Figure 5-2. It is normally used for HANA scale-out environments.

The main features of this deployment are

By default, up to five nodes can be deployed in a single availability zone and multinode option.
All HANA nodes must be provisioned in the same subnet regardless of the function, in compliant with security best practice.
SAP HANA scale-out hosts must have a separate network (additional NIC) for internode communication.

If there is a requirement to deploy the HANA scale-out environment with more than five nodes, contact AWS.

SAP S/4 and HANA databases must be installed as per the SAP standard guide. VM and OS requirements for SAP deployment are explained in detail in the next section. The parameter “listeninterface” in section [communication] must be set to “.internal” or contain a CIDR netmask. Please follow the SAP KBA – 2183363.

Multi-AZ, Single-Node SAP S/4 High Availability Architecture

AWS multi-AZ deployment offers you to run business-critical SAP workloads with a high resiliency, fault-tolerant, and highly available environment. There is very less probability of business impact in case of any application breakdown, unexpected hardware failure, or unavailability of the entire single availability zone.

The infrastructure setup involves the following steps:

Select the availability zones for the deployment of the SAP S/4HANA system.
Create separate subnets for hosting the application and the database, separately in both AZs.

One important infrastructure limitation of hosting the infrastructure in AWS AZs is that you can have a shared subnet between AZs. This means you cannot assign a common IP to ASCS/ERS or HANA DB to address them when they are in two separate AZs. This limitation can be overcome with the use of Overlay IP (OIP).

Option A: Overlay IP Using AWS Transit Gateway

You can set up an SAP HA environment on AWS using Overlay IP in two ways. The first option we will discuss is shown in Figure 5-3. This option overlays the IP using the AWS Transit Gateway.

With Transit Gateway, you can use AWS route table rules which allow an Overlay IP address to communicate with an SAP instance without having any additional component like Network Load Balancer. You can easily connect to Overlay IP from another VPC, another subnet, or through Direct Connect from your corporate network.

AWS Transit Gateway works as a hub that controls the traffic, which is routed among all the connected networks, which act like spokes. Transit Gateway routes packets between the source and the destination as per the Transit Gateway route tables. You can configure these route tables to fetch routes from the route tables for the attached VPCs and VPN connections. You can also add static routes to the Transit Gateway route tables. You can add the Overlay IP address or address CIDR range as a static route in the Transit Gateway route table with a target as the VPC where the EC2 instances of the SAP cluster are running. This way, all the traffic is routed toward the Overlay IP addresses.

In above illustration, you have one VPC to isolate the network from other AWS virtual networks; within the VPC, you have two availability zones AZ1 and AZ2. Now you have to create a private subnet with a specific CIDR range in AZ1 (172.0.1.2/16) and AZ2 (172.0.2.2/16). Your private subnet cannot be spanned across availability zones. Now install S/4 ASCS in AZ1 (instance 1 in the diagram) and Standalone Enqueue Server 2 (ENSA2) in AZ2 (instance 4 in the diagram). SAP defined the new enqueue server ENSA2 as the default installation from S/4 1809 and concept to bring this feature to manage the lock table smoothly and efficient way which ensures the consistency of data in an ABAP system.

The ASCS and ERS or ENSA2 service needs to be installed with a virtual host associated with a virtual IP which is known as Overlay IP. An S/4 application instance needs to be installed in both AZs (instance 2, instance 3) to avoid the outage in case of zone failure. Now the HANA DB needs to be installed in both AZs (instance 3, instance 4) with a virtual host associated with Overlay IP, and the HANA System Replication with synchronous replication mode needs to be configured between the two HANA DB.

The overlay IP always points to the active ASCS or HANA DB node, in case node failure or any disruption of services, ASCS or HANA DB failover to availability zone 2 and Overlay IP switch to AZ 2 active nodes. End users will not get impacted with the node failure as they always connect to Overlay IP, and Overlay IP always points to active nodes.

Follow the AWS standard guide to configure the AWS Transit Gateway. The SAP HA cluster setup on different flavors of OS will be described later in this chapter.

https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html

Option B: Overlay IP Routing with Network Load Balancer

The other option is to overlay your IP routing. This option is illustrated in Figure 5-4.

If you do not have scope to use AWS Transit Gateway, you can use Network Load Balancer to access the Overlay IP addresses from an external network. NLB works at the network layer, the fourth layer in the OSI model which can accept millions of requests per second. It receives a request from an external network and selects a target as per the Network Load Balancer target group and routes the request to the specific Overlay IP address.

The installation of the SAP S/4 application and HANA DB is the same as explained in the previous section. In order to configure the Network Load Balancer in a proper way, you can follow the AWS standard guide, which is accessible in the following link:

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html

SAP HA Cluster Setup

SAP NetWeaver/HANA High Availability Setup on RHEL and SUSE

This section will explain the idea on how to set up a cluster solution to configure SAP on high availability on a RHEL/SUSE operating system. It is based on Standalone Enqueue Server 2 which is now the default installation in SAP S/4HANA 1809 or newer.

There are standard guides available for the SAP S/4HANA high availability setup on SUSE or RHEL on the AWS public cloud. KBAs are given at the end of this section to be referenced to set up the cluster. This section focuses on the working mechanism of the SAP HA cluster.

A high availability cluster solution for RHEL or SUSE works with two nodes. There is an additional software called Pacemaker that ensures automated failover between two nodes in case of hardware issues. Pacemaker works in the same way for the S/4 ASCS or HANA cluster in both RHEL and SUSE flavors. The failure of active nodes is automatically detected by the Pacemaker cluster, and it switches the ASCS/DB (single point of failure) services to the second node. The virtual IP (Overlay IP) is also adjusted from the primary node to the secondary node to make sure all the connection flows to active node only.

Importance of fencing: During a normal operation, there is no work of fencing agents in the cluster solution. A cluster communicates through Corosync, and a cluster of both nodes continuously updates each other of the health status of the nodes. A problem starts when one of the nodes stops responding. There are two possible scenarios:

The primary node is not available due to a crash or panic reboot.
The primary server is available, but due to a network issue, it is not reachable.

In the first case, the cluster will perform the failover to the secondary (healthy) node. In the second case, the failover must not happen as both nodes are active or available. This situation is called split brain or dual primary, and this is super dangerous in the HANA cluster as on both nodes the HANA database is running independently. So, imagine some transaction getting recorded in node 1 and some in node 2. This can result in serious data inconsistency for business, even loss of data. To prevent this situation, the Pacemaker cluster introduces a fencing mechanism called STONITH (shoot-the-other-node-in-the-head ). Just in case there is any communication issues between the nodes, then the healthy node will kill the faulty/noncommunicating node to ensure both nodes are not active at the same time.

The following are the high-level steps to install the SAP S/4 application server or SAP HANA database on the HA environment on a RHEL or SUSE platform:

1.
Build the AWS cloud foundation: The AWS cloud foundation design and implementation is the first step to start any project on the AWS cloud. It starts with region selection, network design (VPC, subnet, firewall, Transit Gateway or Network Load Balancer, Route 53), security and resource policies, on-premise to AWS connectivity, AD authentication, and so on. Some of these services are already explained in previous sections, and a few like security will be explained in the security section later in this chapter.
2.
EC2 instance provisioning: You need to provision the SAP NetWeaver certified and SAP HANA certified EC2 instances. You can deploy this manually or in an automated way with SAP recommended OS settings for a specific OS release (RHEL for SAP solution or SLES for SAP solution). VM provisioning is explained in detail in the “Compute” section later in this chapter.
3.
File system layout: You need to have the following directories to configure the SAP and HANA high availability:
- ASCS server local FS: /usr/sap/<SID>/ASCS<nn>
- ERS server local FS: /usr/sap/<SID>/ERS<nn>
- Shared FS: /sapmnt, /usr/sap/trans, /usr/SAP/<SID>/SYS
- Application server local FS: /usr/sap/<SID>/D<nn>

On Linux OS, Amazon Elastic File System (EFS) can be used for shared directories to be mounted as NFS in different servers. For Windows, FSx is the file share option mounted as SMB drive. For both the HANA nodes, you should have the following file systems with the same size:

/usr/sap
/hana/shared
/hana/data/<SID>
/hana/log/<SID>
/hana/backup
/hana/* file system type should be XFS, and the rest are EXT4 type.

Please follow this sequence to create the environment:

1.
Create the Overlay IP addresses: Create the virtual IP or overlay IP in AWS and associate the same with all the HA nodes.
2.
Install S/4 ASCS and ERS: Install ASCS in one node and ERS in another node with a virtual host and Overlay IP as per the SAP HA standard guide.
3.
Configure the cluster setup: Set up the Pacemaker configuration in both ASCS and ERS nodes.
4.
Install HANA DB: Install the stand-alone HANA DB in both the DB nodes with a virtual hostname and Overlay IP as per the standard SAP guide.
5.
Configure HANA System Replication: Configure HSR with synchronous operation mode and log-replay replication mode.
6.
Set up the Pacemaker cluster: Set up the Pacemaker cluster on both ASCS/ERS and HANA nodes separately.
7.
Install S/4 application servers: Install additional S/4 application servers in both the availability zones. Application servers are not part of the cluster.
8.
Test the cluster: Perform a cluster failover test.

It is very critical for any production system setup with HA to have a robust cluster setup to avoid any unplanned outage because of hardware issues. So, after the cluster setup, perform a rigorous cluster testing. Table 5-1 summarizes a sample cluster test plan.

Table 5-1 Test Cases for HA Clusters

Full size table

Follow the standard S/4 on AWS KBAs to set up the high availability solution on a RHEL or SUSE platform:

S/4 high availability for SUSE: https://documentation.suse.com/sbp/all/html/SAP_HA740_SetupGuide_AWS/index.html
SAP HANA high availability for SUSE: https://documentation.suse.com/sbp/all/html/SLES4SAP-hana-sr-guide-PerfOpt-15_AWS/index.html
S/4 high availability for RHEL: https://access.redhat.com/articles/3916511
SAP HANA high availability for RHEL: https://access.redhat.com/articles/3569621

SAP NetWeaver Availability Setup on Windows Platform

When setting up an S/4HANA system or a NetWeaver system, you can host an application server on a Windows Server operating system. The Windows-native high availability solution – Windows Server failover cluster – is used for the HA configuration. You can configure an SAP high availability setup for ASCS and ERS services in two ways on the Windows platform:

Windows Server Failover Clustering (WSFC) using the Amazon FSx file share solution
Windows Server Failover Clustering (WSFC) using the SIOS Protection Suite on AWS

Windows Server Failover Clustering (WSFC) Using Amazon FSx File Share Solution

This solution uses Amazon FSx file systems to host shared directories needed for ASCS and ERS. Amazon FSx is an AWS fully managed file system (same as EFS for Linux OS) which can be shared across availability zones. Use a multi-AZ Amazon FSx file for a Windows file share. Refer to the following AWS guide to set up SAP S/4 high availability on Windows using the Amazon FSx file share:

https://aws.amazon.com/blogs/awsforsap/how-to-setup-sap-netweaver-on-windows-mscs-for-sap-ascs-ers-on-aws-using-amazon-fsx/

Windows Server Failover Clustering (WSFC) Using SIOS Protection Suite on AWS

SIOS Protection Suite is a third-party software provided by SIOS Technology. It is tightly integrated with the WSFC cluster to perform smooth failover in case of a zone failure or disruption of services. The SIOS DataKeeper part of SIOS Protection Suite is a server-based replication solution (same as the NFS or GFS file share solution) that performs block-level data replication across the availability zones to manage the Windows HA solutions. Here, the recommendation is to provision separate VMs in both zones for shared file systems which are to be replicated synchronously and mounted to ASCS/ERS servers, so there will not be any disruption of services in case of zone failure.

Refer to the following AWS guide to set up SAP S/4 HA on Windows using SIOS Protection Suite: https://aws.amazon.com/blogs/awsforsap/deploying-highly-available-sap-systems-using-sios-protection-suite-on-aws/.

Compute

Computes are the core services for hosting SAP applications and HANA databases. In this section, you will learn the available templates released by AWS that have been certified to host the SAP workload.

This will help to choose the appropriate EC2 template. This section further describes how to provision the template, which build-related information are available, how to provision the EC2 template and which build-related information are required to enable the EC2 to finally host the SAP workload.

Compute refers to the amount of computational power required to fulfill your workload. Being an architect, your responsibility is to properly size the compute to host the SAP workload (large, medium, small). It should not be oversized resulting in customer spending more than required or undersized which may lead to impaired performance of the production instance, hampering business, and unpleasant user experience.

AWS has a wide range of SAP certified compute on offer to host the SAP workload. The elasticity feature of the AWS cloud can be used to adapt the compute power to the usage load requirement. This means you don’t necessarily need to plan for a large instance upfront.

The available EC2 instances in AWS are segregated based on CPU, memory, storage, and network performance. Depending on the usage type, you can provision a suitable EC2, for example, for an application server expecting heavy compute load, you can provision a CPU-optimized EC2, while for HANA DB, you can opt for a memory-optimized EC2 instance.

Available EC2 Instance Family

Amazon provides a wide range of EC2 instance types to support all types of workload.

Compute-optimized instance types are best for workloads where you need high-performance processors: C* (C4, C5, C5a, C6g, etc.).

Storage-optimized instance types are used where you need high, sequential read/write operations to a large dataset locally. They provide low latency and very high IOPS:

D*, H1, I3, I3en

General-purpose instance types are CPU- and memory-balanced instance types and ideal for small- and medium-sized databases or workloads:

M*, T* (M4, M5, M5a, T2, T3, T3a, etc.)

Memory-optimized instance types are ideal for workloads that process a large dataset in memory and are best used in in-memory databases like HANA: R* (r4, r5, r5a, r5ad, etc.).

Amazon also provides bare-metal solutions to support very high memory workload like u6tb1.metal, u-9tb1.metal, u-12tb1.metal, u-18tb1.metal, and u-24tb1.metal.

EC2 Instance Licenses

For running SAP workload on EC2, you have the following options to procure the usage license:

On-Demand Instance: With On-Demand Instances, you pay by hour or by minute, depending on the instances you're running and based on your uses. No long-term contracts or upfront payments are required. You can flexibly increase or decrease the computing capacity depending on the application requirements and only pay the hourly rate for the instances used. This is very useful if you run your workload during specific times only.
Reserved Instance: Amazon EC2 Reserved Instances (RI) provide a significant discount (up to 72%) compared to On-Demand pricing and provide a capacity reservation when used in a specific availability zone. You should use a reserved instance for all the production workload.
Dedicated host: This is the bare-metal solution offering explained earlier. A dedicated host is a physical EC2 server that is reserved exclusively for your use. With dedicated hosts, you can save costs by using your existing server-based software licenses, like Windows Server, SQL Server, and SUSE Linux Enterprise Server (according to your license terms and conditions). This can be booked on-demand or as a reserved instance (with 70% discount) as per your usages.

SAP S/4 Certified EC2 Instance Types

AWS has worked closely with SAP to certify a set of EC2 instances for SAP and HANA workload. Follow the link to get the updated latest generation SAP certified EC2 instance types:

https://aws.amazon.com/sap/instance-types/

Also, refer to the SAP Note 1656099 “SAP Applications on AWS: Supported DB/OS and AWS EC2 products” that gives you the latest information about AWS EC2 instance types that are currently supported on Amazon Web Services (AWS) infrastructure.

EC2 Provisioning

This section will walk you through the components, services are required to provision the virtual machines on AWS and high-level steps to provision the VM. First, you need to assess and gather customer requirements to build the cloud foundation or landing zone which include the following components:

Region: Select the primary and DR region.
Availability zones: Select the availability zones and single-AZ or multi-AZ deployment.
Networking: Design network segmentation with the following items.
Virtual Private Cloud (VPC): The number of VPCs required like Management VPC and SAP VPC to isolate from other virtual networks.
Private subnet: Design a private subnet for SAP workload like one subnet for each SAP SID or one subnet for non-production workload and one for production workload or different subnets for the SAP S/4 application and HANA DB layer.
Public subnet: Bastion host on a public subnet with an Elastic IP address to access the EC2 instances.
Internet Gateway to access the Internet.
NAT Gateway: A NAT gateway allows the outbound Internet access for private subnet resources.
AWS connectivity: You can connect to AWS VPC with your corporate network in two ways.
VPN connection: Encrypted IPSec connection between on-premise and AWS VPC. You can create multiple VPN connections with one VPC; it’s fast and simple to set up.
Direct Connect: Using Direct Connect, you can connect to AWS VPC with your data center. Direct Connect provides high bandwidth and throughput.
Security: Define a security policy to restrict the inbound/outbound traffic.

You have to create an AWS account to provision any resources on AWS. Once your AWS landing zone is ready, then you are good to start with deploying S/4 and HANA VMs. You need to have the following information to provision an S/4 application or HANA DB server on AWS:

1.
Account ID.
2.
IAM roles/policies.
3.
VPC/subnet/region.
4.
Security group.
5.
S3 bucket (if required to attach).
6.
Storage volumes and file system layout: Mount point, volume (physical and logical), size, type of storage (EBS/EFS), file system type.
7.
Instance size.
8.
Platform (Windows/RHEL/OEL).
9.
Physical and logical hostname.
10.
UID/GID information.
11.
OS packages should be installed as per the SAP recommendation.
12.
Server tagging information.

Now you can deploy the cloud foundation and EC2 instances in a manual way or fully automated way with a script.

Manual Deployment with AWS Console

This example walks you through the look and feel of the AWS console and how to create resources on AWS. The process is shown in Figure 5-5.

Create a Direct Connect connection: Search the service from the AWS console or go to All Services ➤ Networking & Content Delivery ➤ Direct Connect.

Click create connection. After giving all the details like name, your location from where you want to connect to AWS, required bandwidth, your on-premise network provider, and BillTo tag, create a connection as shown in Figure 5-6.

You can choose the service provider for the connection from a list of providers as shown in Figure 5-7. After that step, the connection would be created and established.

Create VPC, Subnet, NAT Gateway (Create Elastic IP Address Before You Create VPC)

After the connection was created successfully, the next step will be to create the VPC with public and private subnets. The start of the deployment is shown in Figure 5-8.

Step 2 of the creation requires you to maintain the details about the public and private subnets as shown in Figure 5-9.

After you maintained the details about the public and private subnets and click next, it will take some time to create the subnets. During that time of waiting, you will see the status message as shown in Figure 5-10.

Eventually, after the public and private subnets have been created, you will see a completion message as shown in Figure 5-11.

Now your basic cloud foundation is ready, and you can deploy SAP S/4 and HANA VMs as follows. Here in the example, we choose SLES for SAP 15 SP1 AWS Machine Image with pay-as-you-go (PAYG) subscription. You can use bring-your-own-subscription as well. The first step to deploy the machine is to choose the Amazon Machine Image, which is tailored for the needs of SAP. In Figure 5-12, you can see an example of such an SAP-tailored AMI.

After choosing the AMI, the associated and certified instance types are listed. This allows you to choose the right sized VM for your new SAP system. Each VM template differs in the number of CPUs and memory and, hence, incurs higher/lower costs. Those are also shown for each instance type. Figure 5-13 shows the list of instance types and costs for the SLES operating system.

In the next step for the deployment, you will have to choose the right instance type. You also see the sizing of each instance type, like CPUs and memory, but also the limitations toward the storage (Elastic Block Storage – EBS only) and the connectivity to the network. This is shown in Figure 5-14, where we choose the instance type r5.

Once the instance type is chosen, you will need to select a couple of options and specify some important details. For example, you need to assign the network and subnet but also settings for the domains and some additional behavior settings. In Figure 5-15, we have chosen the network “sapvpc,” to which the new VM will be assigned.

After this configuration, you can add some storage. To do so, you do not select the “Review and Launch” button as shown in Figure 5-16, but you choose to add some storage. As per the limitations for the chosen instance type (r5), we can only select EBS. Figure 5-16 shows the configuration of a 10 GB and a 25 GB storage device, which is sufficient for the operating system.

As a next step after configuring the storage, you can configure tags. Those are used to manage cost allocations or specify the owner of a specific machine. In Figure 5-17, we specify a tag called “SAP S/4 S4D” and set the value to “600099.” Afterward, we define the security group for the new VM. This is based on the recommendations from the AWS Marketplace and contains, for example, some frequently used ports (22 and 80), which will be added to the security group for this machine.

Before the new instance will be launched, you can review all the chosen settings and options and, if required, return back to the specific step to change anything. The summary as shown in Figure 5-18 contains all the settings, which we have chosen for the deployment.

The summary contains a lot of details and also lists the details about the security group as well as the chosen storage. This is shown in Figure 5-19.

Before finally launching the instance, you can review the storage and the sizing of the storage. If you are ok with that, you can go ahead and get the new VM created and launched by hitting the button “Launch” as shown in Figure 5-20.

For the access to the newly created machine, a key pair can be chosen, if you already have one stored in AWS, or you can go ahead and create a new one as shown in Figure 5-21. This is needed in order to gain the access to the machine after the successful deployment. The deployment can take quite a while, depending on the size of the machine and the number of settings to be applied. But overall, the deployment is rather quick, and you will see a screen like in Figure 5-22, which also shows you the current step in the deployment.

If everything goes smooth and without any error, you will see the newly created VM in the list of your running instance in the AWS console as shown in Figure 5-23. This shows the new instance mpss4us1p with the instance type r5.xlarge.

Automated Deployment with Scripts

When you deploy SAP systems in AWS, you need to deploy identical instances, for example, deployment of Additional Application Servers or setup of landscape in a disaster recovery region which needs identical setup as production. There is an option of automated deployment of infrastructure as well as SAP applications through scripts. Terraform and Ansible are two available tools that can aid this.

Terraform

Terraform is an infrastructure automation tool. It uses easy-to-write templates in HCL (HashiCorp Configuration Language). It offers built-in functions and conditions and has a vast array of modules and providers for working with cloud and on-premise systems. One of the unique selling points of Terraform is that it is cloud agnostic, that is, the code works on all popular clouds. If you plan to use Terraform, you don’t need to deploy any agent, only the binary code on the server is sufficient to perform the provisioning tasks.

In AWS, Terraform can be used to create the SAP and DB infrastructure automatically as per the Terraform configuration files. Terraform workflows depend on their commands – plan, apply, and destroy. And to invoke this, you need to have an initialized working directory.

Visit the GitHub repository and go through the sample Terraform scripts and modules and execute them to create your first infrastructure on AWS for SAP automatically:

https://github.com/aws-samples/terraform-aws-sap-netweaver-on-hana

Ansible

Ansible, which is owned by Red Hat, is an open source tool that enables the automation, configuration, and orchestration of infrastructure. Ansible is very reliable for repeated deployment, infrastructure update, and configuration management. And all these can happen from one central location called control machine via SSH. Ansible also offers a vast array of modules for most OS-level utilities.

Ansible uses YAML syntax to create the configuration file. Ansible too is an agentless tool, and only binary code is required on the server to perform the tasks.

Ansible can be used to automate the OS configuration and SAP and DB application deployment. Like Terraform, you also need to execute the Ansible script from a tool server to deploy the application on managed servers. The yml (*.yml) file is the main configuration file in Ansible which contains all the tasks to configure the infrastructure and deploy S/4 and HANA applications.

https://software.opensuse.org/download.html?project=systemsmanagement&package=ansible

Terraform uses API calls to provision cloud resources like deploying EC2 instances, disk provisioning and load balancer setup, and so on, whereas the Ansible script is used to configure OS settings like mounting the disk, FS layout, user group creation, OS parameter settings, and installation of an SAP application and database. Figure 5-24 depicts how it works.

For a fully automated deployment, you would follow the six steps as shown in Figure 5-24:

1.
Clone the Terraform Git repository to the laptop.
2.
Launch Terraform from the laptop to provision the cloud foundation like the VPC, subnet, Route 53, NLB, Transit Gateway, etc.
3.
You need to provision one tool server on AWS from where you can launch Terraform and Ansible to provision VM and SAP.
4.
Clone the Terraform and Ansible Git repository to the tool server.
5.
Launch Terraform from the tool server to deploy SAP infrastructure.
6.
Launch Ansible from the tool server for OS configuration and to deploy S/4HANA application.

Storage

This section gives an introduction of the main storage types of AWS that are used when hosting the SAP landscape on the AWS cloud. As a recap, the main AWS storage services that are used in SAP are shown in Figure 5-25:

Amazon Elastic Block Store (Amazon EBS)
Amazon Elastic File System (Amazon EFS)
Amazon FSx for Windows File Server
Amazon Simple Storage Service (Amazon S3)

The section elaborates the available storage types in Amazon, based on the requirements of the S/4 system, and it provides guidance to the general storage layout (stripping) as well as possible sizing for S/4 systems (database and application servers). We will also discuss cost-optimized solutions for running noncritical SAP systems, for example, read-only archive systems. Based on the DR requirements, you may need to choose specific settings (geo-replication) for some of the storages. The relationship between the different storage types is shown in Figure 5-25.

Amazon EBS

EBS (Elastic Block Store ) provides durable, block-level storage volumes to be attached to specific EC2 instances. They function similar to Storage Area Network (SAN) devices, much like raw unformatted block device from where you can carve out the file systems. Normally, all the file systems of an SAP application server and database that does not require sharing are created out of EBS volumes. EBS by its configuration offering from AWS is on a high availability setup. They are replicated across multiple servers in an availability zone that ensures HA.

You can attach multiple EBS volumes to a single EC2 instance, but you cannot attach the same EBS volume to multiple EC2 instances. EBS volumes are independent on the EC2 instance lifetime. You can keep the EBS volume after terminating the EC2 instance. EBS is not expandable across the availability zones. If you need to replicate the content across availability zones, you can take a snapshot of existing EBS, transfer the snapshot to another zone, and restore. AWS offers different EBS volume types:

General-purpose SSD: General-purpose SSD (gp2 and gp3) provides cost-effective storage with strong performance. This is best suited for small- to medium-sized workload. It’s available from 1 GB till 16 TB and provides 3 IOPS per GB, so if you provision 1 TB volume, you will get 3000 IOPS. General-purpose SSD is billed based on the volume you attached, regardless of how much data you actually stored.
Provision IOPS SSD: Provision IOPS SSD (io1, io2) provides the highest throughput and performance out of all the EBS volumes. This is primarily used where you need high and consistent IOPS rate. This is the most expensive EBS storage type, and the volume size can go up to 16 TB starting with 4 GB. The pricing model is similar to general-purpose SSD; you have to pay for the volume you attach and IOPS you provision. Provisioned IOPS volume types are primarily used in HANA database workloads that require high IOPS.
Magnetic Volumes: A Magnetic EBS (st1, sc1) volume provides the lowest performance with lowest cost among all the EBS volumes. It’s useful where data needs to be accessed infrequently and for sequential reads. It is not recommended to use Magnetic Volumes for SAP workloads.

Amazon EC2 Instance Store

EC2 instance stores also provide block-level storage like EBS, but they are ephemeral data stores. Instance stores are physically attached with an EC2 host; hence, if you terminate the EC2 instance, your instance storage data is lost. It is ideal for temporary storage like buffer, cache, or data that replicates across instances. Instance stores should not be used to SAP workload file systems, but you can use them in swap space.

Amazon EFS

As explained in Section 4.2, EFS and FSx are Amazon-managed highly available shared file systems used to store SAP file systems that need to be shared across application servers. And in the case of high availability configuration, they are also used to host file systems for ASCS/SCS and ERS HANA share and HANA backups.

EFS is exclusively used with Linux operating systems, while FSx is used with the Windows Server operating system. Refer to the following standard AWS guide to know how to create an EFS file system step by step:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

Amazon S3 (Simple Storage Service)

Amazon S3 is an object storage which you can use to store and retrieve any type and any amount of data from anywhere over the Web. S3 offers you to pay only for the storage you actually use. For the SAP landscape, S3 is commonly used in the following cases:

Store backup (DB, VM snapshot, etc.) and archive data.
Disaster recovery.
Content, media, and software storage.

S3 also offers different types of storage classes like general purpose, infrequent access, and archive to support different types of use cases. S3 components are explained briefly in the following.

Buckets: An S3 bucket is a container for objects to store in S3. A bucket is a global entity and is not limited to your AWS account. This means bucket names should be unique across all AWS accounts. Although bucket namespace is global but you can create an S3 bucket in your specific region and close to set-off end users in order to minimize the latency and to ensure fast transfer of the files or even you can create in different region than primary to support in disaster scenario.

Objects: Objects are files which are stored in S3 buckets. Objects can store any type of data in any format, but you can store data up to 5 TB in a single bucket with unlimited number of objects. Each object consists of data (actual data) and metadata (information about data).

Keys: A key is a unique identifier of every object which is stored in an S3 bucket. A key can be a file name which should be unique in a single bucket, but the same key (or file name) can be used in different buckets.

Object URL: An Amazon S3 object can be accessed with a specific URL formed using a service endpoint, a bucket name, and an object key like

http://testbucket.s3.amazonaws.com/test.doc

Here, testbucket is the bucket name, and test.doc is your key or file name.

Durability and availability: Amazon S3 provides very high durability and very high availability; the Amazon S3 standard storage is designed for 99.999999999% durability and 99.99% availability. S3 achieves durability by automatically replicating the data in all locations in a specific region. If you don’t need high durability for noncritical data, you can use Reduce Redundant Storage (RRS) at a lower cost with 99.99% durability.

Data consistency: Amazon S3 guarantees on data consistency as by default it replicates your data in different servers or locations within a region. Changes may take a moment, so in some cases you can get stale data, specifically if you PUT new data on an S3 object and subsequent GET will return old data; so for an eventually consistent read, you will get either old data or new data, but there will not be any data inconsistency.

Access control: Amazon S3 uses the Amazon Access Control List (ACL) and IAM to grant the access on the S3 bucket or object level. You can grant WRITE, READ, and FULL CONTROL at the bucket or object level.

Storage class: You need to understand the different types of storage class available in S3 to define the backup and archive storage strategy in a cost-effective way. There are mainly three storage classes available:

Amazon S3 Standard: The Amazon S3 Standard provides the highest durability, availability, low latency, and high performance on your data transfer between EC2 and S3. The Amazon S3 Standard is very useful for frequently accessed short-term or long-term storage data.
Amazon S3 Standard IA: Standard Infrequent Access also offers the same durability, availability, and low latency like the standard storage class, but this is used for less frequently accessed data. If you have to store data for a minimum of 30 days, you can use this for long-term stored data which are accessed less frequently, and cost-wise it’s much cheaper than the standard storage class.
Amazon Glacier: The Amazon Glacier storage class allows you to store the archive data or long-term backup with the lowest price. It also provides durability and security to your data. Data retrieval from Glacier can take several hours. Also, retrieval can be expedited incurring additional costs. Now you can plan your cloud storage based on the preceding three classes; mainly, you need to focus on “how frequently data access is required,” “retention period,” and obviously “cost.”

For further details, we recommend reading through the user guide from Amazon, using the following link:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonS3.html

Storage Layout for S/4HANA System

An SAP system can be set up with one of the three possible deployment options. This section will detail the storage layout setup required for each.

Standard System Deployment

In this deployment option, all the components of the SAP application – ASCS/SCS, ERS, and PAS – and HANA database run on one single EC2 host. This deployment is only suitable for small non-production instances.

If you plan to run an SAP S/4HANA application server on a Windows Server host, you need separate EC2 instances for the application and the HANA database.

Distributed System Deployment

In this deployment option, each component can run on separate hosts:

An EC2 for ABAP Central Services instance (ASCS instance)
An EC2 for SAP HANA database
An EC2 for PAS
Additional EC2s, optionally Additional Application Servers (AAS)

High Availability System Deployment

In this deployment option, each component must run on a separate host, and the high availability setup will be done to secure the single-point-of-failure (SPOF) components for the S/4 application (ASCS/ERS) and HANA DB.

Indicative File System Setup for Non-high Availability Setup

There are clear recommendations for which storage type can be used for which file system/mount point of the SAP system. For SAP systems running without any high availability solution, Table 5-2 provides an overview.

Table 5-2 Indicative FS Layout for Non-HA

Full size table

Indicative File System Setup for High Availability Setup

For the HA setup, the SPOF file systems need to be on HA, and EFS is one the suitable options to host such file systems. Compared to non-HA SAP systems, those systems using a high availability solution have special mount points for special file systems. Table 5-3 shows the mount points and the suggested storage type.

Table 5-3 Indicative FS Layout for HA

Full size table

* It is preferable to keep /<sapmedia> (a directory that holds all SAP installation media downloaded from the SAP Support Portal) in a shared location so that it is accessible from all the servers. So EFS has been recommended. It is not a SPOF.

The following aspects related to file system hosting should be taken into account while planning to configure the SAP application and HANA DB file systems:

HANA data and log volumes must be configured on SAP-certified storage options for HANA workloads. To achieve the optimal throughput or performance, SAP certifies EBS volumes (gp2, gp3) and provisions IOPS SSD (io1, io2) for SAP HANA workloads.
For non-production HANA databases, you can opt for general-purpose SSDs (gp2/gp3), unless you have a pressing requirement for high IOPS.
For production instances that are mission critical, you should provision IOPS SSD (io1, io2).
Keep in mind the cost while deciding the storage tiers. IOPS SSDs can be 1.5 times (or more) costlier than general-purpose SSDs.
AWS has recently launched the gp3 type EBS volume. It is now recommended to use the gp3 type SSD as this offers better throughput or performance and is cost-effective compared to gp2 type EBS volume.
EFS volumes are up to three times costlier than EBS volumes. So, for a standard installation, prefer putting the file system in EBS as they are accessed from the same host.
It is possible to stripe multiple EBS volumes together to achieve more IOPS and larger capacity. This is especially applicable for hosting HANA DB’s data files.
With SAP HANA 2.0 SPS03, the HANA indexserver is able to distribute its I/O activity across multiple HANA data files. These files can be located on different disks. If you opt for this setup, you can save yourself from the additional overhead of EBS striping.
Ref: Partitioning Data Volumes - SAP Help Portal
https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/40b2b2a880ec4df7bac16eae3daef756.html?q=hana%20data%20volume%20partitioning
2400005 – FAQ: SAP HANA Persistence
For a view of the HANA storage configuration for /hana/data and /hana/log, you can refer to the AWS documentation – Storage Configuration for SAP HANA: https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-storage-config.html.
Enable EBS optimization while launching the EC2 instance for hosting the SAP application/DB. With this setup, the burst performance of the EBS volumes is almost guaranteed. When attached to an EBS-optimized instance
- General-purpose SSD (gp2 and gp3) volumes are designed to deliver their baseline and burst performance 99% of the time.
- Provisioned IOPS SSD (io1 and io2) volumes are designed to deliver their provisioned performance 99.9% of the time.

Refer to the AWS documentation for instructions on how to enable EBS optimization for an instance:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html

PAYG vs. Commitment – Calculator

Although the public cloud can offer great potentials for savings, the tricky question remains for a lot of customers, if they should commit to a workload for some time or if they want to benefit from the flexibility. This has a big monetary impact and will be discussed in this section. We will also show the calculator for having a better idea about the break-even for the decision.

In AWS, you can purchase an EC2 instance in the “On-Demand” or “Reserved Instance” category based on your usage.

On-Demand Instances

On-Demand Instances enable you to pay for what you use; you have to pay only for the time of EC2 instances running, and if you stop it, you don’t need to pay for compute, only you have to pay for the storage attached to the instances. This is very useful and cost-effective in cases where you have limited usage of instances like sandbox, training, non-prod instances, etc. You can schedule the start and stop automatically if you know the usage duration. For example, you can automatically start it before starting the business hours and stop the instance after business hours. On-Demand Instances are very useful and cost-effective in those cases where you don’t have any long-term commitment.

There is a default limit of running a total number of On-Demand Instances per AWS account per region. The limit depends on the number of vCPUs. You can have a certain number of vCPUs per AWS region and per account, but you can increase this limit by raising a request through the AWS Support Portal.

Reserved Instance

In a Reserved Instance model, you will get a significant discount compared to the On-Demand Instance cost. You need to provide one-year or three-year long-term commitment. You will get more discount for longer commitment.

A Reserved Instance will not get renewed automatically if it expires; you must purchase the reserved instance again, else it would be converted to an On-Demand Instance once it expires.

It is a very useful and cost-effective option for your production workload where your EC2 instance must be running 24 hours throughout the year.

The Reserved Instance price depends on four attributes:

Instance type (small or large)
Region (purchased on which region)
Tenancy (default or dedicated)
Platform (Unix or Windows)

A Reserved Instance offers two classes: Standard and Convertible. In a Standard class, you will get a significant discount, but you cannot exchange the instance type, only you can modify it. Convertible comes with a lower discount compared with the standard class, but you can exchange the instance type with another convertible instance, and it can also be modified.

A Modified Reserved Instance means you can change the instance type within the same family. You can modify the instance type from m4* to m5* provided your instance footprint size is the same, but you cannot modify an m4* to c* instance type. Only the Linux/Unix platform can be modified.

An Exchange Convertible Reserved Instance means you can exchange the instance type from one family to any other family with the same or higher footprint size than the original instance type.

Payment Option

You have to pay for Reserved Instances regardless of whether you are using it or not. There are three payment options available in the Reserved Instance category:

All Upfront: Full payment must be made before starting the instance, no other charges to be paid throughout the term. You get a maximum discount with this payment option.
Partial Upfront: A portion of the total cost must be paid before starting the term, and the remaining will be billed with a discounted hourly rate.
No Upfront: You don’t need to pay anything upfront; you will be billed a discounted hourly rate.

AWS Calculator

You can calculate the BOM (Bill of Materials) of your project through the AWS calculator . This section will show you how the AWS calculator is used in your regular business. Go to https://calculator.s3.amazonaws.com/index.html, and you will see a similar screen like the one in Figure 5-26.

Here, you can see all the AWS services in the left pane, which you need to calculate the cost, and “Services” and “Estimate of your Monthly Bill” at the top pane. In this example, we will estimate the cost of the EC2 instance and EBS volume with the “On-Demand” and “Three years Reserved Instance” category.

We will take two r* family instance types and 2048 GB “Provisioned IOPS SSD (io2)” EBS volume into our consideration.

On-Demand Instance Cost

Click “Add New Row” in the “Compute: Amazon EC2 Instances” section and enter the details as per your requirement. In the same way, enter the details in the “Storage: Amazon EBS Volumes” section as you can see in Figure 5-27.

In Figure 5-28, you can see the estimated monthly bill of $6796.59 for two r5.8xlarge instances and 4 IOPS SSD (io2) volume with 2048 GB. If you click the Estimate tab, you can see the breakdown as well.

If you change the billing option for the instance from on-demand to a three-year upfront payment, the overall costs will significantly reduce. This billing option is shown in Figure 5-29, and you can see the monthly cost of $0.00.

Reserved Instance Cost

In order to understand the costs for a Reserved Instance, you will need to switch to the tab “Estimate of your Monthly Bill” to see the breakdown of the costs. This is shown in Figure 5-30, where the total on-time cost of $50,150 is shown plus the monthly cost of $3340.

Once you gained a good overview about your monthly and on-time costs, you can switch back to the main tab Services to review your input as shown in Figure 5-31.

Security on AWS

Security is of paramount importance when you plan to host your SAP landscape in the AWS cloud. AWS promises to be one of the most secure environments and ensures protection at every layer engaged in hosting and running an SAP landscape. The security in AWS works with the Shared Security Responsibility Model:

AWS owns the security of the cloud infrastructure.
The customer is responsible for the security of SAP workloads deployed on AWS – for example, for application, data, identities, and connectivity.

Figure 5-32 shows the AWS Shared Security Responsibility Model for SAP systems deployed in AWS.

In this model, the security of the cloud is the responsibility of AWS, while the security in the cloud is the responsibility of customers. AWS takes care of the security part of the underlying infrastructure like compute, storage, global network, etc., and you are responsible for everything you deploy on the cloud like the operating system, SAP application, network, firewall setup, etc.

AWS offers a wide range of security tools for the protection of the network, configuration management, access control, and data security. And to keep track of changes, AWS provides monitoring and logging tools that can provide full visibility into what is happening in your environment.

You can protect AWS accounts and resources with different AWS-provided security features like AWS credentials, AWS Identity and Access Management (IAM), encrypted data transfer using HTTPS endpoints, etc.

You can use different types of credentials to protect your AWS resources from unauthorized access like passwords, digital signature and certificates, key pairs, and multifactor authentication (MFA). Not only account security, AWS also provides built-in security in each layer of the infrastructure, and to protect your organization data from threats, you will also get security features on each service including the EC2 instance, guest operating system, EBS volume, storage (S3, EFS, FSx), network, etc. Network security is a very important aspect in the SAP architecture design on AWS. Here, we will discuss how you can secure your network from outer world unwanted traffic.

The security concern at each layer can primarily be categorized into these sections: access and identity provisioning and protection (AIPP) and data protection (DP). And then to keep track of all controls and activities, you require monitoring and logging tools.

On top of all these sits the Governance, Risk, and Compliance to ensure that all the regulatory frameworks such as PCI, GDPR, CCPA, and HIPAA are in place and the organization is abiding by the regulatory and audit requirements.

Some questions that you should be asking when planning the access and data protection are as follows:

1.
AIPP: How will the access be provided?
2.
AIPP: How will unwanted access be prohibited?
3.
AIPP: Who will have access?
4.
AIPP: How much access will be provided?
5.
DP: How will data at rest be safeguarded?
6.
DP: How will data in transit be protected?

Tools

AWS along with its certified security partners provides several services and tools to protect and safeguard each layer.

Tools for Access and Identity Provisioning and Protection

AWS Identity and Access Management (IAM): The IAM service helps you create and manage an identity and its associated permission to use AWS resources. An identity can be a person, an application, an object, or a computer. Through IAM, you can ensure several authentication mechanisms for identities such as password/certificate login, multifactor authentication, and federated access with third-party solutions like Microsoft ADDS.

AWS Single Sign-On (AWS SSO): With AWS SSO, along with the directory that it offers, you can manage the access for users (groups) to AWS services. It is different from AWS IAM in its scope. With the AWS SSO service, you create the users centrally in AWS SSO and manage access to all your AWS accounts and applications. The user just needs to authenticate once with a single set of credentials configured in AWS SSO; all the connected applications can be reached with no additional credentials. This is especially useful in the case of SAP Fiori configuration.

In addition to these plans, appropriately for the operating system–level access that SAP system administrators will need to manage and maintain the systems:

During installation, the SAP Technical Team will need administrator access (for Windows) or root access (for Linux). Ensure that access is provided using SSH keys rather than a password.
For the sustained support phase, ensure steps to harden the operating system. You can refer to the vendor-specific guide for OS hardening details.

The OS hardening guide for SUSE Linux Enterprise Server for SAP Applications 15 can be found at the following link:

https://documentation.suse.com/sbp/all/html/OS_Security_Hardening_Guide_for_SAP_HANA_SLES15/index.html

The same guide for Red Hat Enterprise Linux 8 is at this link:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/pdf/security_hardening/security-hardening.pdf

Tools for Data Protection

Protect data at rest. AWS provides data encryption to protect all the locations where SAP data can be stored – EBS, EFS, FSx, S3. Related services offered by AWS are mentioned as follows:

Key Management Service (KMS): This service helps in key storage, management, and related auditing. The main features of this service are
- It is tightly integrated with AWS services like EBS, EFS, S3, and SQS.
- KMS can generate a key for you, or you can upload your own key.
- The control on who can manage and who can use the keys is governed by IAM users and roles.
- The use of keys can be audited via CloudTrail.
- Compliance: PCI DSS level 1, FIPS140-2 level 2.
Cloud HSM: Cloud HSM is a dedicated hardware device associated to one customer key management. The main features of this service are
1. 1.
  It must be located within a VPC.
2. 2.
  It is not as flexible as KMS in terms of integration with AWS services. You need to write custom script to integrate.
3. 3.
  It has two versions – classical cloud HSM and current cloud HSM. While classical cloud HSM has upfront cost, current cloud HSM is chargeable only for usage. Classical cloud HSM is FIPS140-2 level 2, while current cloud HSM is FIPS140-2 level 3.
AWS Secrets Manager: This service helps you manage, rotate, and retrieve the database credentials or keys for file-level encryption, thus eliminating the need to hard-code sensitive information in plain text.
Protect data in transit: The data as it flows in the network is protected through Transport Layer Security (TLS) for HTTPS or with IPsec for VPN connections.
AWS Certificate Manager: It is an AWS managed service that lets you provision, manage, and deploy public and private SSL/TLS certificates. This service is directly integrated with AWS services like EBS, CloudFront, and API Gateway. AWS itself is a CA, so you don’t need to register via a third-party CA. You can upload a third-party certificate for use in AWS. AWS Certificate Manager supports a wildcard domain (*<domain_name>.com), thus covering all your subdomains, and automatically takes care of the renewal of certificates periodically.

Monitoring and Logging Tools

To keep track of all controls and activities, AWS offers several monitoring and logging tools:

AWS CloudTrail
AWS CloudWatch
AWS GuardDuty

AWS CloudTrail and AWS CloudWatch have been discussed in Section 4.2. AWS GuardDuty is an intelligent threat protection tool (powered by machine learning) that continuously monitors for suspicious activity and unauthorized behavior to protect your AWS accounts, workloads, and data stored in Amazon S3. It feeds in data from various sources like VPC Flow Logs, AWS CloudTrail Event Logs, and DNS logs and does profiling of what is usual. In case of deviation, raise the alarm. This is a very suitable service to automatically monitor and alert any malicious activity for the SAP setup.

Security Event Response Mechanism

The services and tools mentioned earlier help you prevent a security event. Monitoring and logging tools help detect and alert for one. You should have a robust incident management process to respond to any reported security event in the SAP landscape. Use automation tools, wherever available, to have a swift and speedy investigation and recovery and periodically perform a simulation run for security event handling as well that way you plan for disaster recovery and your business continuity.

The next section covers the security aspects associated to Amazon Virtual Private Cloud Security (VPC) that is one of the first configurations that you need to perform as a preparation for hosting the SAP landscape in the AWS cloud.

Amazon Virtual Private Cloud Security (VPC)

To deploy any instance on AWS, you create a VPC; it’s a part of the cloud foundation. A VPC provides you the isolated environment in AWS from the outer world or any other account on AWS or even from any other VPC within the same AWS account as long as you are not enabling the VPC peering. VPCs have an IP range, and you can launch S/4 EC2 instances with private IP addresses that belong to the VPC IP range. Now to provide more security, you need to create a subnet, security group, and Network Access Control List (ACL) to control inbound and outbound traffic. Figure 5-33 provides you an overview about the setup.

The network traffic flow has been depicted in Figure 5-34. The VPC enables you to create an isolated environment within AWS with private IP addresses associated with EC2 instances. To secure your environment, you need to enable a firewall in the VPC for both ingress and egress traffic from EC2 instances. You can restrict the traffic by IP addresses and ports. A firewall is not managed from a guest OS; it can only be modified from VPC APIs. API access calls are used to create, delete, change in routing, security groups, and other functions through your Secret Access Key, without Secret Access Key VPC API calls cannot be possible. It is always recommended to use SSL encrypted API endpoints.

Subnet and Routing Tables

A subnet is the next layer of security. You can create one or more subnets in a single VPC to launch EC2 instances within the same CIDR block. For example, you can create one production subnet and one non-production subnet where you will deploy all non-production EC2 instances in the non-production subnet and all production EC2 instances in the production subnet. So in this way, you can segregate the CIDR block as well as you can control the traffic from/to prod and non-prod systems more granularly.

Network Access Control List

A network ACL is the next layer of security in the VPC; you can configure the network ACL to control the inbound and outbound traffic from the subnet. The ACL is maintained in the same way as the firewall with source/destination IPs, service ports, and IP protocols. The network ACL operates at the subnet level and it’s stateless, which means the response of the request is not allowed by default; it must be defined explicitly in inbound and outbound rules. Here, the lowest number rule gets the highest priority to allow or deny the request. For example, if you allow the request at rule no. 100 and deny the same request at rule 200, then the network ACL will allow the request.

Security Groups (SGs)

Security Groups work as a virtual firewall at the EC2 instance level to control inbound and outbound traffic to/from an instance. It works in instance and subnet levels; hence, you can configure different sets of security rules in different instances within the same subnet and the same VPC. If you don’t specify any security group at the instance level, it will use the default security group for the VPC.

A Security Group is stateful, which means if you send an outbound request, then the response of that request will get into the instance regardless of inbound rules, and for an inbound request, the response will go out regardless of the outbound rules you set in the security group. When you create an SG, by default it will come with outbound rules which allow all outbound traffic, and you can modify the outbound rules, and with no inbound rules, that means it will deny all inbound traffic. So, when you create an SG, no instances in the same subnet can communicate with each other unless you create inbound rules to allow traffic. SGs are associated with network interfaces (NICs).

Virtual Private Gateway

A virtual private gateway allows you to establish a secured connection between your Amazon VPC and other networks. You can establish a network connection to virtual private gateways from on-premises gateway devices.

Internet Gateway

An Internet Gateway is attached with a VPC and allows you to directly connect to Amazon S3, other services, and the Internet. To allow this kind of request, you need to create an Elastic IP address or NAT Gateway in a public subnet; every Internet-facing request should pass through either an Elastic IP or NAT (Network Address Translation) Gateway.

Hope now you have an idea how you can set up the network security in your SAP environment. To know more in detail, go through the following AWS network guide:

https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html

Backup and Restore in AWS

A backup is one of the first lines of defense that you must put in place for all AWS resources critical for running the SAP landscape. AWS provides several tools as well as integration options to third-party solutions to back up your operating system and database.

Primary backup entities are

The EC2s hosting the SAP workload.
Backup of all the storages where SAP systems’ related data is stored.
Backup of databases operating with SAP systems.

This section summarizes the different ways of taking backups on AWS via AWS Backup, a third-party solution, and the built-in solutions for each of the databases (dump to disk).

Here, we will discuss the AWS-native backup solution which you can design for EC2 instances, file systems, and SAP HANA DB and to be stored in the S3 storage with a proper life cycle. Earlier, we used to take disk-level HANA DB and log backup via the HANA studio or HANA cockpit and then transfer the backup files to S3 via a script. Now to eliminate this operational overhead and additional storage cost for backups, AWS recently introduced its own backup solution through which you configure the HANA DB backup/recovery directly to/from the S3 storage.

SAP HANA DB Backup/Recovery via AWS Backint Agent

AWS Backint agents work in a similar way as other third-party Backint agents. You need to install the AWS Backint agent from the AWS Systems Manager console and then provide the S3 bucket details where data to be backed up, during Backint agent installation. Only S3 buckets which are created after May 2019 are compatible with the AWS Backint agent.

As of now, the AWS Backint agent only supports S3 Standard, S3 Standard IA, and S3 One Zone-IA storage classes. S3 Glacier is not supported by the Backint agent. Once you are done with the agent installation and configuration, you need to update Backint-related parameters in HANA DB (global.ini configuration file) to configure the DB and log backup from HANA studio or HANA cockpit with Backint options instead of file systems. By default, the HANA log backup is scheduled in every 15 mins, but you can adjust the frequency as per your defined RPO. Here, we have to configure the S3 life cycle to store the backup files most economically. Table 5-4 shows an indicative example of storing backups in AWS S3 as per the backup policy in different S3 storage classes in the most cost-optimized way. Plan the life cycle of backups as per the requirements on your side.

Table 5-4 Backups and Storage Types in AWS

Full size table

In order to install and configure the AWS Backint agent for SAP, you can simply follow the AWS user guide, accessible at the following link:

https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-prerequisites.html

EC2 Instance and EBS Volume Backup to S3

To protect your environment, you also need to take a backup of

EC2 instance
EBS storage
EFS file storage

You can take a snapshot backup of EC2 instances and EBS volumes to protect your SAP system from any kind of failure. EBS volumes are backed up individually as a snapshot to S3.

An EC2 snapshot backup includes an AMI (OS configuration) and all the EBS volumes attached to it. So you can create a clone of the existing server or restore the existing server within a few minutes in case of a server crash.

One thing to remember is you cannot move the snapshot to different S3 storage classes; the snapshot is an AWS managed service, and it is always stored in the S3 Standard storage.

Now we will demonstrate how you can take EC2 and EBS snapshots.

Log in to an AWS account, and go to the EC2 dashboard where you can see all the EC2 resources deployed in your AWS region. Figure 5-35 shows you an overview about the deployed instances.

Now click Instances to see the number of running instances and to see the storage attached to EC2; click the instance ID and go to the storage option. Here, you can see one instance (focerpnv01) running with one root volume and one EBS volume. Now let’s see how we can take the EBS volume and EC2 instance snapshot backup.

Snapshot Backup from AWS Console

Click the snapshot option from the EC2 dashboard and create a snapshot.

Figure 5-36 shows the start screen when creating a snapshot. You can see any snapshots created in the past in the upper half of the screen. Those have been created on August 18.

Now we need to select which snapshot you want to take; if you take a specific EBS snapshot, select Volume, else select Instance to take snapshots for all the EBS volumes attached to the instance.

In Figure 5-37, we have selected Instance as we have taken all the volumes. Now you need to select the correct instance ID. You must exclude the root volume, then only EBS volumes will be backed up. You can add tags as per your defined policies.

Your snapshot is ready once you click the Create Snapshot button. Now if you go to the Snapshot option from the EC2 dashboard, you can see your two “testsnapshot,” one for the root volume and one for the EBS volume, as shown in Figure 5-38.

Once you return back to the overview page, you will see the additional snapshots, which have been created on top of the already existing ones. This is shown in Figure 5-39.

EC2 Image Backup

Select the instance, for which an image shall be created. Go to Actions ➤ Image and templates ➤ Create image, enter the details like the image name and other required details, then click the Create image button as shown in Figure 5-40.

Now you can see the instance image in Images ➤ AMIs as shown in Figure 5-41.

AWS Backup

AWS recently introduced “AWS Backup,” an AWS managed service. The features of AWS backup service are manifold. This is a centralized backup solution, which you can use to automate the backup of AWS resources like the EC2 instance AMI, EBS volume, EFS file share, etc. You can create backup policies via a backup plan including scheduling, retention period, and backup monitoring. You can also directly configure the AMI backup for different regions; it automatically copies the AMI (which is tagged as the DR region) to the DR region. So, in case of disaster, you can quickly restore the system in the DR region using the primary server AMI. Now the “AWS Backup” service supports only EBS, EC2, EFS, RDS, DynamoDB, Storage Gateway, and Amazon FSx resources.

Backup Configuration Steps from AWS Console

Search AWS backup in the service area and click AWS Backup. Create a backup plan as per your customer backup policies. The start screen is shown in Figure 5-42.

Once you start creating the backup plan, you can either start from a template base of build a new plan or you use an existing JSON expression for building the plan as shown in Figure 5-43. In this example, we will go ahead and build a new plan from scratch.

Figure 5-44 shows you the details, which you will need to define for the new backup plan. This includes some important values, like the frequency, but it also includes some values for the movement of backups to cold storage to reduce some costs. This depends on the backup policy of your company or your customer.

Click Create plan, and your backup plan is ready (see Figure 5-45); now you need to assign the resources to be backed up. You can assign resources in two ways: via Tags or Resource ID. If you select Tag, then all the resources with the same tag will be included in your policy, and if you select Resource ID, then you have assigned resources to be included in the backup plan. Here in this example, I have selected Resource ID.

To select a resource and assign it to the backup plan, click the button “Assign resources,” and it will bring you to the next screen as shown in Figure 5-47.

Now you can see this resource in your backup plan, which will be backed up and retained as per the policy you set. Create an AWS account to explore all the options as much as you can.

Restore Snapshot from AWS Console

You need to test the restore process for a noncritical environment at least once in a quarter to check if you meet your RPO/RTO. You can restore EC2 instances including all the configurations of your source system, or you can restore only the EBS volume and mount it to any EC2 instance. Here, we will show you how you can restore an EC2 instance AMI.

As shown in Figure 5-48, go to AMIs ➤ Images; here, you have all the images taken into your AWS region. Select the AMI to be restored and launch it.

Select a target instance type, here we have selected t2.micro, and complete the launch wizard with all the details, then review and launch the instance.

In Figure 5-49, you can see one root and one EBS volume which were included in the AMI. You can add more EBS volumes or remove existing EBS volumes as per your requirement, but you cannot remove the root volume.

You should have the key pair to log in to the instance after launch. In Figure 5-50, we choose an existing key pair as we already have it. You select the “create key pair” option to launch the instance first time.

Now your new EC2 instance is ready with the image of the existing instance. This is the basic backup-restore process you can do from the AWS console. You can do this from the AWS CLI and automate this process. You just create an AWS account and explore the options as much as you can.

Disaster Recovery via AWS

The reader will learn about the possibilities to implement a proper DR solution based on AWS mechanisms or database-based DR mechanisms. This section will also help in determining the RTO/RPO per solution.

Disaster recovery is a very important aspect in SAP environments and for business continuity. In AWS, you can plan and design your DR solutions for production workloads in a single region with multiple availability zones or in different regions as per customer requirements. Here, we will show you how you can design different types of DR solutions based on a defined RPO (Recovery Point Objective) and RTO (Recovery Time Objective).

Passive DR Architecture – RPO Is More Than Zero and RTO Is Higher

This is the most cost-effective DR solution where you don’t need to set up an SAP DR environment in advance; hence, there will not be any running cost for EC2 instances and storage. In the architecture shown in Figure 5-51, you can see how we can achieve passive DR in cross-regions.

It’s very easy and simple to deploy SAP systems in other regions in case of a disaster in the primary region. To do this, you have to configure a backup of DB, EC2 instances, and EFS storage if it’s in use.

Steps to Configure the Passive DR

Configure the HANA DB data and log backup via the AWS Backint agent or any third-party backup tool and store the backup to an S3 storage.
Enable S3 Cross-Region Replication (CRR).
Create a backup plan and configure an AWS backup for EC2 instance AMIs (S/4 and HANA DB AMI) and EFS storage.
The AWS backup will replicate the AMI to the DR region.

Steps to Invoke Passive DR

Restore the S/4 application and HANA DB server from the AMI backed up through the AWS backup.
Restore and recover the HANA database from the S3 backup.
Mount the EFS file system copied to the DR region.
Start the HANA DB and S/4 application.

If you configure DR in the same region but different availability zones, then Cross-Region Replication and AWS backup need not be configured.

Semi-active DR Solution [RPO Is Near to Zero and RTO Is Medium]

You can go with this DR solution where you need

RPO is defined near to zero, and RTO is medium.
Cost-optimized DR solution.

Here, you need to deploy the HANA DB system in the DR region with smaller sizing than primary. Your DR HANA DB server memory sizing would be minimum DB row store table size + 60 GB. You have to configure the HANA System Replication with asynchronous replication mode and log-replay or delta-replay operation mode to replicate the data from the primary to the DR site continuously. As here we are going with the smaller DB DR server compute size to minimize the running DR cost, the preload table option must be turned off during the HSR configuration between primary and secondary:

global.ini/[system_replication]-> preload_column_tables=false

You need to configure the AWS backup for S/4 application EC2 instance AMIs and EFS storage to restore the SAP application in the DR region. The architecture is shown in Figure 5-52.

Steps to Configure the Semi-active DR

You will need to perform the following steps to create a semi-active DR solution for your SAP system:

Estimate the DR DB server sizing (row store table size + 60 GB). A minimum of 64 GB memory is required to install HANA DB.
Calculate the row store size: Select host, round (sum(page_size*USED_BLOCK_COUNT)/1024/1024/1024,2) as “RowStore Size GB” from m_data_volume_page_statistics where page_sizeclass = ‘16k-RowStore’ group by host. Provision the HANA DB VM and install HANA software.
Configure HANA System Replication with asynchronous replication mode and log-replay operation mode.
Turn off the preload table option.
Configure the AWS backup for SAP S/4 instances and EFS storage.

Steps to Invoke DR

In order to invoke the failover in case of a disaster, you will need to perform the following steps:

Perform a HANA takeover in the DR site.
Stop the DR HANA database.
Resize the HANA VM the same as the primary server.
Start the HANA database.
Restore SAP S/4 application instances from the AMI backed up in the AWS backup.
Mount the EFS file system to application servers.
Start the S/4 application.

If you configure the DR in the same region but different availability zones, you can use a quality server as the DR server to reduce the cost. In case of a disaster, stop the quality system and resize the VM to invoke the DR. No need to configure the AWS backup in the same region.

Active-Active DR Solution [RPO Near to Zero and RTO Is Very Less]

You can go with this DR solution if your requirements meet the following conditions:

RPO is near to zero, and RTO is very less.
The DR environment should be in an operating state within a couple of hours.
This is the most expensive DR solution.

The active-active DR design is the same as semi-active DR; the only difference is here we will provision the HANA DB server the same as the primary one.

Steps to Configure the Active DR

For creating the active DR for your SAP system, you will need to perform the following steps:

Provision the HANA DB server in the DR region with the same compute and storage as the primary.
Install HANA DB software.
Configure HANA System Replication with asynchronous replication mode and log-replay operation mode while enabling the preload option.
Configure the AWS backup for SAP S/4 application EC2 AMIs for the DR region.
Configure the AWS backup of the EFS storage for the DR region so that you can mount the same file systems to DR servers.

Steps to Invoke DR

After configuring the DR, you may invoke it as follows:

Perform a HANA DB takeover.
Restore SAP S/4 application EC2 instances from AMIs backed up through the AWS backup.
Mount EFS file systems to DR servers.
Start the SAP S/4 application.

A DNS update is a mandatory step once you invoke the DR environment in case of a disaster. Your SAP S/4 application server hostname or alias must be the same as the primary server, but the IP would be different. So once your traffic switched to DR servers, you need to just replace the primary server IP with the DR server IP address in the DNS server. So, there are no changes required from the end user and interface perspective in case of an actual disaster.

You can achieve zero RPO and very less RTO if you configure the DR environment in the same region with different availability zones to configure HANA System Replication with synchronous replication mode and log-replay operation mode.

SAP HANA HSR Setup Guide

For setting up the HANA System Replication, there is a comprehensive user guide available from SAP. You can access it at the following link:

https://help.sap.com/doc/c81e9406d08046c0a118c8bef71f6bdc/2.0.04/en-US/SAP_HANA_System_Replication_Guide_en.pdf

Summary

Now you have an idea on how to place an SAP S/4HANA system on the AWS public cloud. Here, we will conclude this chapter with AWS core components required to deploy SAP S/4HANA systems on AWS.

Cloud Foundation Design and Implementation

First, you need to assess and design the cloud framework on which your SAP system will be deployed, like as follows:

AWS region: Finalize AWS primary and secondary regions.

Network design: Finalize the network design including

On-premise to AWS connectivity (site-to-site VPN, Direct Connect)
Subscription design (Hub ➤ Spoke)
VPC
Subnet design
Resource group policy
Tagging policy

Security design: Security plays an important role in the public cloud. You need to take proper security measures to protect your SAP system from unknown threats and vulnerabilities:

IAM service
OS hardening
Security group
Network Access Control List
Routing table

Once you finalize the design, build the cloud foundation for SAP deployment.

SAP S/4 Architecture Design and Implementation

Assess and understand the customer requirement and design your S/4 architecture on AWS accordingly. It should be a cost-optimized architecture which fulfills customer requirements as well.

Self-healing or default deployment: If no HA DR is required, standard deployment will be on AWS EC2 instance. This is called a single-AZ and single-node architecture.

HANA scale-out deployment: If you have a HANA scale-out environment, then you have to go with single-AZ and multinode deployment. You can add a standby node if you need a HANA HA environment without implementing any additional tool (like Pacemaker).

S/4HANA HA deployment: Here, you need to deploy your S/4 application and HANA DB in multi-availability zones with Overlay IP using Transit Gateway or Network Load Balancer and Pacemaker or the WSFC cluster solution to configure the S/4HANA application–level high availability.

S/4HANA HA and DR deployment: This is an expensive one. Here, you need to deploy S/4HANA in multi-availability zones for HA and different regions for DR server deployment. You can use DR in multi-availability zones as well to optimize the cost. It’s totally based on customer requirements.

To minimize the cost, you can also use your QA server as an environment. In this case, you need to deploy your QA in different AZs than production, deploy production HANA DB in a QA environment, and configure async replication with a production system. In case of a disaster, stop the QA system and start HANA DB. (Resize your EC2 instance type if required.)

Now to implement the SAP S/4HANA architecture, you need to go with the following components:

Compute: Based on the sizing, select the right and SAP-certified EC2 instance type.

Storage: Select the AWS standard disk and storage layout for S/4HANA. This is a very important thing because disk throughput depends on the storage configuration.

PAYG or Reserved Instance: Based on the usage, you need to go with PAYG or Reserved Instance. You should always use a reserved instance if it’s being used for 24*7 throughout the year. It is always recommended to use with a PAYG model and, after a couple of months’ observation, reserve the right instance type for your application.

Backup and restore: A backup is an important aspect as customers have to adhere to several data compliance policies. First, you need to finalize the backup-restore policies with customers during the design phase.

Configure an AWS VM backup and a disk snapshot for instances and file systems and use AWS HANA backup tools to configure the HANA database and log backup as per the defined and agreed backup policies.

Author information

Authors and Affiliations

Bern, Switzerland
André Bögelsack
Kolkata, India
Utpal Chakraborty & Dhiraj Kumar
Irschenberg, Germany
Johannes Rank
München, Germany
Jessica Tischbierek
Ismaning, Germany
Elena Wolz

Authors

André Bögelsack
View author publications
You can also search for this author in PubMed Google Scholar
Utpal Chakraborty
View author publications
You can also search for this author in PubMed Google Scholar
Dhiraj Kumar
View author publications
You can also search for this author in PubMed Google Scholar
Johannes Rank
View author publications
You can also search for this author in PubMed Google Scholar
Jessica Tischbierek
View author publications
You can also search for this author in PubMed Google Scholar
Elena Wolz
View author publications
You can also search for this author in PubMed Google Scholar

Rights and permissions

Reprints and permissions

Copyright information

About this chapter

Cite this chapter

Bögelsack, A., Chakraborty, U., Kumar, D., Rank, J., Tischbierek, J., Wolz, E. (2022). SAP S/4HANA on AWS Elastic Compute Cloud – Deployment. In: SAP S/4HANA Systems in Hyperscaler Clouds. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-8158-1_5

Download citation

DOI: https://doi.org/10.1007/978-1-4842-8158-1_5
Published: 20 May 2022
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-8157-4
Online ISBN: 978-1-4842-8158-1
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)

Publish with us

Policies and ethics