AWS for SAP

Achieving Robust SAP Landscape Segregation with Amazon VPC Lattice

Introduction

Organizations running SAP workloads in regulated industries must comply with strict governance requirements that mandate environment segregation. Financial institutions, healthcare organizations, and other regulated entities are required to maintain separate environments for development, testing, and production systems. The ISO 27001, ISO 27002, and  Technology Risk Management Guidelines by Monetary Authority of Singapore, require separation and segregation-of-duties between development, QA, and production environments to protect data integrity and restrict unauthorized access.

In many instances, these requirements are not just strong recommendations, but mandated compliance that organizations must meet to maintain their operating licenses and avoid significant penalties. Since SAP systems deal with sensitive data, it’s crucial to properly separate different environments to avoid serious risks like data breaches, fines, lawsuits, and business problems.
This blog explores how AWS Private Link and Amazon VPC Lattice can help organizations achieve robust SAP landscape segregation while simplifying network management and reducing operational complexity.

The challenges in traditional SAP landscape segregation

Organizations deploying SAP workloads across development, quality assurance, and production environments face numerous complex challenges in maintaining required isolation between environments and providing access based on principle of least privilege. One of the primary hurdles is establishing and maintaining meaningful isolation between these different landscapes, which is crucial for preventing development changes from affecting production systems without proper testing, thus satisfying regulatory compliance requirements.

Traditionally, achieving isolation between different SAP environments required complex networking setups with VPC peering, Transit Gateway routing rules, firewalls and security groups across multiple VPCs and accounts, while maintaining seamless communication between essential SAP services. This presents another significant challenge, as teams must operate and maintain this complex setup which is often prone to misconfiguration errors. These complex traditional networking configurations create substantial operational overhead, requiring dedicated resources for maintenance, troubleshooting, and ongoing management of underlying networking and security layers.

That’s where AWS Private Link support for VPC resources and Amazon VPC Lattice comes in. In next section we explain how AWS Private Link support for VPC resources and VPC Lattice can be used to achieve the required segregation between SAP environments using principle of least privilege at the same time providing seamless access between these environment. We will also cover the scenarios which will benefit from AWS Private Link support for VPC resources or VPC Lattice.

SAP environment segregation using AWS PrivateLink support for VPC resources:

AWS PrivateLink support for VPC resources is designed to provide secure and unidirectional connectivity to individual resources across VPC and account boundaries. AWS PrivateLink support for VPC resources leverages private IPs to communicate between the client and resource, and allows granular control which resources in your VPC are exposed to the resource consumer.

Using AWS PrivateLink support for VPC resources, SAP workloads across development, quality assurance, and production environments can be isolated, adhering to the principle of least privilege. Resource Links allow you to share specific VPC resources across different VPCs without exposing the entire network, which is crucial for SAP landscapes where separation between environments is essential for regulatory compliance and operational stability. Please refer to figure 1 and high level steps below.

Figure 1 – Segregation using Resource endpoints

Figure 1 – Segregation using Resource endpoints

High level steps

Assumptions: Each SAP environment (QA, Dev and Prod) are running in their own VPCs in different accounts and there is no network connectivity between them.

  1. Starting with one environment, for example dev, create a Resource Gateway in the VPC where the dev SAP instance is located. While creating the Resource Gateway, choose at-least two subnets across two AZs and the Security Group with required rules in it to allow SAP traffic.
  2. Create a Resource Configuration using the Resource Gateway created in previous step. The Resource Configuration should be created using the TCP port/s the SAP dev instance is listening on and in resource-configuration-definition, ipResource should be chosen as the type and should point to the IP address of the SAP dev instance.
  3. Create a Resource Share for this Resource Configuration using AWS Resource Access Manager and share it with the other AWS Accounts where SAP prod and QA systems are running (this is required if these systems are running in different AWS accounts).
  4. Create an endpoint in the required VPC, for example in Prod and QA VPCs, using the Resource Configuration shared by dev account and associate the Security Group with required rules in it to allow the SAP traffic.
  5. Create an Amazon Route 53 Private Hosted Zone for QA and Prod VPCs and associate it with respective VPCs. Then add CNAME record/s in these Private Hosted Zones with the domain name you want to use to access SAP dev instance, pointing to the system generate domain name of endpoint created in each VPC.
  6. Repeat these steps for other SAP environments as required.

The above method works well if the access requirement is between the VPCs only and not from outside the VPC e.g. from on-premise networks and the number of resources needing access few in number (e.g. 1 or 2). The reason is that, each resource will need individual Resource endpoint in the VPCs from where the access is required and with more number of resources, creation and management of these endpoint will increase the operational workload.

