SAP on AWS: AWS Landing Zone

For any application to run on AWS, including SAP, the initial requirements have to be fulfilled. All the enterprise customer scenarios today need a Landing Zone to be set up first before SAP deployments can be performed. A "Landing Zone" is an AWS environment set up for a specific customer that can be used as a starting point to deploy workloads. In this blog, we will take a deep dive into the Landing Zone from an SAP deployment perspective. 

SAP uses AWS IaaS services for the SAP NetWeaver and SAP S/4HANA deployments, while the PaaS and SaaS products are used for many integration scenarios and several non-NetWeaver and non-ABAP-based products. To run these services, the basic requirements can be summarized below:

1. An active AWS account with IAM permissions to create and destroy resources as part of a multi-account AWS setup
2. A network (AWS VPC) with subnets that can be used to provide the network to corresponding deployments
3. A billing account
4. A potential connectivity setup to existing customer network in case of on-premise integrations and/or on-premise to AWS migration scenarios
5. Audit and logging setup

It is important to use AWS best practices while creating the above entities, given the fact that they serve as a core and cannot usually be modified at a later stage unless additional efforts are spent, including re-creating servers and other infrastructure in some cases. The setup of the AWS Landing Zone can be performed either automatically using AWS Control Tower. Alternatively, it can be performed manually by a team of AWS experts. In the case of large enterprises, as the setups are customized, this usually would mean a combination of automated and manual steps. The difficult part in setting this up is decisions on several aspects of how various aspects, like accounts, networking, policies, and so on, are structured. 

Let's start deep-diving them one by one in SAP's context.

AWS Accounts

The accounts provide access for any user who wishes to perform an operation task on AWS Console. While a single account can be used to technically run an SAP workload, the reality is that every enterprise needs to keep a robust security check in place along with clear segregation of duties which in turn results in the need for multiple accounts. In the context of SAP deployments, the recommended approach is to segregate non-production and production workloads into separate accounts. In addition, the accounts are required for various tasks, including monitoring, backup, and auditing, among others. 

In many cases, the account structure is not specifically decided for SAP applications as it is a broader decision applicable to all applications running in AWS for the particular customer. For such cases, it should still be ensured that separate accounts for SAP workloads are in place. A segregation is further possible between production and non-production workloads on the account level itself. This provides the additional benefit of being able to segregate the billing and ensure costs can be aligned to more granular levels.

AWS Networking

With multiple accounts, multiple VPCs are required, unless the design of VPC sharing is chosen. While VPC sharing avoids setting up VPC peering and transit gateway, most of the enterprise SAP customers prefer setting up a transit gateway that serves the wider purpose of being able to connect multiple networks running SAP and non-SAP workloads. 

SAP landscapes in most cases include sandbox, dev, QA, pre-production, and production workloads. The preferred strategy for these workloads segregation from a networking standpoint is to set up a non-production and a production VPC. The sandbox, dev, and QA are then segregated using subnets in the non-production VPC, while pre-production and production workloads are set up using their own subnets within the production VPC. 

This strategy can be adapted as per organization standards. However, the recommendation above provides a baseline that can be used for ensuring security from a networking perspective.

Billing Account

It is recommended that enterprise customers use an organization unit (OU) set up to manage multiple accounts and include a management account that manages bill payments centrally. In the case of SAP workloads on AWS, there can be 2 possible scenarios. 

1. In most cases, customers have more resources and services in non-SAP space that leverage AWS, and a management account already exists. This can be re-used for additional SAP-related AWS billing management as well. 
2. In several cases, it is possible that SAP is the first workload to be deployed on AWS, and hence, an OU and a billing account has to be set up before any other actions are performed. 

While a single billing account and non-OU setup will allow SAP workloads to run, it will create a problem in the future when more non-SAP workloads are added. The step for setting up a management account for billing purposes hence becomes necessary as part of the AWS Landing Zone setup.

On-Premise/Other Cloud Connectivity 

The SAP landscapes have inter-dependencies with plenty of non-SAP systems: it is typically SAP that acts as the finance or retail backend system and data flows in and out of it every single second when the system is functional. The other systems can be on another private or public cloud, on-premise, or in the AWS itself in the same or another VPC. Regardless of the location, the data transfer shall remain seamless and the business expects that AWS should not appear as a different setup from on-premise ones. 

To connect the AWS VPC with the existing network, AWS offers several mechanisms. AWS Direct Connect provides a high-speed, private network-based reliable connectivity, while AWS VPN provides comparatively lesser speed, encrypted traffic via a public network and can be set up quickly without dependencies with network providers. Typically, customers use AWS Direct Connect during migrations and once most of the workloads that are data intensive in nature are in AWS, they leverage AWS VPN for day-to-day tasks. 

Connectivity to other cloud providers is set up in a similar manner and can be set up using VPN connectivity as well as Direct Connect. Closely coupled SAP systems are recommended to be in one of the cloud setups itself as the minimal latency requirements could not be met in hybrid scenarios. Also, keep in mind that any data sent outside of the AWS network incurs an egress cost, although it is not significant (~ 0.09 per GB). Hence, it is recommended to keep the closely coupled systems in the same zone of the AWS region. 

While a single Direct Connect or AWS VPN connection suffices for SAP data transfer requirements, from a redundancy and availability point of view, at least 2 active-active or active-passive connectivity setups are recommended. It is also possible to use the VPN as a fallback option for Direct Connect.

Audit and Logging 

It is important, although not mandatory, that a Landing Zone consists of mechanisms to define how AWS Auditing and AWS Logging will be performed. These are natively available with AWS Tools, namely, AWS CloudTrail and AWS CloudWatch. Additionally, AWS Config is used to provide tracking of resource changes against a baseline configuration; for example, using only specific types of instances and disks. The events can vie sent via a notification to administrators and other key stakeholders. 

In the context of SAP, auditing and logging are of paramount importance given the fact that SAP systems act as a core to the business and any changes or unnoticed events can directly hamper the business to perform their regular tasks. The usage of native services is preferred and recommended; however, customers prefer using third-party tools in scenarios where they are already familiar with these tools and have the skill set available to manage them.

Conclusion

Addressing the above aspects provides an initial setup that can then be used to deploy SAP systems in a stable and secure manner with minimal disruptions for changes at a later stage. Some of the aspects - specifically, auditing and logging - are adjustable at a later stage. However, the network design and account structure changes require much more effort in case they need to undergo a change. It is hence recommended to spend some time and finalize these design aspects with key stakeholders and then implement them, either using AWS Control Tower or configuring them manually wherever the Control Tower does not support the customizations required.