VPC Subnet Zoning Patterns for SAP on AWS, Part 3: Internal and External Access

Harpreet Singh and Derek Ewell are Solution Architects at Amazon Web Services (AWS).

In part one of this article series on virtual private cloud (VPC) subnet zoning patterns, we described possible ways in which SAP applications may be accessed, and then discussed Amazon Virtual Private Cloud (Amazon VPC) subnet zoning patterns for internal-only access in detail. In the second article in the series, we discussed how traditional application network zoning can be mapped to AWS. In this concluding article of this series, we’ll discuss access patterns for SAP applications that require access to and from both internal and external sources. Access from external sources may be controlled (that is, they may involve known external parties) or uncontrolled (that is, they may be publicly accessible)—we’ll cover both scenarios.

Internal and controlled external access

SAP Process Orchestration (PO)/Process Integration (PI) is the perfect example of this scenario, because in most cases it requires access from trusted external parties for external interfaces, and internal access for internal interfaces between SAP and/or non-SAP systems. Internal interfaces are easy to manage—essentially, you define the appropriate traffic in route tables, network access control lists (ACLs), and security groups. However, the challenge lies in providing external access securely, so let’s focus on egress and ingress traffic from trusted external parties. There are four typical options:

• Virtual private network (VPN) connections for both ingress and egress
• Elastic Load Balancing for ingress, and network address translation (NAT) gateways for egress
• NAT devices (NAT instances or NAT gateways)
• Reverse proxies

VPN connections (ingress and egress)

If you want to have a dedicated virtual connection with your trusted external parties, you can establish a site-to-site IPsec VPN connection either by using a virtual private gateway (VGW) in your VPC, or by having your own software VPN server, such as those available in the AWS Marketplace, in a public subnet.

Note   The architecture diagrams in this blog post show a single Availability Zone for simplicity. However, for high availability, we recommend configuring the solution across at least two Availability Zones.

Figure 1: VPN connection for controlled external access

Elastic Load Balancing (ingress) / NAT gateway (egress)

Elastic Load Balancing offers three types of load balancers:

• Classic Load Balancer
• Network Load Balancer
• Application Load Balancer

Classic Load Balancers are intended for applications that were built for the EC2-Classic platform. If you’re using a VPC, we recommend using a Network Load Balancer or an Application Load Balancer. A Network Load Balancer operates at the connection level (layer 4) of the Open Systems Interconnection (OSI) model and is ideal for TCP traffic load balancing, while an Application Load Balancer operates at the request level (layer 7) and is the ideal choice for HTTP or HTTPS traffic load balancing.

Let’s consider two examples here, one for Secure File Transfer Protocol (SFTP) and the other for HTTPS.

• SFTP. Let’s say you have an SFTP server in a private subnet that needs to be externally accessible from trusted external parties. In this scenario, you can use an internet-facing Network Load Balancer in a public subnet, and control access to trusted external parties through the security group associated with the SFTP server in a private subnet. (There is no security group associated with a Network Load Balancer). For outbound (egress) traffic, say, from SAP PI/PO to SFTP servers of trusted external parties, a NAT gateway is required. You can use Amazon Route 53 to register your organization’s external domain name and resolve fully qualified domain names (FQDNs) to the load balancer.
  

  Figure 2: Network Load Balancer for external access

• HTTPS. For this second example, let’s say you have web service based interfaces to SAP PI/PO that need to be externally available. In this scenario, access will be based on SSL (HTTPS), so an Application Load Balancer is the perfect fit for ingress traffic. Access from known IPs will be controlled through the security group attached to the load balancer. On the other hand, if SAP PI/PO needs to consume web services exposed by your trusted external parties, you’ll need a NAT gateway. You can use Amazon Route 53 here as well for domain name registration and FQDN resolution.
  

  Figure 3: Application Load Balancer for external access

Other alternatives

NAT instances and reverse proxies are possible alternatives to using Elastic Load Balancing. However, we recommend that you use Application or Network Load Balancers in internet-facing configurations, because these managed offerings take away the overhead of managing NAT instances and reverse proxies.

• NAT devices. AWS offers two kinds of NAT devices—NAT gateways and NAT instances. NAT instances are based on an Amazon Machine Image (AMI), whereas NAT gateways are managed by an AWS service. Both of these devices provide internet access for your EC2 instances in private subnets. You can enable NAT instances for port forwarding as well, to allow external parties to access your applications running on EC2 instances in private subnets. Let’s look at the previous SFTP example again, where a SFTP server in a private subnet needs to be accessed by known external parties for file-based interfaces with SAP PI/PO. A NAT instance (after enabling port forwarding) will protect your SFTP server (which is in a private subnet) from direct external access while enabling external parties to access it. You can configure the security group attached to the NAT instance to allow traffic only from known external IPs for controlled access. If all your interfaces are based on outbound connections from SAP PI/PO, NAT gateways provide a perfect fit.
  

  Figure 4: NAT instance for port forwarding

• Reverse proxy (ingress) / NAT gateway (egress). A reverse proxy is used for ingress HTTP/HTTPS traffic. A reverse proxy in a public subnet allows external parties to establish HTTP/HTTPS connections to SAP PO/PI servers in private subnets. You can use SAP Web Dispatcher as a reverse proxy for ingress traffic, or you can use third-party products like F5 BIG-IP. If you’re using SAP Web Dispatcher, we recommend that you configure it for reverse invoke connection. You can use a NAT gateway, as in the previous scenario, for egress traffic.
  

  Figure 5: Reverse proxy for external access

In both of these (NAT and reverse proxy) scenarios, to retain a static public IP address, you will need to use Elastic IP addresses. In addition, you can use Amazon Route 53 for domain name registration and FQDN resolution.

Other application-specific options, such as SAP Cloud Connector, are also available. Cloud Connector establishes connections with the SAP Cloud Platform over HTTPS. The connection is always invoked by Cloud Connector, but after the connection is established, data can be sent both ways (through a reverse invoke connection). We recommend that you place Cloud Connector in the extranet zone, with internet access via a NAT gateway.

Figure 6: Integration with SAP Cloud Platform

Internal and uncontrolled external access

Internal access to applications in this category needs to be managed in a similar way as in the previous scenario (internal and controlled external access), that is, by defining appropriate route tables, network ACLs, and security groups. So, we will focus on uncontrolled external access in this section.

SAP Fiori is a common example of a SAP application where you may need external access without a VPN connection as well as internal access. Other examples include the SAP hybris platform, an externally accessible SAP Enterprise Portal (EP), or SAP Supplier Relationship Management (SRM) system. However, in most cases, uncontrolled external access for SAP systems is limited to HTTP/HTTPS. Let’s consider the example of an SAP Fiori front-end server in a central hub deployment, running on SAP NetWeaver Gateway.

Figure 7: Application Load Balancer for external access

An Application Load Balancer in an external zone acts as the entry point for HTTP/HTTPS requests. The load balancer sends requests to SAP Web Dispatcher. AWS Shield protects the SAP NetWeaver Gateway from common web exploits, especially if it’s used in conjunction with AWS WAF in the load balancer. AWS Shield is a managed distributed denial of service (DDoS) protection service that safeguards web applications running on AWS. There are two tiers of AWS Shield: Standard and Advanced. There is no additional charge for AWS Shield Standard.

What’s next?
In this post, we discussed scenarios for accessing SAP applications both internally and externally. If you’d like to discuss your specific scenarios, or if you have any questions or suggestions about this blog post, please contact us.