Review: AWS Global Accelerator - Improving Latency and Design for Failure

The Cloud is all about networking. AWS introduced Global Accelerator at re:Invent in 2018. A year after that, it is about time to review the service. AWS Global Accelerator makes use of Amazon’s worldwide infrastructure and is designed to improve the performance and reliability of your applications.

Do you prefer listening to a podcast episode over reading a blog post? Here you go!

Let the review begin.

How It Works

The Global Accelerator provides two static Anycast IPv4 addresses. All you need to do is to define endpoints in one or multiple regions. The following endpoints are supported:

• Internet-facing Application Load Balancer (ALB)
• Internal Application Load Balancer (ALB)
• Internet-facing Network Load Balancer (NLB)
• Elastic IP
• EC2 Instance (with or without Public IP)

The Global Accelerator optimizes the route for each client, which means it minimizes the number of hops until a TPC or UDP package enters Amazon’s network and therefore reduces latencies. Also, Global Accelerator route requests to healthy endpoints only.

Global Accelerator creates a peering connection between your accelerator and a VPC that you created with Amazon Virtual Private Cloud (Amazon VPC). The traffic between Global Accelerator and your VPC uses private IP addresses.²

The Global Accelerator uses two public IP addresses for enhanced fault tolerance. There is also a DNS name available pointing to both public IP addresses (e.g., af56c15e2cd32aa08.awsglobalaccelerator.com ).

To make use of Global Accelerator, you need to:

1. Create an accelerator which provisions two static Anycast IP addresses.
2. Create a listener for the protocol and port or port range.
3. Create an endpoint group for every region you want to route traffic to.
4. Add an endpoint (e.g., an ALB) to each endpoint group.

On top of that, Global Accelerator supports shifting traffic between regions and endpoints gradually. A convenient feature to move your workload because of deployments or outages.

Want to reduce the traffic of a specific region? Use traffic dials to decrease traffic. For example, by reducing the traffic dial from 100% to 50%, half of the traffic will be routed to another region instead. When using multiple endpoints within a region, use the endpoint weight to adjust the proportion of traffic for each endpoint.

In case of a failure, re-routing traffic to other endpoints, availability zones, or regions happens within 30 seconds after the health check detects a failed endpoint.

Use Cases

Common scenarios for using the AWS Global Accelerator:

• Multi-Region: deploy your infrastructure to multiple regions and route traffic to the region that is closest to the client.
• Disaster Recovery: shift traffic from a region or endpoint affected by an outage to another endpoint. The Anycast IP addresses make sure all clients send requests to healthy endpoints only immediately.¹ Doing so is a challenge when using routing mechanisms based on Route 53 (DNS) due to caching issues.
• Static IP Address: some clients (e.g., IoT devices) might not be able to resolve names via DNS, or static IP addresses might be needed for a firewall rule (NLB is an alternative in that scenario).
• Low Latency: all scenarios, where latency is critical (e.g., trading, gaming, …).
• Blue-Green or Canary Deployment: shift traffic between infrastructures during deployments or for testing purposes.
• Origin Cloaking: use the Global Accelerator as public and protected (see AWS Shield) endpoint for an ALB or EC2 running in a private subnet.

Read on for a comparison of Global Accelerator and CloudFront.

Latency Benchmark

Reducing the latency for clients connecting to your endpoints worldwide is the unique selling point of Global Accelerator. But what kind of latency improvements can you expect? I run a latency benchmark on PerfOps. Special thanks to Dmitriy, CEO of PerfOps, for providing free credits to run the latency benchmark.

Please note, AWS announced TCP Termination at the Edge on March 23, 2020. The following latency benchmark is therefore outdated. That’s especially important for the comparison between Global Accelerator and CloudFront. Hopefully I will find time to update the latency benchmark soon.

• The benchmark was executed by 247 nodes distributed worldwide.
• The nodes are simulating traffic from different parts of the world. Results from real-world clients with consumer standard Internet connectivity might differ.
• The benchmark consists of 10,000 measurements per endpoint.
• An Application Load Balancer (ALB) in eu-west-1 was used as the only endpoint.
• The ALB responds with a static response without forwarding the request to a target.
• The benchmark measures the time-to-first-byte (TTFB).

In short, Global Accelerator delivers what it promises. The network latency is specified in the 95th percentile.

That’s a latency reduction by 33%.

The following table illustrates the latency reduction that you can achieve from different continents when fronting your ALB with a Global Accelerator. Again, we are having a look at the 95th percentile.

*: Note that the ALB is running in eu-west-1. Therefore, it is not surprising that there is no significant difference between the latency of Global Accelerator and the ALB.

