AWS PrivateLink and SAP on AWS Deployments

AWS provides its services to millions of customers and thousands of SAP customers. Today, one of the key challenges that customers face is network security while data is transferred over the internet. Although data is encrypted and various network protocols are developed today to reduce the surface area that can be exploited by attackers, it is still a risk since the tools available to hackers get advanced every single day as well. 

Another mechanism by which this risk is totally eliminated is to avoid exposure to the internet altogether for specific use cases and rely on a trusted AWS backbone network for all data transfers. Traditionally, this is achieved by creating VPCs in AWS and establishing VPC peering, which allows non-overlapping private network ranges to be able to communicate with each other. Another available feature was VPC endpoints. This basically provides a mechanism to connect to AWS services, like S3 object storage, without requiring the customer to communicate over the internet. 

AWS PrivateLink can be visualized as an offering that provides benefits of both of the above services and is available for non-AWS services. For example, SAP runs SAP BTP (Business Technology Platform) in their own VPC within AWS. Now, a VPC peering scenario is not possible since there will be hundreds of customers who will use these BTP services. An endpoint, in this case, is created just like it's available for AWS services; however, instead of traditional AWS service, the VPC owner, in this case SAP, can expose their services. The consumer can easily access the private endpoint available within the AWS network and is never leaving the backbone of AWS as long as their VPC is also set up in AWS.

To technically understand the usage of PrivateLink, there are a few terms that need to be described.

1. Endpoints — In the context of a VPC, an endpoint is a virtual connection point, or in simpler words, a URL that acts as an entry point for any specific AWS service. The most commonly used regional endpoint is the AWS S3 service. For us, there are several types of endpoints in AWS, which are described below.

2. Service Endpoints — The endpoints that usually refer to a specific AWS service, for example, in the above case, it's S3, and hence they are referred to as Service endpoints. They are available for almost every AWS service, and currently, there are 233 such endpoints that can possibly be created. The screenshot below is from AWS Console when a service endpoint creation is performed

2.a. PrivateLink Ready Partner Services — AWS Partners can build online products that can enhance security and ensure data protection by connecting a customer's VPC to other customer/partner-managed services. 

2.b. AWS MarketPlace Services — The AWS Marketplace is available for any registered third-part to sell their offerings. With an endpoint, it is ensured that such services are connected to the customer's VPC without traversing the internet.

2.c. EC2 Instance Connect Endpoint — This allows a private AWS network-based endpoint for any EC2 instance. It basically sets up an elastic network interface that can allow corresponding resources to connect to a private subnet without the need for any additional peering or internet gateways.

2.d. Other Endpoint Services — The service endpoints can be shared across VPCs, and such services will appear here once shared with the referenced account.

2. Gateway Endpoints — The Gateway endpoints are designed specifically for AWS S3 and Dynamo DB services, and it is important to note that they do not use AWS PrivateLink, which in turn provides a benefit that there are no additional endpoint-related costs incurred while using them. They still serve the same functionality of reaching AWS services without traversing the internet and without using an internet gateway. The functionality is achieved by updating the VPC route table where a destination, which is the prefix list of service (S3 or DynamoDB), and the target is the gateway endpoint itself. 

3. Gateway Load Balancer Endpoints — These are designed to provide private connectivity using third-party virtual appliances. These endpoints provide private (within the AWS network) connectivity between virtual appliances in service provider VPC and the application servers (running the consumer applications) in consumer VPC.

4. Endpoint Services — Any AWS consumer, in this context referred to by AWS as a provider, can create this for any application that the provider has developed and is hosting in their own VPC. This is powered by PrivateLink. Any other consumer, referred to in this context by AWS as a service consumer, that, in this case, will act as an end-user for this service, can then connect to this endpoint. The connection by service consumers is created using an interface VPC endpoint or a Gateway Load Balancer endpoint, depending on the type of service. This is useful to extend a S/4HANA system running on an EC2 instance, which can expose its services using the endpoint services feature and can have native AWS integrations in a secure manner.

SAP PrivateLink Service establishes a private connection by re-using several of the above-described services and provides a mechanism to let SAP BTP services that are running in AWS under a customer-owned BTP account get connected to other customer or AWS services that are running in a customer-owned AWS account. The basic architecture for this is depicted below.

The interface endpoint described above is created in a customer-owned SAP BTP account that is running services in AWS, and this can now consume any AWS Endpoint service that is created in the customer's AWS account. The traffic will flow across VPCs using AWS PrivateLink (also referred to as SAP Private Link), which will ensure traffic is not going via the internet. The architecture also supports consuming S3, SQS, SNS, SES, RDS Aurora Data API, Lambda, IOT Core, and KMS services that are available as native AWS services.

PrivateLink-Based BTP to AWS Connectivity

The customer runs a custom application in a BTP account that is deployed in AWS and owned by them. Technically, this is in a VPC that is owned by SAP themselves; however, the SAP BTP is delivered as a SaaS product, and the customer doesn't have visibility of this VPC layer. The AWS PrivateLink service is visible under the Entitlements section in the Account Explorer of BTP cockpit and is named SAP PrivateLink Service. Once enabled, the service can be consumed.

1. The customer has deployed an application to generate PDF documents using the SAP Forms Service by Adobe. This is based on ADS that traditionally was deployed on a dedicated Java stack. Now, this setup no longer requires an additional Java instance in the landscape.
2. The customer's SAP system is running under a customer-owned AWS account and is a highly secure environment that cannot be exposed to the internet for legal and security reasons.
3. To utilize the SAP Forms Service and securely transfer data within the AWS network, the customer uses SAP PrivateLink and establishes secure connectivity using the above reference architecture.
4. The communication remains within the owned network.

There are several use cases and reference architectures that can be built using PrivateLink.

1. SAP systems running on AWS under SAP RISE and SAP BTP on AWS (credits available as part of RISE) connectivity.
2. SAP systems running on-premise for a customer that has connectivity ( Direct Connect / VPN) to AWS and SAP BTP on AWS.
3. SAP systems running on AWS under the customer's own account and SAP BTP on AWS connectivity.

There are various possibilities that can be further explored with the PrivateLink connectivity based on enterprise-specific use cases.