Continent Global Accelerator ALB Latency Reduction Africa 369 ms 497 ms 26% Asia 401 ms 580 ms 31% Europe 146 ms 154 ms 5% * North America 188 ms 312 ms 40% Oceania 377 ms 702 ms 46% South America 376 ms 498 ms 24%

* : 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.

USD per GB Traffic Total Price EC2 Data Transfer Out 0.09 700 GB USD 63.00 Global Accelerator (from EU to US) 0.015 350 GB USD 5.25 Global Accelerator (from EU to EU) 0.015 175 GB USD 2.63 Global Accelerator (from EU to ME) 0.035 175 GB USD 6.13

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.

Continent Global Accelerator CloudFront (✅ cache) Africa 369 ms 51 ms Asia 401 ms 179 ms Europe 146 ms 107 ms North America 187 ms 78 ms Oceania 377 ms 71 ms South America 376 ms 29 ms *

* : 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.

Continent Global Accelerator CloudFront (✅ cache) CloudFront (❌ cache) Africa 369 ms 51 ms 387 ms Asia 401 ms 179 ms 661 ms Europe 146 ms 107 ms 169 ms North America 187 ms 78 ms 374 ms Oceania 377 ms 71 ms 1008 ms * South America 376 ms 29 ms 530 ms

* : 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:3

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.4

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:

Criteria Support Score Feature Completeness ⚠️ 6 Documentation Detailedness ⚠️ 6 Tags (Grouping + Billing) ✅ 10 CloudFormation + Terraform support ❌ 5 Emits CloudWatch Events ❌ 0 IAM granularity ✅5 10 Integrated with AWS Config ❌6 0 Auditing via AWS CloudTrail ✅ 10 Available in all commercial regions ⚠️7 7 SLA ✅8 10 Total Maturity Score (0-10) ⚠️ 6.4

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.