Hacker News new | ask | show | jobs
by rebyn 2755 days ago
I'm having a hard time trying to wrap my head around this. What are the differences between this and CloudFront?
3 comments

Seems like Amazon's response to GCE Premium Network Service tier. Instead of user traffic going over regional ISPs until it hits the AWS region, user traffic hits an AWS PoP and then uses Amazon's backbone network to get to the AWS region running your service, leading to marked improvements in multi-region deployments.

With CloudFlare, you're limited to what you can run in a CloudFlare PoP (i.e. CloudFlare workers).

(CloudFront, not CloudFlare.)

So CloudFront added support for custom origins a while back (making it more like normal CDNs) and with Lambda@Edge you could direct the user to the correct region.

https://aws.amazon.com/blogs/networking-and-content-delivery...

It's a global loadbalancer that works across regions and directs traffic over their private network to the closest backend based on a number of factors, and provides a single IP endpoint to the rest of the internet.

Google has Global Load Balancing: https://cloud.google.com/load-balancing/

Azure has Front Door: https://azure.microsoft.com/en-us/services/frontdoor/

Various CDNs like Akamai, Cloudflare and Fastly also have the same if you need to span multiple providers. Azure supports this also with custom endpoints.

Or, Global Accelerator vs using Route53 Latency based routing and multiple regions?
Global Accelerator:

You get static IP addresses that are broadly announced over the Global AWS backbone. That means that traffic gets onto the AWS network ASAP and that network takes it from there. It's really useful even if you're only in one region. Actually that's when it's most useful, because the more reliable AWS network can carry the traffic further for you.

These static IP addresses are provided using BGP anycast. Anycast can be slow to respond to network events such as link failures. Networks have to propagate BGP updates when conditions change. To provide fault-tolerance, Global Accelerator can provide you with multiple static IPs, and these will be served by diverse paths.

You can hardcode the static IPs in your DNS and firewall configurations, and use ordinary client retry behavior to drive the fault-tolerance.

Route 53 Latency Based Routing and Multiple regions:

Route 53 LBR uses constantly-running network latency measurements to figure out the best AWS region to send your traffic to. This traffic will generally enter the AWS backbone close to the target region, with your user's ISPs and their Internet transit providers carrying the traffic more of the distance. If you are running in many regions, then the average distance to users may be low enough that that network reliability is not a factor.

Route 53 LBR uses DNS health-checks to respond to network events. These health-checks are often faster to respond than BGP anycast, so can be preferable for cases where clients do not retry quickly.

Clients need to resolve DNS and it is harder to hardcode entries in firewall configurations etc.

Overall: both make sense, and GA really shines when you are serving globally from a relatively small number of regions to begin with.

Would there be any benefit of using Global Accelerator and Route53 together?

When a Global Accelerator "instance" is created, it seems like it creates 2 new Public IP addresses per Region ( and then those are then BGP Anycast'ed from the Av.Zones and Edge Locations around that Region). Does this mean that:

GlobalAcceleratorInstance1

Region1:

   PublicIPAddress1

   PublicIPAddress2

 Region2: 

   PublicIPAddress3

   PublicIPAddress4

 Region3:

   PublicIPAddress5

   PublicIPAddress6
?

And will Route53 then allow me to create a record that points to a magic geo/lbr Alias record type to resolve these to some great additional benefit?

Or would the idea be to just create one pair of them in one region near my "origin" IP - and BGP Anycast takes care of the rest and basic DNS A records as usual?

Kind hope AWS uses this first. We do not have to refer to each region endpoint like calling Athena service....