In November 2019 AWS launched a new 5 day course “Architecting on AWS Accelerator” which includes content from the “Advanced Architecting on AWS” course.
It covers Global Accelerator, so I am revisiting it for the scenario where it is used in front of Load Balancers.
The above slide shows the current model without Global Accelerator.
The problem with it is caching.
Say a user browses to www.example.com and is returned the IP of the LB in us-east-1. Then the LB in us-east-1 goes down for some reason. It will be replaced and its IP will change. The old IP has a high likelihood of being cached either locally or at a DNS cache.
The user browses to www.example.com
When we configure Global Accelerator we receive 2 static IPs.
We create a record set in Route 53 with these 2 IPs.
The browser will try to make a connection to one of the IPs.
Global Accelerator will typically direct the user to the LB nearest the user. In addition, the user will be routed via the nearest edge location, and from their the traffic will traverse the AWS network rather than the internet.
From the Global Accelerator home page:
To improve the user experience, AWS Global Accelerator directs user traffic to the nearest application endpoint to the client, thus reducing internet latency and jitter. It routes the traffic to the closest edge location via Anycast, then by routing it to the closest regional endpoint over the AWS global network. AWS Global Accelerator quickly reacts to changes in network performance to improve your users’ application performance.
Global Accelerator is also using health checks. In this scenario, rather than use its own health checks, it relies on the health checks of the LB.
To set this scenario up:
As a prerequisite I set up the following:
An instance in us-east-1 with a simple web page identifying its region eg “Hello from us-east-1”
An ALB in us-east-1 targeting the single instance.
I repeated the above for eu-west-1.
I tested access to the two ALB’s by browsing to their DNS names.
Now for the Global Accelerator part.
From the Global Accelerator console, create a Global Accelerator. Give it a name.
Add a Listener on TCP/80.
Add an Endpoint Group, choose us-east-1 from a drop down. Repeat for eu-west-1.
Add Endpoint for us-east-1, of type ALB, and choose the ARN of the ALB from a drop down.
Repeat for eu-west-1.
It takes about 5 minutes to deploy, and you receive 2 static IPs.
Put either one of them in a browser. You should see the web page of the instance in your closest region.
Stop that instance.
Wait until the target group indicates that the instance is unhealthy.
Refresh the browser. You should see the web page of the instance in the other region.
If you have a Route 53 hosted zone, create a record set. I used ga.thetrainit.com. Add the 2 static IPs of the GA.
Browse to ga.thetrainit.com to test it.
Start the stopped instance, wait for the target group to indicate that it is healthy and test again.
Some further notes:
If I do an nslookup on ga.thetrainit.com it returns the two IPs in a fairly unpredictable order.
From the FAQ:
If one static IP address becomes unavailable due to IP blocking, or unreachable networks, AWS Global Accelerator will provide fault tolerance to client applications by rerouting to a healthy static IP address from the other isolated network zone….With AWS Global Accelerator there is no reliance on IP address caching settings of client devices. The change propagation time is a matter of seconds, thereby reducing downtime of your applications.
To clean up:
Disable the Accelerator, which only took a few seconds for me.
Delete the Accelerator.
Delete the Route 53 record set.
In each region, delete the ALB, Target Group, and terminate the instance.
Some snippets from the FAQ
Q: How does AWS Global Accelerator work with Elastic Load Balancing (ELB)?
If you have workloads that cater to a global client base, we recommend that you use AWS Global Accelerator. If you have workloads hosted in a single AWS Region and used by clients in and around the same AWS Region, you could use an Application Load Balancer or Network Load Balancer to manage such resources.
Q: How is AWS Global Accelerator different from Amazon CloudFront?
Global Accelerator and CloudFront are two separate services that use the AWS global network and its edge locations around the world. CloudFront improves performance for both cacheable (e.g., images and videos) and dynamic content (e.g., APIs acceleration and dynamic site delivery). Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in a single or multiple AWS Regions. Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT) or Voice of IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic fast regional failover. Both services integrate with AWS Shield for DDoS protection.