Getting Started with Architecting SAP on the AWS Cloud

Rahul Kabra is a Partner Solutions Architect at Amazon Web Services (AWS).

If you are considering moving your SAP workloads to AWS, you’re probably wondering what your SAP architecture would look like on AWS, how different it would be to run SAP on AWS vs. running it on premises or in your private cloud, and how your business might benefit from migrating to AWS. This introductory article will touch on these topics and will provide you with key data points to prepare you for migrating and operating SAP workloads on AWS.

Architecting your SAP landscape on AWS does require a minor mind-set change to take advantage of the agility and scalability that AWS offers for SAP workloads. You’ll also want to understand how SAP architectures leverage various AWS services, and how the AWS environment provides better security and availability than a traditional environment. In this post, we’ll explore architectural components to give you an overview of SAP on AWS.

Core AWS services that are relevant for SAP

Here are some of the AWS core services you should be familiar with to get started with your SAP deployments:

Amazon VPC – The Amazon Virtual Private Cloud (Amazon VPC) service provides a logically isolated section of the AWS Cloud where all your AWS resources get deployed. Amazon VPC provides virtual networking features and security, which you can control to help ensure that only relevant and approved network traffic flow into and out of the VPC. For additional information on VPC design and architectural patterns for SAP, see VPC Subnet Zoning Patterns for SAP on AWS, published earlier on this blog.
Amazon EC2 – The Amazon Elastic Compute Cloud (Amazon EC2) service provides virtualized hosts where SAP application servers and databases can be installed. AWS provides multiple instance families that are certified for running SAP workloads, ranging from small, multi-purpose instances to high-memory instances on which you can run in-memory workloads like SAP HANA.
Amazon EBS – Amazon Elastic Block Store (Amazon EBS) is a block-based storage service that is used for hosting SAP application and database data, log files, and backup volumes. AWS provides multiple EBS volume types to meet the SAPS, IOPS, and throughput requirements of your SAP applications.
Amazon EFS – Amazon Elastic File System (Amazon EFS) provides a shared file system that can be attached across various EC2 hosts. This file storage can be particularly useful for SAP scale-out instances, where shared files like /usr/sap/trans or /sapmnt/<sid> need to be mounted.
Amazon S3 – Amazon Simple Storage Service (Amazon S3) is a scalable and durable object-based storage service, which is used for storing SAP application backups and snapshots.
Amazon Glacier – This service provides highly scalable, durable, and cost-effective object storage that can be used for long-term backups, and data that needs to retained for compliance or regulatory reasons.
IAM – AWS Identity and Access Management (IAM) is used to create and manage AWS users and groups. You can securely control access to AWS resources using IAM roles.
CloudWatch – Amazon CloudWatch is a monitoring service for AWS resources. It is critical for SAP workloads, where it’s used to collect resource utilization logs and to create alarms to automatically react to changes in AWS resources.
CloudTrail – AWS CloudTrail keeps track of all API calls made within your AWS account. It captures key metrics about the API calls and can be useful for automating trail creation for your SAP resources.
AWS CLI – AWS Command Line Interface (AWS CLI) is a tool for managing and operating AWS services via command line or scripts. We’ve provided some examples in the “AWS Automation” section later in this blog post.
Route 53 – Amazon Route 53 is a scalable and highly available DNS service. You can use it to create hosted zones, traffic policies, and domains on AWS, and to connect to non-AWS resources.

AWS sizing and performance

The AWS platform allows enterprises to provision the right type and size of computing resources in a self-service manner, without the need for large, upfront investment in hardware. One of the primary advantages of moving to AWS is that you gain the flexibility and agility to adjust your resources to your changing business needs. For example, AWS provides a global footprint that currently includes 16 AWS Regions and 42 Availability Zones to host your SAP landscapes near your customer base in a secure, highly available manner. Unlike traditional on-premises setup, the AWS Cloud environment lets you resize your SAP EC2 instances with a few clicks in the Amazon EC2 console, as shown in the following screen illustration, or with a simple API call.

Resizing your existing EC2 instance from the Amazon EC2 console

You get almost instant access to as many resources as you need, and you pay only for what you use. This means that infrastructure architects don’t have to guess or include a buffer when determining compute/memory sizing requirements for new projects. Also, during special events like month-end or open-enrollment periods, it becomes very easy to add capacity to existing hosts, with the option of scaling out your SAP application or database tiers. AWS provides both memory-optimized and compute-optimized instance types to meet your resource requirements, and has worked closely with SAP to get these certified for SAP workloads. See SAP Note 1656099 to get a list of certified AWS instances for SAP. (SAP notes require SAP Service Marketplace credentials.)

Designing SAP applications on AWS means that not all SAP applications need to be operational at all times. Non-critical SAP systems such as sandbox, training, and demo systems can be shut down when they’re not in use, resulting in significant cost savings.

One of the performance enablers on AWS is the way storage is configured. EBS volumes are replicated within an Availability Zone, so they’re already protected against data loss. For this reason, EBS volumes can be striped via RAID 0, which provides the maximum performance. This isn’t possible in most on-premises environments. For details on various EBS volume types and performance characteristics, see the post Deploying SAP HANA on AWS – What Are Your Options on this blog. These EBS volumes can be utilized for non-HANA databases as well.

AWS automation

