AWS Global Accelerator compared to CloudFront and Route53

When AWS Global Accelerator was announced in November 2018 many engineers were asking what does it actually bring? The key features of Global Accelerator is using AWS backbone network and latency based region selection with failover.

While it might sound awesome, similar features were available in other AWS services for a while.
For example, in Cloudfront CDN traffic between Edge location and Origin also uses internal AWS network. And Route53 is offering multiple possibilities for GEO based DNS, when nearest region is selected automatically, with customizable healthchecks and failover possibilities.

To understand a use case for AWS Global Accelerator, let's compare different achitectures of web application hosted in cloud.

The old good Cloudfront

This is a classic architecture for web application, with global availability requirements. Idea behing this architecture is to pass whole web traffic via cloudfront. It allows to use caching for website assets, make full use of AWS backbone network between Edge location and backend application. 

Advantages of this architecture:

• Possibility to cache website assets and main traffic in Edge location, close to end user.
• Between Edge location and origin (your backend) AWS internal network is used, which allows for traffic to pass faster.
  For example, latency between Sau Paulo and Ireland using public network could be 600ms, but via AWS network it's usually under 200ms.
• Possibility to use persistent SSL connections between Edge location and Origin (backend application). This allows to skip SSL handshakes between regions, which takes a lot of time due to latency.
• Any server can be used as Cloudfront origin. It can be AWS services like Load Balancers, or S3 buckets, or even a static IP, outside of AWS network. This allows to apply Cloudfront approach even for applications not hosted on AWS.

While this architecture is great for end-users, it brings some complexity for IT operations:

• Route53 should be used as DNS in order to use Alias record for domain.
• Any tiny change for Cloudfront configuration takes ~40 minutes to be applied due to Cloudfront internal architecture.
• There are outages on some Cloudfront Edge locations from time to time, and users in some regions are affected. Usually outages are self resolved within an hour, but it's dissapointing that there is nothing to do if you see such an outage.

Let's try to extend this architecture, via addind multiple backend resources in different regions.

Multi regional setup with Cloudfront

To add multiple regions to previous architecture we need to somehow balance traffic between them. Luckly Route53 offers a latency based DNS records, which allows connection to closest region. Route53 also offers healthchecks, so if one region becomes offline, all traffic will be passed to another healthy region.

The way of request in this case: User requests domain www.example.com, which is resolved to Cloudfront distribution. This way request reaches Cloudfront Edge location, closest to User. Edge location has an origin configured to domain origin.example.com. This domain is resolved by Route53 Latency based record to closest region (backend service).

This architecture has same pros and cons as previous setup with single region.

AWS Global Accelerator without caching

Now it's time to make use of Global Accelerator. By simply putting it between user and backend services, we achieve almost same capabilities, like in previous setup (Multi regional setup with Cloudfront).

Advantages of AWS Global Accelerator solution over Cloudfront based solution:

• No need in Route53 and Alias record for domain. Global Accelerator provides 2 dedicated IPs, which can be used with any 3-rd party DNS.
• Faster configuration. Dispite Cloudfront configuration, Global Accelerator updates itself immediatelly, so in critical situation updates can be applied faster.

Disadvantages of Global Accelerator over solution with Cloudfront:

• There is no caching on the edge locales. Not possible to cache website assets, or API responses, or do full-page caching.
• Not possible to run Lambda Edge on Edge locales.

While being easier and simplier to set-up, Global Accelerator is missing caching at Edges. So, how our architecture would look if we still need to add caching?

Multi regional app with AWS Global Accelerator and Cloudfront

If we need caching - we have to introduce Cloudfront in front of the whole chain:

Looks complex, isn't it? Let's compare it to Scheme 2: Multi regional setup with Cloudfront:

• Adding Global Accelerator made system more complex: extra proxy in the line eats some milliseconds in every request.
• Architecture without Global Accelerator was also more flexible: it allows to have non-AWS IP as a backend, while Global Accelerator can work only with AWS Load Balancers and Elastic IPs as backend.

Conclusion

For a domain that has only API endpoints, and never needs caching - better to set-up AWS Global Accelerator and use architecture from Schema 3: Multi regional application using AWS Global Accelerator.

For a domain with a website, or API endpoints that might need caching - better to go for a solution with Cloudfront + Route53, see Schema 2: Multi regional setup with Cloudfront