Global Load Balancing with VMware Cloud on AWS and the AWS Global Accelerator

One of the public cloud’s defining advantages is its ability to provide global reach instantly. In a matter of minutes, a start-up in France can enter a new market in the US with minimum effort and commitment.

Many of our VMware Cloud on AWS customers leverage the global reach of AWS to expand into new regions but as their business goes global, our customers face challenges around delivering applications to these global users over the public Internet.

Our customers have been asking for a way to provide a global Internet-facing applications (sometimes providing via GSLB devices such as Citrix Netscaler or F5) running on VMware Cloud on AWS. When AWS introduced the AWS Global Accelerator at re:invent a couple of months ago, I thought I’d experiment with it and see how it integrates with VMware Cloud on AWS.

The idea around the AWS Global Accelerator is to get traffic from the user to the web server within the AWS network as early as possible (to avoid traversing multiple public networks to reach the application, as these public networks can be congested and each hop can introduce availability and performance risk).

The AWS Global Accelerator would advertise the same public IP out from multiple Edge Locations and a user in the US would enter its local AWS Edge Location and travel across the AWS private network all the way to the server and a user in Europe would do the same via its local AWS Edge Location.

The AWS Global Accelerator improves application availability by continuously monitoring the health of your application endpoints and routing traffic to the closest healthy endpoints.

It can take many networks to reach the application and paths to and from the application may differ. Each hop impacts performance and can introduce risk.

Adding AWS Global Accelerator removes these inefficiencies. It leverages the Global AWS Network, resulting in improved performance.

Before we used Anycast IP for global load-Balancing, we tended to use DNS where a user would make a DNS request and DNS servers would return multiple IPs so that users would reach different IPs for the same server – but DNS is dumb and does not check the health ands reachability of the servers.

Now let’s go deeper into how we can leverage this with VMware Cloud on AWS.

The AWS Global Accelerator works with the AWS Load-Balancer (Network or Application) to track the health of the web servers.

In my case, I have an EC2 instance running a Web Server in Oregon (US) and a VMware Cloud on AWS SDDC in Frankfurt, Germany.

In Frankfurt, I am using the same Network Load Balancer and the web farm I used in my previous post (Load-Balancing on VMware Cloud on AWS).

In Oregon and Frankfurt, I have built a Network Load Balancer and a Target Group attached to the Network Load Balancer that tracks the health of the web server (1 EC2 instance in Oregon and 4 Web Servers in my SDDC in Frankfurt):

• 

• 

When I create the Global Accelerator, I added the Oregon Network Load Balancer and Frankfurt Network Load Balancer as my endpoints and the Global Accelerator forwards the traffic from the users to their closest location.

• 

• 

• 

A user based in the UK when accessing the website will go the Frankfurt DC, while a U.S. based user will go to the Oregon one, despite connecting to the same IP address.

Try it yourself – http://13.248.136.128 should connect you to the closest webserver to your location.

In essence, we’re achieving some global server load-balancing without having to play around with DNS: AWS advertises the same IP out of its edge locations to the Internet and the user will enter its Edge Location, traverse the AWS private network and access the webserver.

With minimal effort, I have built a globally resilient web server and data can be accessed as close as possible to the users and I can address any latency, performance or regulatory requirement.