AWS is a leader in cloud automation and provides multiple options for programmatically scripting your resources to operate or scale them in a predictable and repeatable manner. You can execute scripts to automate SAP operations such as creating new SAP application servers, taking backups and snapshots, and building new instances from the ground up.

Here are some examples to illustrate how easy is it to take snapshots of your existing SAP HANA data volumes for backup, and to restore those volumes on your server. These commands can be easily scripted and executed as part of your backup/recovery process via crontab or any other time-based job scheduler tools.

Example 1: Taking a snapshot of existing SAP HANA data volumes

Stop the SAP HANA instance:
sudo su – <sid>adm -c "HDB stop"
Quiesce the file system:
umount /hana/data

Identify the SAP HANA volume IDs attached to the instance:

aws ec2 describe-volumes --region=us-west-2 --filters Name=attachment.instance-id,Values=i-03add123456789012 Name=tag-value,Values="HANA*" --query 'Volumes[*].{ID:VolumeId,Tag:Tags}'

Response:

[
    {
        "Tag": [
            {
                "Value": "HANA_root",
                "Key": "Name"
            }
        ],
        "ID": "vol-071111111111111"
    },
    {
        "Tag": [
            {
                "Value": "HANA_data #1",
                "Key": "Name"
            }
        ],
        "ID": "vol-082222222222222"
    },
    {
        "Tag": [
            {
                "Value": "HANA_data #2",
                "Key": "Name"
            }
        ],
		"ID": "vol-0733333333333"
     }
]

Take a snapshot of the SAP HANA volumes:
aws ec2 create-snapshot --region=us-west-2 --volume-id vol-07222222222222 --description "HANA Server Data volume #1"; aws ec2 create-snapshot --region=us-west-2 --volume-id vol-08333333333333 --description "HANA Server Data volume #2
Mount back the SAP HANA data volumes (this can be done while the snapshot is in a pending state):
mount /hana/data
Start SAP HANA:
sudo su - hxeadm -c "HDB Start"

Example 2: Restoring data from a snapshot and attaching it to your existing host

Create a new volume from the snapshot:
aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --snapshot-id snap-1234abc123a12345a --volume-type gp2
Attach the newly created volume to your EC2 host:
aws ec2 attach-volume --region=us-west-2 --volume-id vol-4567c123e45678dd9 --instance-id i-03add123456789012 --device /dev/sdf
Initialize the volume to optimize the read operation (highly recommended for production scenarios):
fio --filename=/dev/xdf --rw=randread --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
Mount the logical volume associated with SAP HANA data on the host:
mount /dev/mapper/hanaexpress-lvhanaexpressdata /hana/data
Start SAP HANA:
sudo su - hxeadm -c "HDB Start"

There are other ways you can leverage automation for SAP on AWS:

Use Amazon Machine Instances (AMIs) to create new copies of your SAP instances.
Automatically create new SAP instances using AWS CloudFormation, or use the AWS QuickStart for new SAP HANA deployments in the cloud.

HA and DR using multiple Availability Zones and Regions

In traditional on-premises SAP deployments, high availability (HA) is handled within a single, physical data center. In contrast, AWS allows HA deployments across multiple Availability Zones in the same AWS Region. Availability Zones are physically isolated collections of data centers, connected via low network latency, in the same geographical region. For some customers, this HA setup may be sufficient for disaster recovery (DR) as well. If not, you can take advantage of the multiple options AWS offers with flexible pricing to leverage a second region in a different part of the country or world. The following diagram shows a sample distributed architecture for SAP.

Distributed SAP architecture on AWS

SAP operations

Compared with on-premises environments, AWS provides more transparency and accountability in the operation of SAP systems, with the help of monitoring services such as Amazon CloudWatch and AWS CloudTrail. You can use IAM roles and policies, security groups, and network ACLs for fine-grained security access control to AWS resources.

Monitoring services – Services like CloudWatch and CloudTrail can be helpful in monitoring resource utilization. CloudWatch enables you to create alarms to monitor and automatically recover an instance if it becomes impaired due to an underlying hardware failure. For details, see the AWS documentation.
Security – IAM allows refined controlled access to AWS resources and lets you create roles to enable secure communication between different services without having to copy AWS access keys. For details, see the AWS documentation.
Backups – If your organization uses a backup tool that supports direct Amazon S3 integration, you can back up your database directly into your S3 bucket. If not, you can use your existing backup tools to first export your files to an EBS volume, and then sync it with Amazon S3.

AWS Simple Monthly Calculator

Unlike the on-premises world where it is really difficult to get a comprehensive understanding of hardware and operational costs, AWS provides you with tools to map the costs of the infrastructure and various payment models for EC2 instances, including On-Demand and Reserved Instances.

Next steps

For more details on SAP on AWS, use the following resources:

Read SAP on AWS whitepapers – Great material for understanding the architectures and deployment options for SAP on AWS.
Read the SAP on AWS blog – We have quite a few blog posts that dive deep into various SAP topics.
Sign up for an AWS training class – AWS provides great training resources to help you get up to speed on various AWS services. Consider taking a class like AWS Technical Essentials to get prepared for AWS.
Get AWS certified – Getting an AWS Solutions Architect Associate or Professional certification can provide you with architectural and best practices guidance for deploying SAP and non-SAP applications on AWS.
Reach out to your consulting partner – If there’s a consulting partner that you actively work with, contact them about getting involved with your SAP migration to AWS.

– Rahul

AWS for SAP