Menu
SAP HANA on AWS
SAP HANA Quick Start

Planning the Deployment

Before you deploy SAP HANA on AWS, please review the following sections for guidelines on instance types, storage, memory sizing, operating system choices, and Multi-AZ deployments.

AWS Instance Types for SAP HANA

This Quick Start supports the following instance types for the SAP HANA host:

  • x1.16xlarge, x1.32xlarge, x1e.4xlarge*, and x1e.32xlarge

  • r3.2xlarge*, r3.4xlarge*, and r3.8xlarge

  • r4.2xlarge* (default), r4.4xlarge*, r4.8xlarge, and r4.16xlarge

* These instance types aren't supported for SAP HANA production workloads.

The default instance type is r4.2xlarge, but you can switch to one of the other types during deployment. The r3.8xlarge, r4.8xlarge, r4.16xlarge, x1.16xlarge, x1.32xlarge, and x1e.32xlarge instance types are officially supported by SAP for production use. For more information about different instance types and their use cases, see the Amazon EC2 Instances webpage. For a list of SAP-certified EC2 instances, see the SAP HANA hardware directory.

Storage Configuration for SAP HANA

SAP HANA stores and processes all or most of its data in memory, and provides protection against data loss by saving the data in persistent storage locations. To achieve optimal performance, the storage solution used for SAP HANA data and log volumes should meet SAP's storage KPI. AWS has worked with SAP to certify both Amazon EBS General Purpose SSD (gp2) and Provisioned IOPS SSD (io1) storage solutions for SAP HANA workloads.

gp2 volumes balance price and performance for a wide variety of workloads, while io1 volumes provide the highest performance consistently for mission-critical applications. With these two options, you can choose the right storage solution that meets your performance and cost requirements. We highly recommend using the io1 configuration for your mission-critical SAP HANA workloads for production use.

Note that only x1e.32xlarge, x1.32xlarge, x1.16xlarge, r4.8xlarge, r4.16xlarge, and r3.8xlarge instances are certified for production use. You can use all the instance types supported by this Quick Start for non-production use.

For multi-node deployments, storage volumes for SAP HANA data and logs are provisioned in the master node and every worker node.

In the following configurations, we intentionally kept the same storage configuration for SAP HANA data and log volumes for all R3 and certain R4 instance types so you can scale up from smaller instances to larger instances without having to reconfigure your storage.

gp2-based storage configuration for SAP HANA data

Instance type Memory (GiB) vCPUs General Purpose SSD (gp2) storage for SAP HANA data (striped with LVM) Total maximum throughput (MiB/s)* Total baseline IOPS Total burst IOPS
x1e.32xlarge 3904 128 3 x 1600 GiB 480 9000 9000
x1.32xlarge 1952 128 3 x 800 GiB 480 7200 9000
x1.16xlarge 976 64 3 x 400 GiB 480 3600 9000
r4.16xlarge 488 64 3 x 225 GiB 480 2025 9000
r4.8xlarge 244 32 3 x 225 GiB 480 2025 9000
r3.8xlarge
x1e.4xlarge* 488 16 3 x 225 GiB 480** 2025 9000
r4.4xlarge* 122 16 3 x 225 GiB 480** 2025 9000
r3.4xlarge*
r4.2xlarge* 61 8 3 x 225 GiB 480** 2025 9000
r3.2xlarge*

* Not supported for SAP HANA production workloads.

** This value represents the maximum throughput that could be achieved when striping multiple EBS volumes. Actual throughput depends on the instance type. Every instance type has its own Amazon EBS throughput limit. For details, see Amazon EBS-Optimized Instances in the AWS documentation.

gp2-based storage configuration for SAP HANA logs

Instance type Memory (GiB) vCPUs General Purpose SSD (gp2) storage for SAP HANA logs (striped with LVM) Total maximum throughput (MiB/s)* Total baseline IOPS Total burst IOPS
x1e.32xlarge 3904 128 2 x 300 GiB 320 1800 6000
x1.32xlarge 1952 128 2 x 300 GiB 320 1800 6000
x1.16xlarge 976 64 2 x 300 GiB 320 1800 6000
r4.16xlarge 488 64 2 x 300 GiB 320 1800 6000
r4.8xlarge 244 32 2 x 300 GiB 320 1800 6000
r3.8xlarge
x1e.4xlarge* 488 16 2 x 175 GiB 262** 1050 6000
r4.4xlarge* 122 16 2 x 175 GiB 262** 1050 6000
r3.4xlarge*
r4.2xlarge* 61 8 2 x 175 GiB 262** 1050 6000
r3.2xlarge*