Note that latencies can be further improved by adding more regional endpoints (e.g., additional load balancers in North America and Asia). Of course, that also requires you to duplicate your infrastructure and data, which is an entirely different story.

Pricing

It is complicated to estimate the costs for adding Global Accelerator to your infrastructure in advance.

First of all, each public IP address pair (aka. accelerator) provided by Global Accelerator costs USD 18 per month.

On top of that, you pay an additional fee for the traffic. Roughly estimated, the premium is 20% on your traffic. It might surprise you that you not only pay for outgoing traffic but also for incoming traffic. Or to be more precise, you are paying for the dominant traffic direction (either incoming or outgoing traffic).

So let us assume, your infrastructure leverages a Global Accelerator as well as an Application Load Balancer in eu-west-1. Your workload results in 1,000 GB of traffic per month. 700 GB of that traffic is outbound. So outbound is your dominant direction, and you pay for those 700 GB, but not for the other 300 GB inbound. 50% of the traffic is transferred to the United States, 25% to Europe, and 25% to the Middle East.

For more details, visit the official pricing page.

CloudFront vs. Global Accelerator

When optimizing for low latency and response times, CloudFront - the Content Delivery Network (CDN) - is an obvious choice. Both services optimize the route of a request from clients all over the world to your endpoints. However, CloudFront can process a request and cache a response from 200 locations distributed worldwide. The Global Accelerator routes the packages to one of your endpoints (one or multiple endpoints optionally distributed among regions).

There is another fundamental difference between CloudFront and Global Accelerator: CloudFront caches responses from your endpoints. At best, CloudFront can answer an incoming request from an edge location near to the client without forwarding a request to your endpoint. Depending on your workload, the majority of requests are cacheable, which reduces the response times and latencies enormously.

In summary, the result of the latency benchmark with the same setup, as described above, is not a surprise. The Global Accelerator reduces the latency to the ALB. But still, the package is routed from each continent to the ALB in eu-west-1. CloudFront, on the other hand, was able to cache the responses at the edge locations.

*: Please note that for some continents, the benchmark is running on less than ten different nodes. Some of the nodes might even be located in or near an AWS data center.

When caching a response is not an option, CloudFront has to forward each request to the ALB. CloudFront needs to process each request that results in a higher latency compared to using Global Accelerator, which routes the packages directly to the ALB immediately.

*: Please note that for some continents, the benchmark is running on less than ten different nodes. Some of the nodes might even be located in or near an AWS data center.

What do these benchmark results mean in practice?

When to use CloudFront?

• The protocol is HTTP/HTTPS.
• The majority of responses can be cached.
• Processing decrypted data outside the EU (GDPR)/another territory is not an issue.

When to use Global Accelerator?

• When using CloudFront is not an option (see above).
• For all non-HTTP workloads based on TCP or UDP. For example, Voice-over-IP, DNS, MQTT, FTP, …
• Fast and reliable multi-region disaster recovery is required (does not rely on DNS).
• When you don’t want to make your endpoint publicly available (with the exception of S3).

Private Subnet

There is no way to reach an instance placed into a private subnet from the Internet. Agree?

That is no longer the case. With Global Accelerator, you can add a public endpoint to any instance running in a private subnet. The only requirement is an Internet Gateway attached to the VPC.

Keep that in mind, when writing IAM policies to deny creating publicly available resources or when configuring compliance checks.

Missing Features

I can’t understand why CloudFormation still doesn’t have support for Global Accelerator. However, the missing resources have been added to the public road map recently. As usual, Terraform already supports the newish service.

As discussed at the beginning, deploying applications and infrastructures seamlessly is a use case for Global Accelerator. However, there are no integrations with developer tools and management tools, yet. For example, CodePipeline or CodeDeploy should offer ways to do a blue-green or canary deployment with the help of Global Accelerator.

Limits

The following service limits are documented:³

• 20 accelerators (2x 20 static Anycast IP addresses) per AWS account
• 10 listeners per accelerator
• 10 port ranges per listener
• 10 endpoints per endpoint group

Also, I stumbled upon the following limitation in the documentation: the idle timeout is 90 seconds for TCP connections and 30 seconds for UDP connections.⁴

It is worth noting that the AWS Global Accelerator does not support IPv6 yet.

Service Maturity Table

The following table summarizes the maturity of the service:

Our maturity score for AWS Global Accelerator is 6.4 on a scale from 0 to 10.

Summary

By optimizing the route from the clients distributed worldwide to your endpoints, the AWS Global Accelerator optimizes the network latency significantly. On top of that, a multi-region infrastructure benefits from the routing possibilities provided by AWS Global Accelerator. The service maturity is good for a 1-year-old service. As described above, some features are missing. I haven’t used Global Accelerator in any project yet, because CloudFront was doing the trick so far.