That’s where Amazon VPC Lattice based solution comes in which is described in the next section.

SAP environment segregation using Amazon VPC Lattice:

Amazon VPC Lattice allows secure service-to-service communication for modern distributed applications. This enables organizations to connect and manage services across multiple accounts and VPCs without complex networking configurations. Resource Gateways extend the VPC Lattice capabilities by enabling direct connectivity to resources that traditionally needed complex networking setups. This feature allows service providers to provide secure connectivity to their resources to consumers spread across different VPCs across different accounts as well as to networks/consumers situated on-premises.

The solution will have a Service network with each SAP instance (prod, dev, qa) associated as a service of its own. These services will be made available to each other via Service Network Endpoints. For access from on-prem, the on-prem network will be connected to an Ingress VPC via AWS Direct Connect or AWS Site to Site VPN. This Ingress VPC will have Service Network Endpoints which can be access from on-prem.

This approach will work well for multiple resources per VPC required access to form other endpoints/resources in other VPCs as well as for providing access to these systems from on-prem by abstracting IP address dependencies and allowing endpoints to communicate securely without needing direct network routing. Please refer to figure 2 and high level steps below.

Figure 2 – Segregation using VPC Lattice

Figure 2 – Segregation using VPC Lattice

High level steps

Assumptions: Each SAP environment (QA, Dev and Prod) are running in their own VPC in different accounts and there is no network connectivity between them. Connectivity from On-Prem is already provisioned to an VPC (Ingress VPC) in a different account via Aws Direct Connect or AWS Site to Site VPN. There is a central Account in which the Service Network will be created.

We will start with SAP instances in dev environment being exposed to SAP instances in other environment like prod and QA.

  1. In the SAP dev instance account, create a Resource Gateway in the VPC where the SAP dev instance is located. While creating the Resource Gateway, choose at-least two subnets across two AZs and the Security Group with the required rules in it.
  2. Create a Resource Configuration using the Resource Gateway created in previous step. The Resource Configuration should be created using the TCP port/s the SAP dev instance is listening on and in resource-configuration-definition, ipResource should be chosen as the type and should point to the IP address of the SAP dev instance.
  3. Create a Resource Share for this Resource Configuration using AWS Resource Access Manager and share it with the central account mentioned in the assumptions section. This step is not required if the entire setup is being provisioned in the same account.
  4. Create a Service Network in the central account.
  5. Share this Service Network with all other accounts mentioned in the assumptions section above using AWS Resource Access Manager. This step is not required if the entire setup is being provisioned in the same account.
  6. Accept the Resource Shares for each shared resource in all the accounts mentioned in the assumptions section.
  7. Associate the Resource Configuration created in previous step to this Service Network.
  8. Create a service network endpoint for the Service Network created in step 4 in SAP prod, QA environment VPC and the Ingress VPC. Make sure to choose all the AZs so that AZ mismatch between customer and SaaS provider can be avoided. Alternatively you can align AZs between Resource Gateways in customer VPCs and service network endpoint in the SaaS provider VPC. Obtain the DNS Names assigned by the system for each SAP dev instance.
  9. Create and associate separate Private Hosted Zones with SAP dev, prod, QA environment VPC and Ingress VPC. Create CNAME records to point the system-generated DNS names of the Service Network Endpoints in each VPC to a more user friendly domain names.
  10. Repeat these steps for SAP prod and QA environments.

SAP Transport Management System (STMS) Configuration

With VPC Lattice providing seamless connectivity between SAP environments, configuring the Transport Management System becomes straightforward. Kindly refer to SAP documentation for configuring TMS.

Please refer to pricing page for Amazon VPC Lattice and Resource Endpoint

Conclusion

Amazon VPC Lattice transforms SAP landscape segregation from a complex networking challenge into a manageable, policy-driven approach. By providing strict isolation, simplified service discovery, built-in load balancing, and granular access controls, VPC Lattice enables SAP on AWS customers to meet regulatory requirements while reducing operational overhead.

The centralized management console and native AWS integration make VPC Lattice an ideal solution for regulated industries that require robust environment segregation without the complexity of traditional networking approaches. Organizations can achieve compliance with regulations like MAS Technology Risk Management Guidelines while maintaining operational efficiency and security best practices.

For SAP customers looking to modernize their networking architecture while meeting stringent regulatory requirements, Amazon VPC Lattice offers a path forward that simplifies operations without compromising on security or compliance.
Reference: MAS Technology Risk Management Guidelines

Credits

We would like to thank Genny Iustiadi for his contributions to this blog.