Great news coming from AWS for SAP customers! As announced on 2018 re: Invent, Amazon Web Services has introduced a new service called “Global Accelerator”. According to the official information "AWS Global Accelerator is a service that improves the availability and performance of applications with users". Basically, provides static IP addresses that act as a fixed entry point to an application endpoint (such as SAP Router or Web Dispatcher*) in an AWS Region.
Let's have a look into their functionalities and how this new service can improve and optimize SAP system applications.
*In AWS world, ALB, NLB or EC2 Instance, all of them entry points for SAP applications running on AWS.
A Quick Review
When traffic passes through the internet from a user’s access on route to a cloud provider, or from your datacenter to a cloud provider, the provider (ISP) has choices as to how to route that traffic in. By default, traffic bound to AWS will ride the public internet until it hits the region at the end. That means that traffic is subject to latency based upon public internet congestion. It's subject to latency and jitter.
Global Accelerator sort of flips the behavior on its head, where instead of traveling across the entire internet until it smacks into a region, traffic now winds up landing into AWS's network far sooner. AWS Global Accelerator uses AWS’s network to optimize the path from users to the applications, improving the performance of the traffic, and this is why it’s great news for SAP customers.
Unlike Amazon CloudFront, that is aimed for HTTP traffic for CDN (web) content, so not much benefit from CloudFront to SAP customers. Direct Connect is a point to point improvement, good from Office to AWS, from Datacenter to AWS, but users are on the move.
All changed this November 2019. Now, applications such SAP running on Amazon EC2 instances can be directly fronted by AWS Global Accelerator. Before, we needed to use an Elastic IP address to front an EC2 instance with Global Accelerator. Now, we can use Global Accelerator directly as the single internet-facing access point for SAP applications.
This means that previously, Global Accelerator was primarily suited to stateless server workloads whereas now it routes directly to EC2 allowing connection to applications such as SAP. Also, by bringing endpoints closer to our users, we see a reduction in latency and jitter over UDP or TCP. Global Accelerator monitors and reacts to changes in network performance, providing the best possible experience for users.
We can also benefit from an easier endpoint management, because AWS Global Accelerator’s static IP addresses make it easy to move endpoints between Availability Zones and AWS Regions without needing to update DNS configuration or change client-facing applications such as SAP Router or Web Dispatcher (just to give a couple of examples).
However, we need to take into consideration that, the Global Accelerator might not be useful if users and AWS aren’t far away or with a decent internet connectivity. In order to prove that, we decided to give it a try. Below you will find more information on how we did it and the outcome. Keep reading!
- SAP instance running on EC2
- SAP Router for SAP GUI connections
- SAP Web Dispatcher for HTTPS connections
- SAP Fiori Launchpad
How We Did It?
We created a Global Accelerator against a SAPRouter, which is a process from SAP, widely used, that acts as a proxy between SAP systems and users. It’s a very interesting enhancement for any customer firewall.
We are calling a SAPRouter exposed as Elastic IP based in EU Ireland, the origin of the call is Barcelona and the ping is between 44ms and 47ms:
Traceroute takes 26 jumps to the destination:
Once created, the access to SAP, is using Global Accelerator as the endpoint. Ping has gone from 44-47 ms to 12-15 ms (+300% improvement).
Traceroute has gone from 26 jumps to 10:
With that said, we recommend to test it, as some network benchmarks such as ThousandEyes have determined that in some areas Internet outperforms Global Accelerators, and we can see from the pricing that the solution requires a good business case for its costs.
If interested, explore more about it on the official documentation and also, we recommend an interesting analysis published by Corey Quinn, cloud economist.