AWS for SAP

Terraform your SAP Infrastructure on AWS

Introduction

SAP systems are critical for business operations, it’s important to adhere to SAP best practices when planning their deployments and operations. While customers are increasingly choosing RISE on AWS, many customers are running SAP on AWS natively, and so, when workload requirements change, teams must iterate and adapt quickly to provision the required infrastructure keeping in mind all the security tenets, performance best practices, and other non-functional requirements.

In this blog post we’ll help you to create your own SAP infrastructure on AWS using Terraform and the building blocks provided in this GitHub repository.

The minimally required resources for creating an architecture as in Figure 1, and hosting a single SAP system would typically include:

Minimal SAP architecture

Figure 1 – Sample SAP S/4HANA architecture on AWS

The industry standard and best practices for deploying resources into the cloud recommend to use Infrastructure as code. Some of the stronger benefits for using Infrastructure as code are a) Improved collaboration and shared configurations, b) easier evolution and versioning of your infrastructure, and c) provisioning automation.

Infrastructure as code

Infrastructure as code (IaC) is a practice in which infrastructure is provisioned and managed using code and software development techniques, such as version control and continuous integration. The AWS cloud offers an API-driven model which enables developers and system administrators to interact with infrastructure programmatically, at scale. Once resources and services are defined as code, infrastructure and servers can quickly be deployed using standardized patterns, updated with the latest patches/versions, and duplicated in repeatable ways.

This enables companies to quickly deploy SAP infrastructure on AWS by utilizing tools like AWS Launch Wizard. With AWS Launch Wizard, customer teams can build SAP systems that align with AWS best practices rapidly from the AWS Console following a guided experience designed for SAP administrators. When using AWS Launch Wizard, other AWS services are used on the back-end, such as AWS CloudFormation and AWS Systems Manager, to do the provisioning and configuration work. While AWS Launch Wizard provides an easy to use and efficient way to provision SAP related infrastructure on AWS, in some cases you may prefer to use a cloud-agnostic IaC tool. In situations like this, Terraform by HashiCorp can be leveraged to automate these SAP deployments on AWS.

DevOps for SAP Infrastructure

Having your infrastructure defined as code opens a new perspective of benefits. It allows you to implement a DevOps model in the SAP Basis world.

High level pipeline

Figure 2 – Overview of a DevOps pipeline

Automating the SAP provisioning in all layers brings the following advantages:

  • Rapid delivery
  • Scale
  • Reliability
  • Improved collaboration
  • Security

You can dive deeper and find additional information on What is DevOps?.

As part of our AWS Professional Services SAP practice, we help customers build their automation factory using a variety of the DevOps tools such as Terraform and CloudFormation, incorporating SAP and AWS Best Practices into this type of automation. In this blog, we provide a sample Terraform solution for deploying the architecture depicted in Figure 1.

Getting started

  1. Fork the GitHub repository aws-sap-terraform into your own account. How to fork?
  2. Navigate through the folders in the specific order: KMS, EFS, Security Groups, IAM, Instances and fill in the files named “dev.tfvars” on each folder according to what your environment requires and the examples below. More information on how to fill in these files below on section Configuring your infrastructure, as well as each README page in the repository.
    1. IMPORTANT: The file as well as the branch names have to match the environment you are deploying to. If you are deploying dev, keep dev.tfvars and use dev branch. If you are deploying qa, create a new file called qa.tfvars and create a qa branch. If you are deploying prod, create the prod.tfvars file and create/use a branch named prod. The recommended branch strategy for SAP infrastructure deployments is the environment branch. Check out What is an Environment Branch strategy if you’re looking for more details, as well as How to work with environment branches.
  3. At each of the folder take a look and update as required at the locals.tf file (example kms/locals.tf). These files contain all the tags to be attached to the resources of that configuration. Update them as required.
  4. Push your updated code to your repository.
  5. Add tag key “sap_relevant” and value “true” to the VPC you’re using for this deployment.
  6. Add tag key “sap_relevant” and value “true” to the Subnets you’re using for this deployment. This will affect where resources will be created. Make sure you apply this tag to all the subnets that will receive an SAP application.
  7. Continue to section below “How to deploy”

Configuring your infrastructure

1. Configuring KMS

Configure the KMS keys you want to create for your environment following the pattern below using file kms/dev.tfvars. More information on configuring this can be found in the README.

environment = "dev"
aws_region = "us-east-1"

keys_to_create = {
  "ebs" = {
    alias_name = "kms-alias-ebs"
  }
  "efs"        = {}
  "cloudwatch" = {}
  "s3"         = {}
}

2. Configuring EFS

Configure the EFS volumes required for your environment following the pattern below using the file efs/dev.tfvars. More information on configuring this can be found in the README.

environment       = "dev"
aws_region        = "us-east-1"
sap_discovery_tag = "sap_relevant"

efs_to_create = {
  "D01-sapmnt" = {
    access_point_info = {
      posix_user = {
        gid = 5001,
        uid = 3001
      },
      root_directory = {
        creation_info = {
          owner_gid   = 5001,
          owner_uid   = 3001,
          permissions = 0775
        },
        path : "/",
      }
    }
  }
}

3. Configuring Security Groups

Configure the Security Groups required for your deployment following the pattern below using the file security_group/dev.tfvars. More information on configuring this can be found in the README.

environment = "dev"
aws_region = "us-east-1"
sap_discovery_tag = "sap_relevant"

