Share SAP OData Services securely through AWS PrivateLink and the Amazon AppFlow SAP Connector

Introduction

Amazon AppFlow is a fully managed service that enables customers to securely transfer data between Software-as-a-Service (SaaS) and enterprise applications, including SAP, Salesforce, Zendesk, Slack, and ServiceNow, and AWS services, including Amazon S3 and Amazon Redshift, in just a few clicks.

Often, customers first move their SAP workloads onto AWS to reduce costs, improve agility, and strengthen security. However, that is just the first step to fully harnessing the power of SAP on AWS. Customers can then begin to build capabilities to extract value from their SAP data by combining it with non-SAP data in AWS data lakes. This allows you to enrich and augment SAP systems by leveraging native AWS services to optimize manufacturing outcomes, track business performance, accelerate product lifecycle management, and so on.

Based on the feedback we received from our customers, last year we announced a new Amazon AppFlow connector for SAP OData. This helps AWS customers to securely transfer their SAP contextual data to AWS and vice-versa by connecting to the OData APIs that are exposed through their SAP Gateway. With this enhancement, customers can create secure bi-directional data integration flows between SAP enterprise applications (SAP ECC, S/4HANA, SAP BW,BW/4HANA) and Amazon S3 object storage with just a few clicks.

Amazon AppFlow SAP OData Connector supports AWS PrivateLink, which adds an extra layer of security and privacy. Customers can use AppFlow’s private data transfer option to ensure that data is transferred securely between Amazon AppFlow and SAP. As part of private flows, Amazon AppFlow automatically creates AWS PrivateLink endpoints. The lifecycle of interface endpoints is completely managed by Amazon AppFlow under the hood.

In this blog, we will show how to expose SAP resources in a private and secure manner over AWS PrivateLink for setting up private data flows in Amazon AppFlow using the SAP OData connector. The blog will provide architectural and instructions on how to setup AWS PrivateLink for AppFlow SAP OData Connector.

Architecture

AWS PrivateLink uses Network Load Balancers (NLB) to connect interface endpoints to the VPC endpoint service. NLB functions in the network transport layer (layer 4 of the OSI model) and can handle millions of requests per second. In the case of AWS PrivateLink, the NLB is represented inside the consumer VPC, in this case, Amazon AppFlow as an Endpoint Network Interface.

With AWS PrivateLink,customers can create an endpoint service by placing their SAP instances behind a NLB and enabling consumers like Amazon AppFlow to create an interface VPC endpoint in an Amazon AppFlow managed VPC that is associated with the endpoint service. As a result, customers can use Amazon AppFlow private flows to securely transfer data.

The following steps explain how to create a private flow in the customer’s AWS account for establishing the SAP OData service for consumption in Amazon AppFlow private data flows.

• The SAP Gateway is a component of NetWeaver Application Server ABAP 7.40 running on an Amazon Elastic Compute Cloud (EC2) instance optimized for SAP workloads.
• The instance is placed within a virtual private network (VPC) consisting of a private subnet per Availability Zone (AZ).
• An internal Network Load Balancer (NLB) is provisioned in front of the SAP application instance, and an endpoint service is connected to the NLB.
• For establishing a TLS connection, a TLS listener is created in the Network Load balancer, and an SSL certificate is obtained from the AWS Certificate Manager for the registered domain.
• A private DNS name is enabled for the endpoint service by verifying the domain using a public DNS provider, in this case, Amazon Route 53.
• Create an Amazon AppFlow data flow using the SAP OData connector to extract data from SAP by creating a private connection profile with endpoint service details.
• When a private connection profile is created, Amazon AppFlow creates VPC Interface endpoints with Amazon AppFlow managed VPC in the background for establishing connectivity to SAP OData services over a private link for secure data transfer during flow execution.

Configurations that are required for setting up private data flows using the SAP OData connector:

Prerequisites:

• As part of the prerequisites, you need to have the internal-facing NLB configured with your SAP system as backend target groups, with a mapping to more than 50% of the subnets (in separate AZs) in a given region. This will have lower latency and better fault tolerance.
• VPC Endpoint services are available in the AWS region in which they are created and can be accessed from the same region. Amazon AppFlow flows need to be created in the same region where endpoint services are made available.
• A private DNS name must be enabled for the endpoint service. For the endpoint service to verify the domain ownership, you must own the domain using a public DNS provider like Amazon Route 53.
• The SAP instance must have a certificate installed for end-to-end TLS communication. You can use Amazon private CA for obtaining server certificates and installing them on the SAP system via transaction code STRUST. If you want to terminate the SSL at the load balancer, then you can skip this step and just forward the traffic to the target group on a port where SAP does not require a certificate for SSL communication.

Building a VPC endpoint service for exposing SAP Gateway over PrivateLink involves the following steps:

Step 1:  Create VPC and Private Subnets

