How AWS Launch Wizard for SAP works
AWS Launch Wizard provisions and configures the infrastructure required to run SAP HANA database
and SAP NetWeaver based SAP applications on SAP HANA or SAP ASE database on AWS. You
select the SAP deployment pattern and provide the specifications, such as operating system,
instance size, and vCPU/memory. Or, Launch Wizard can make these selections for you according to
SAP Standard Application
Benchmarks
Launch Wizard recommends Amazon EC2 instances by evaluating the SAP Standard Application
Benchmarks
Launch Wizard maintains a mapping rule engine built on the list of certified EC2 instances that are supported by SAP. When you enter your vCPU/memory or SAPS requirements, Launch Wizard recommends an Amazon EC2 instance that is certified for SAP workloads and offers performance that is no less than your input requirements. For certain workloads, such as SAP HANA in a production environment, Launch Wizard recommends instances based on the official SAP recommendations for SAP HANA database workloads. For workloads in a non-production environment, Launch Wizard recommends Amazon EC2 instances that meet SAP recommended requirements; however, the recommended instances are not enforced. You can change the instance types after deployment, or you can override the recommendation by making manual selections.
In addition to launching instances based on the SAP system information that you provide, such as SAP System Number and SAP System Identifier (SAP SID), Launch Wizard performs the following operations:
-
Configures the operating system
-
Configures hostname
-
Attaches security groups so that the systems in the cluster that use the same configuration template, and also external systems, can communicate with the SAP systems that will be deployed on these instances.
Launch Wizard provides an estimated cost of deployment. You can modify your resources and instantly view an updated cost assessment. After you approve the deployment, Launch Wizard validates the inputs and flags inconsistencies. After you resolve the inconsistencies, Launch Wizard provisions and configures the resources. The result is a ready-to-use SAP application.
Launch Wizard creates a CloudFormation stack according to your infrastructure needs. For more information, see Working With Stacks in the AWS CloudFormation User Guide.
AWS Launch Wizard implements SAP deployments as follows.
Deployment aspects
- Storage for SAP systems
- Amazon Elastic File System setup for transport directory
- Amazon Elastic File System setup for SAP Central Services instances configured for high availability
- Bring your own image (BYOI)
- Specify private IP address
- Configuration settings
- Custom deployment configuration scripts
- Manual cleanup activities
- Default Quotas
- AWS Regions and Endpoints
Storage for SAP systems
Storage capacity and performance are key aspects of any SAP system installation. Launch Wizard provides storage type options for the SAP NetWeaver application tier, SAP HANA database tiers, and SAP ASE database tiers.
Amazon Elastic Block Store (Amazon EBS) volumes are included in the architecture to provide durable, high-performance storage. Amazon EBS volumes are network-attached disk storage, which you can create and attach to EC2 instances. When attached, you can create a file system on top of these volumes, run a database, or use them in any way that you would use a block device. Amazon EBS volumes are placed in a specific Availability Zone, where they are automatically replicated to protect you from the failure of a single component.
General Purpose EBS Volumes offer storage for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 16,000 IOPS (at 5,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size.
Provisioned IOPS Amazon EBS volumes offer storage with consistent and low-latency performance. They are backed by solid state drives (SSDs) and designed for applications with I/O intensive workloads, such as databases. Amazon EBS-optimized instances, such as the R4 instance type, deliver dedicated throughput between Amazon EC2 and Amazon EBS.
By default, Launch Wizard deploys Amazon EBS volumes for the SAP HANA database that meet the storage KPIs for SAP as listed in Storage Configuration for SAP HANA.
For NetWeaver database stacks, you can choose between a gp2
,
gp3
, io1
, or io2
volume for the
usr/sap/
and SAPSID
/sapmnt
(for
non-HA deployment architectures) file systems, whereas other configurations are deployed
with gp3
volumes. The gp3
volumes are used by default.
Launch Wizard also supports the use of Amazon FSx for NetApp ONTAP for SAP HANA databases. FSx for ONTAP file
systems can be used for data
, log
, and shared
(hana-shared
and usr-sap
) file systems. For more
information, see SAP HANA on AWS with
Amazon FSx for NetApp ONTAP.
In an SAP landscape, development occurs in the development system and is then imported into the QA and follow-on systems. For this import to occur successfully, a shared file system is required for SAP systems in the landscape. Amazon EFS is used to create the SAP Transport file system that is shared between multiple SAP systems in the landscape.
Amazon Elastic File System setup for transport directory
The SAP transport directory is a shared file system between SAP systems (for example, Development, Quality, and Production) that are part of the same SAP Transport Domain for releasing and importing SAP transports. To avoid a single point of failure, Launch Wizard creates a file system with Amazon Elastic File System or reuses existing file systems. It mounts the file systems on the SAP systems that you select based on the role of the system. The transport file system is mounted on all of the applications servers included in the deployment.
When systems within the same SAP Transport Domain are created in one VPC and need to be attached to SAP systems in other VPCs (for example, if Development and Quality are deployed in a VPC tagged as Non_Prod, and Production is deployed in a VPC tagged as Prod), a prerequisite for using VPC Peering/Transit Gateway is that you must enable the VPCs to be able to communicate. This allows Launch Wizard to attach the transport directory created in one VPC to instance(s) in other VPCs using a mount target in the same Availability Zone or other Availability Zones, as applicable. If the VPCs are not permitted to communicate, then the deployment will fail when it attempts to mount the transport file system created in one VPC to systems in another VPC.
Note
When a transport files system is created with Amazon Elastic File System, Launch Wizard considers it a shared resource and will not delete it when you delete the deployment or if the deployment is rolled back.
Amazon Elastic File System setup for SAP Central Services instances configured for high availability
The SAP Central Services instances that make up a NetWeaver high availability
deployment, ABAP Central Server (ASCS) and Enqueue Replication Server (ERS) instances,
must contain the following file systems to be highly available: /sapmnt
,
/usr/sap/
,
and
<SAPSID>
/ASCS<XX>
/usr/sap/
.
These file systems are built with Amazon EFS to avoid a single point of failure for the SAP
system. Launch Wizard creates these file systems for the NetWeaver high availability
pattern using a single Amazon Elastic File System. <SAPSID>
/ERS<XX>
The following table contains information about how a single Amazon EFS is configured and mounted on an ASCS, ERS, Primary Application Server (PAS), and Additional Application Server (AAS).
EFS ID | EFS DNS name | Instance mounted on | File System name | Server mounted on |
---|---|---|---|---|
fs- |
fs- |
fs- |
/sapmnt | SAP ASCS, ERS, Primary and Additional Application servers |
fs- |
fs- |
fs- |
|
SAP ASCS Server |
fs- |
fs- |
fs- |
|
SAP ERS Server |
Bring your own image (BYOI)
You can bring your own images to deploy and configure EC2 instances for SAP with AWS Launch Wizard. During launch, in order to continue with a deployment, Launch Wizard verifies whether the operating system version selected on the front end matches the operating system version of the instance. If the versions do not match, the deployment fails with an error.
When building your own image,consider the following:
-
Launch Wizard configures the operating systems with OS-level parameters and utilities required by SAP
-
Refer to SAP installation documents to ensure that operating system prerequisites are in place so that Launch Wizard deployments do not fail.
-
Launch Wizard accesses standard repositories provided by OS vendors. Do not block access to them.
-
Deployments by Launch Wizard use OS utilities and programs, such as zipper, yum, grep, printf, awk, sed, autofs, python, saptune, and tuned-profiles in the deployment script to configure SAP application and database servers. We recommend that you do not delete standard utilities.
Specify private IP address
You can specify available IP addresses that are already approved by your internal security and governance for each Amazon EC2 instance in your SAP deployment. The SAP environment is accessible as soon as the deployment is successful.
Launch Wizard, by default, auto-selects available IP addresses when a custom IP address is not provided.
When specifying a custom IP address, verify that it is within the range of the subnet of the instance that you are deploying.
Configuration settings
The following configuration settings are applied when deploying an SAP application with Launch Wizard.
Setting | Applies to |
---|---|
SSM Agent |
All SAP systems and patterns |
EBS volumes for SAP application tier |
All SAP systems and patterns |
EBS volumes for SAP HANA database, log and backup file systems |
All SAP systems and patterns |
EBS volumes for SAP ASE database, log and backup file systems |
All SAP systems and patterns |
EFS volumes for /hana/shared and
/backup |
|
EFS volumes for SAP transport file systems | All SAP systems and patterns |
EFS volumes for SAP central services: sapmnt ,
/usr/sap/<SID>/ASCS<XX> , and
/usr/sap/<SID>/ERS<XX |
ASCS and ERS systems |
OS parameters required based on the operating system chosen for database |
All SAP systems and patterns |
Security groups created and assigned for accessing the SAP system |
All SAP systems and patterns |
SSM Session Manager to remotely access the server for administrator activities |
All SAP systems and patterns |
Time zone settings at the OS level |
All SAP systems and patterns |
Custom deployment configuration scripts
You can use custom shell scripts during the pre-deployment and post-deployment configuration phases. You provide the scripts stored on Amazon S3 or locally. During provisioning, Launch Wizard installs the AWSTOE application. When there are custom scripts to run, Launch Wizard creates an AWSTOE document that downloads the scripts from the location specified and then runs the scripts. The success of the custom scripts is a customer responsibility. Check the CloudWatch log streams for detailed execution logs or failure information after the scripts are deployed.
The number of configuration scripts you can use depends on the deployment model. For SAP HANA deployments, you can use one script, which runs on all of the HANA instances (both primary and worker nodes). For NetWeaver stack on SAP HANA database, the following script limits apply:
-
NetWeaver stack on SAP HANA or SAP ASE single-instance deployment — Because all tiers are installed on the same database instance, you can use only one script.
-
NetWeaver stack on SAP HANA distributed-instance deployment — You can use one script per each instance tier selected, including for ASCS/SCS Server and Primary Application Server (PAS), Database (DB) Server, and Additional App Servers (AAS).
-
NetWeaver stack on SAP HANA high availability deployment — You can use one script per each instance tier selected, including for Primary Application Server (PAS), ABAP System Central Services (ASCS) Server, Database (DB) Server, Additional App Servers (AAS), and Enqueue Replication Server (ERS).
Pre-deployment configuration scripts
Pre-deployment configuration scripts run after the instances are launched and the baseline Launch Wizard configuration tasks, such as deploying Amazon CloudWatch, Amazon EC2 Systems Manager agents, and the AWS CLI, are complete. If you want to run multiple pre-deployment configuration scripts, Launch Wizard runs them in parallel on each EC2 instance in the order in which they are specified. Pre-deployment configuration scripts can be used to perform tasks such as OS hardening or deploying security and logging software. The maximum runtime for all pre-deployment configuration scripts on a single EC2 instance is 45 minutes.
Post-deployment configuration scripts
Post-deployment configuration scripts run when Launch Wizard completes configuration tasks specific to the application on all of the instances in a deployment. Before the provisioning process completes, post-configuration scripts run on all of the specified instance tiers. Launch Wizard uses SSM and AWS Lambda to trigger running post-deployment scripts on all selected SAP instances in the order in which they are specified. They can be used to perform tasks such as installing monitoring and management software, and for updating your DNS with entries for the newly deployed SAP servers and the domains joining them. The maximum runtime for all post-deployment configuration scripts on a single instance is 2 hours.
Manual cleanup activities
If you choose to delete a deployment, or a deployment fails during the deployment phase and rolls back, Launch Wizard deletes the Amazon EC2 and Amazon EBS volumes that it launches as part of the deployment. It also removes the AWSTOE application. The following resources are considered shared resources and are created without the deletion flag.
-
The Amazon Elastic File System file system that is created for the SAP transport files system
/usr/sap/trans
. -
The Amazon Elastic File System that is created for storing SAP software and media.
-
The security groups that you create.
These resources must be manually verified to ensure that they are not being used by other systems in the landscape. They must then be manually deleted from either the Amazon Elastic File System or Amazon EC2 consoles, or by using APIs.
Default Quotas
To view the default quotas for AWS Launch Wizard, see AWS Launch Wizard Endpoints and Quotas.
AWS Regions and Endpoints
To view the service endpoints for AWS Launch Wizard, see AWS Launch Wizard Endpoints and Quotas.