* Not supported for SAP HANA production workloads.

** This value represents the maximum throughput that could be achieved when striping multiple EBS volumes. Actual throughput depends on the instance type. Every instance type has its own Amazon EBS throughput limit. For details, see Amazon EBS-Optimized Instances in the AWS documentation.

io1-based storage configuration for SAP HANA data

Instance type Memory (GiB) vCPUs Provisioned IOPS SSD (io1) storage for SAP HANA data (striped with LVM) Total maximum throughput (MiB/s) Total provisioned IOPS
x1e.32xlarge 3904 128 3 x 1600 GiB 1500 9000
x1.32xlarge 1952 128 3 x 800 GiB 1500 9000
x1.16xlarge 976 64 1 x 1200 GiB 500 7500
r4.16xlarge 488 64 1 x 600 GiB 500 7500
r4.8xlarge 244 32 1 x 300 GiB 500 7500
r3.8xlarge
x1e.4xlarge* 488 16 1 x 600 GiB 500** 2000
r4.4xlarge* 122 16 1 x 300 GiB 500** 2000
r3.4xlarge*
r4.2xlarge* 61 8 1 x 300 GiB 500** 2000
r3.2xlarge*

* Not supported for SAP HANA production workloads.

** This value represents the maximum throughput that could be achieved when striping multiple EBS volumes. Actual throughput depends on the instance type. Every instance type has its own Amazon EBS throughput limit. For details, see Amazon EBS-Optimized Instances in the AWS documentation.

io1-based storage configuration for SAP HANA logs

Instance type Memory (GiB) vCPUs Provisioned IOPS SSD (io1) storage for SAP HANA logs (striped with LVM) Total maximum throughput (MiB/s) Total provisioned IOPS
x1e.32xlarge 3904 128 1 x 525 GiB 500 2000
x1.32xlarge 1952 128 1 x 525 GiB 500 2000
x1.16xlarge 976 64 1 x 525 GiB 500 2000
r4.16xlarge 488 64 1 x 260 GiB 500 2000
r4.8xlarge 244 32 1 x 260 GiB 500 2000
r3.8xlarge
x1e.4xlarge* 488 16 1 x 260 GiB 500** 1000
r4.4xlarge* 122 16 1 x 260 GiB 500** 1000
r3.4xlarge*
r4.2xlarge* 61 8 1 x 260 GiB 500** 1000
r3.2xlarge*

* Not supported for SAP HANA production workloads.

** This value represents the maximum throughput that could be achieved when striping multiple EBS volumes. Actual throughput depends on the instance type. Every instance type has its own Amazon EBS throughput limit. For details, see Amazon EBS-Optimized Instances in the AWS documentation.

In addition to the SAP HANA data and log volumes, all instances deployed by this Quick Start will have the following storage configuration for root, SAP binaries, and SAP HANA shared and backup volumes:

Instance type Memory (GiB) vCPUs Root volume (gp2) SAP binaries (gp2) SAP HANA shared [1] (gp2) SAP HANA backup [2] (st1)
x1e.32xlarge 3904 128 1 x 50 GiB 1 x 50 GiB 1 x 1024 GiB 1 x 8192 GiB
x1.32xlarge 1952 128 1 x 50 GiB 1 x 50 GiB 1 x 1024 GiB 1 x 4096 GiB
x1.16xlarge 976 64 1 x 50 GiB 1 x 50 GiB 1 x 1024 GiB 1 x 2048 GiB
r4.16xlarge 488 64 1 x 50 GiB 1 x 50 GiB 1 x 512 GiB 1 x 1024 GiB
r4.8xlarge 244 32 1 x 50 GiB 1 x 50 GiB 1 x 300 GiB 1 x 1024 GiB
r3.8xlarge
x1e.4xlarge* 488 16 1 x 50 GiB 1 x 50 GiB 1 x 512 GiB 1 x 1024 GiB
r4.4xlarge* 122 16 1 x 50 GiB 1 x 50 GiB 1 x 300 GiB 1 x 512 GiB
r3.4xlarge*
r4.2xlarge* 61 8 1 x 50 GiB 1 x 50 GiB 1 x 300 GiB 1 x 512 GiB
r3.2xlarge*

Notes

* Not supported for SAP HANA production workloads.