Start by determining the network you will need to serve the SAP Gateway resources. Keep in mind that you will need to service the application out of more than 50% of AZ within any region you choose. Amazon AppFlow will expect to consume your service in multiple AZs because, as per AWS recommendations, you should architect your applications to span across multiple AZs for fault-tolerance purposes.

In this example, the SAP Gateway instance is placed in a private subnet in one of the AZs in the US-East-1 region. To serve the SAP Gateway resources in that region over a private link, you would need to create subnets in more than 50% of the AZs in that region to provision network load balancers in those subnets, which would cover more than 50% of the AZs in that region for low latency and fault tolerance.

These subnets are private, and the route tables are configured to allow only the VPC traffic.

Step 2:Request a certificate for your domain using ACM

Request a certificate for your domain name using the AWS Certificate Manager (ACM). In this example, we have extended an existing domain by creating a subdomain in the Amazon Route 53 private hosted zone and obtaining a certificate from ACM as shown below. ACM’s domain verification process necessitates the presence of a domain ownership record in a public DNS provider.

Note: To prevent certificate mismatch issues, it’s best practice to provision a wildcard certificate for your domain. See Wildcard Names under ACM Certificate Characteristics for more information.

For verifying the domain ownership, add the CNAME records to the domain you own that are provided by a public DNS provider like Amazon Route 53.

• Create a target group with the protocol TLS and port 443, register the SAP Gateway instance on the private subnet as the target, and forward traffic to the instance on TLS port 44300. In this example, we have configured the SAP instance to listen to secure HTTPS traffic on port 44300.

• Create an internal facing Network Load Balancer, and make it highly available in more than 50% of the AZs in the region where SAP resources will be served for low latency and fault tolerance. Enable cross-zone load balancing on the NLB as well.

• Create a TLS listener for your network load balancer and forward the traffic to the target group that was created earlier.

• During configuration, choose the certificate from ACM as the default SSL certificate. Then, select the SSL certificate that you created in step 2.

After the NLB is provisioned and active, you will create a CNAME record in DNS (Route 53 in our case) for a friendly URL (used in Amazon AppFlow as an application host URL, e.g. privatelink.beyond.sap.aws.dev ) pointing to the NLB internal DNS name (<name>.elb.<region>.amazonaws.com).

Step 4: Create a VPC endpoint service and connect with NLB

Create a VPC endpoint service by selecting the Network Load Balancer that was created in the earlier step, and also in the additional settings, associate the private DNS name hosted in the private hosted zone.

Uncheck the check box “Acceptance required”. This would allow Amazon AppFlow to connect to your service without requiring acceptance from your side.

You must perform a domain ownership verification check for each VPC endpoint service with a private DNS name. You must have the domain on a public DNS provider. For performing domain verification, maintain a DNS record of type TXT with the verification name and values through your DNS provider. You can verify the domain of a subdomain. For example, you can verify beyond.aws.dev in this example, instead of privatelink.beyond.sap.aws.dev.

Once the domain is verified, you will notice the domain verification status changes from “pending verification” to “verified.”

Step 5: Allow principals to access VPC Endpoint Services.

To restrict the VPC endpoint services to being consumed by a specific consumer, you must maintain the allowed list of principals in the endpoint service. In this case, we have allowed Amazon AppFlow connection requests by adding the principal appflow.amazonaws.com to connect to this endpoint service.

This concludes the setup of the endpoint service. Now let’s go and create a private connection in Amazon AppFlow using the endpoint service name.

To create a secure,private connection in Amazon AppFlow

The required inputs to create a new Amazon AppFlow SAP OData private connection are as shown below.

Enable the PrivateLink connectivity and specify the AWS PrivateLink endpoint service name that was created in the earlier step.

Note: When using oAuth 2.0 in a private connection, the authorization URL must be reachable from the network where the connection is being setup. This is because the OAuth connection involves browser interaction with the SAP Login Page, which cannot happen over AWS PrivateLink.

Create a private flow in Amazon Appflow.

The configuration steps to create a new Amazon AppFlow SAP OData flow are as follows.

• Configure Flow and connect to the source by picking the SAP private connection.
• Discover SAP OData Services
• Choose an SAP Service Entity
• Define the flow trigger (whether it is on-demand or scheduled )
• Map Fields, Define Validations, and Set Filters
• Run Flow

You can find further details on how to create a flow in the Amazon AppFlow SAP OData Connector documentation.

Conclusion

In this post, we showed you how to use AWS Private Link to expose SAP NetWeaver Gateway in your AWS account and establish private connectivity between Amazon AppFlow and SAP System OData resources in your AWS account for a secure data transfer. Customers running SAP Systems on-premises can also use the Amazon AppFlow SAP OData Connector by using AWS Virtual Private Network or AWS Direct Connect connections to configure AWS PrivateLink, as an alternative to using the public IP address of the SAP System OData endpoint.

To get started, visit the Amazon AppFlow page. To learn why AWS is the platform of choice and innovation for more than 5000 active SAP customers, visit the SAP on AWS page.