app_sg_list = {
  app1 = {
    description  = "App SG"
    efs_to_allow = ["sapmedia", "sapmnt", "saptrans"]
    rules = {
      "app1" = {
        source = "vpc"
        ports  = [4237]
      }
      "app2" = {
        source = "vpc"
        ports  = [8443]
      }
      "app3" = {
        source   = "self"
        protocol = "all"
        ports    = [0, 0]
      }
      "app4" = {
        source = "self"
        ports  = [1, 65535]
      }
    }
  }
}

4. Configuring IAM Policies and Roles

Configure first the policies required for your environment using the pattern below using the file iam/dev.tfvars. More information on configuring this can be found in the README.

iam_policies = {
  ec2_permissions = {
    name = "iam-policy-sap-ec2-others"
    statements = {
      stmt1 = {
        effect = "Allow"
        actions = [
          "s3:GetBucketPolicyStatus",
          "s3:GetBucketLocation",
          "s3:ListBucket",
          "s3:GetBucketAcl",
          "s3:GetBucketPolicy",
          "s3:PutObjectTagging",
          "s3:PutObject",
          "s3:GetObject",
          "s3:HeadObject",
          "s3:DeleteObject",
        ]
        resources = ["arn:aws:s3:::sap-media-bucket"]
      }
    }
  }
}

Configure the roles required for your environment using the pattern below. Notice that the policies listed under “policies” below “name” in the example below have to use the exact same name you gave the policy above. This way the automation will attach the policies you just created to your role.

environment = "dev"
aws_region  = "us-east-1"

iam_roles = {
  role1 = {
    name = "iam-role-sap-ec2"
    policies = [
      "iam-policy-sap-data-provider",
      "iam-policy-sap-efs",
      "iam-policy-sap-ec2-others"
    ]
    managed_policies = [
      "HAQMSSMManagedInstanceCore"
    ]
    permissions_boundary_arn = "arn:aws:iam::<<account nr>>:policy/example-permissions-boundary-rds"
  },
  role2 = {
    name = "iam-role-sap-ec2-ha"
    policies = [
      "iam-policy-sap-data-provider",
      "iam-policy-sap-efs",
      "iam-policy-sap-ec2-others",
      "iam-policy-sap-pacemaker-stonith",
      "iam-policy-sap-pacemaker-overlayip"
    ]
    managed_policies = [
      "HAQMSSMManagedInstanceCore"
    ]
    permissions_boundary_arn = ""
  }
}

5. Configuring the EC2 Instances

At last, configure the EC2 instances required for your environment using the pattern below using the file ec2_instance/dev.tfvars. You have different alternatives to declare your instances, one more dynamic and another more detailed for customized instances. More information on configuring this can be found in the README.

environment = "dev"
aws_region = "us-east-1"

instances_to_create = {
    sapd01db1 = {
        "private_ip"        = "10.237.40.144"
        "domain"            = "mylab.com"        
        "application_code"  = "hana"
        "application_SID"   = "D01"
        "ha"                = false     
        "ami_ID"            = "ami-12345678901234567"
        "subnet_ID"         = "subnet-12345678901234567"
        "key_name"          = "mycmk"
        "monitoring"        = true
        "root_ebs_size"     = 80 
        "ec2_tags"          = { 
            "tag_key_1" = "tag_value_1" 
        }
        "instance_type"     = "x2iedn.xlarge"
        "hana_data_storage_type"   = "gp3" 
        "hana_logs_storage_type"   = "gp3" 
        "hana_backup_storage_type" = "st1" 
        "hana_shared_storage_type" = "gp3"
    }
}

How to deploy

IMPORTANT: The sample code provides an easy route assuming you are using GitLab to deploy your infrastructure and that it is already connected to your AWS account.. If you’re not using that, you will have to rewrite/replace the files “.gitlab-ci.yml”, all of the “<folder>/gitlab/pipeline.yaml” and ensure you have the right configurations under “<folder>/configs.tf” according to what your CI/CD tool requires.

Once you’ve updated all your files from the steps above as well as reworked the CI/CD specifics, push the code to your repository. Follow the order below to deploy your resources on the AWS account. Creation sequence:

Sequence Stage Jobs
1 KMS kms_plan, kms_apply
2 EFS efs_plan, efs_apply
3 Security Groups security_groups_plan, security_groups_apply
4 IAM iam_plan, iam_apply
5 EC2 Instances instances_plan, instances_apply

How to further automate your SAP environment

To maximize efficiency, improve operational excellence, and take advantage of other AWS services for SAP operations take a look at configuring:

Housekeeping

In case you are only exploring the functionality described in this blog to become more familiar with Terraform IaC capabilities, running a brief POC, or running a temporary deployment for any other reason, remember to clean up the deployed resources to prevent unnecessary spending in your AWS account once you no longer need the resources.

You can manually delete resources in the AWS Management Console, or, alternatively, include a step in your pipeline to do so (recommended). In the sample code, as part of the sample GitLab pipeline configuration, we included a Destroy stage. Once executed, it will use Terraform to delete all resources previously created.

Conclusion

As we have demonstrated with our Terraform modules here on GitHub, by defining SAP as code, infrastructure and servers can quickly be deployed using standardized patterns, updated with the latest patches/versions, and duplicated in repeatable ways to overcome some of the initial learning curve hurdles.

Terraform along with the AWS cloud API-driven model enables developers and system administrators to interact with infrastructure programmatically, at scale, instead of manually setting up and configuring resources.

This solution makes it easy to add into your existing terraform configuration or if you are starting your journey with Terraform you can simply clone the repository and get started with a new terraform configuration.

Are you interested in learning more or maybe you would like a better understanding of how you can extend this solution for your project?

For more information, contact us at sap-on-aws@haqm.com.