** This value represents the maximum throughput that could be achieved when striping multiple EBS volumes. Actual throughput depends on the instance type. Every instance type has its own Amazon EBS throughput limit. For details, see Amazon EBS-Optimized Instances in the AWS documentation.

[1] In a multi-node architecture, the SAP HANA shared volume is provisioned only once on the master node.

[2] In a multi-node architecture, the size of the SAP HANA backup volume is multiplied by the number of nodes. The SAP HANA backup volume is provisioned on the master node, and NFS is mounted on the worker nodes.

Storage for SAP HANA backup is configured with Amazon EBS Throughput Optimized HDD (st1) volumes. This volume type provides low-cost magnetic storage designed for large sequential workloads. SAP HANA uses sequential I/O with large blocks to back up the database, so st1 volumes provide a low-cost, high-performance option for this scenario. To learn more about st1 volumes, see Amazon EBS Volume Types in the AWS documentation.

The SAP HANA backup volume size is designed to provide optimal baseline and burst throughput as well as the ability to hold several backup sets. Holding multiple backup sets in the backup volume makes it easier to recover your database if necessary. You may resize your SAP HANA backup volume after initial setup if needed. To learn more about resizing your Amazon EBS volumes, see Expanding the Storage Size of an EBS Volume on Linux in the AWS documentation.

Memory Sizing for Deployment

Before you begin deployment, please consult the SAP documentation listed in this section to determine memory sizing for your needs. This evaluation will help you choose Amazon EC2 instances during deployment. (Note that the links in this section require SAP support portal credentials.)

Note

You can take full advantage of the 3,904 GiB of memory that the X1e instance offers for your production workloads depending on your sizing requirement. For details, see the SAP HANA Hardware Directory.

  • To obtain sizing information for a system that has not yet been implemented, use the SAP QuickSizer. The SAP QuickSizer provides information on both the SAP HANA in-memory database and the SAP NetWeaver application server where applicable.

  • To migrate an existing SAP NetWeaver Business Warehouse system from any database platform to SAP HANA, SAP strongly recommends the new ABAP sizing report for SAP NetWeaver BW, which is described in SAP Note 1736976.

Further sizing information is also available in the SAP HANA Administration Guide and in the following SAP HANA notes:

SAP note Description
1736976 Sizing Report for BW on SAP HANA
1637145 SAP BW on SAP HANA: Sizing SAP In-Memory Database
1702409 HANA DB: Optimal number of scale-out nodes for BW on SAP HANA
1855041 Sizing Recommendation for Master Node in BW-on-HANA
1793345 Sizing for SAP Business Suite on SAP HANA
1872170 Business Suite on SAP HANA memory sizing

Operating System for Deployment

This reference deployment supports the following operating systems and versions for your SAP HANA instance:

Operating system Supports Single-AZ deployment? Supports Multi-AZ deployment?
  • SLES 11 SP4

  • SLES 12

  • SLES 12 SP1

  • SLES 12 SP3

Yes No
  • SLES 12 SP1 for SAP*

  • SLES 12 SP2 for SAP*

  • SLES 12 SP3 for SAP*

Yes Yes
  • RHEL 7.3

Yes No

* Both AWS Marketplace and Bring Your Own Subscription (BYOS) are supported. You must provide a registration key for the BYOS option.

To learn more about the benefits of using SLES for SAP, see the SUSE product page.

Requirements for Multi-AZ, Single-Node HA Scenarios

If you choose the Multi-AZ, single-node, high availability deployment option, you must follow a few additional requirements. Otherwise, the Quick Start will display an error during parameter validation.

  • Subnets where primary and secondary SAP HANA instances will be deployed must share a common route table. Deploying the Quick Start into a new VPC will ensure this automatically. However, if you’re deploying the Quick Start into an existing VPC, you must ensure that your existing subnets have a common route table.

  • SLES HAE agents require that the Pacemaker tag and the overlay IP address you provide by setting deployment parameters can be uniquely identified. Therefore, you need to ensure the following:

    • The value you provide for the PaceMakerTag parameter isn’t being used by any other EC2 instances in your account, in the AWS Region where you are deploying the Quick Start.

    • The IP address you provide for the VirtualIPAddress parameter is outside the VPC CIDR and isn’t being used in the route table associated with the subnets where primary and secondary HANA instances will be deployed.

  • After deployment, we strongly recommend that you validate the setup of your environment before you use the HA cluster for production. For testing scenarios, see section 6 of the SUSE whitepaper, SAP HANA SR Performance Optimized Scenario.