Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

Global Accelerator for latency-sensitive multi-Region workloads

Some workloads are deployed in many Regions and are sensitive to latency in a way that makes DNS-based routing inadequate. Online games are the standard example — a few tens of milliseconds of difference is a competitive advantage — but the same requirement appears in voice, real-time collaboration, financial order entry and industrial telemetry.

The requirement

Section titled “The requirement”
  • The application runs in multiple Regions, typically behind load balancers fronting Auto Scaling groups.
  • Users must reach the nearest healthy Region, and must be moved off an impaired Region quickly and deterministically.
  • The transport may be UDP, or TCP that is not HTTP, so Layer 7 routing is not available.
  • Third parties may need a small, stable set of IP addresses to allow-list.

DNS-based failover cannot meet the second and third points reliably. Route 53 health checks work, but the recovery time is bounded by record TTL and by resolvers and clients that cache beyond it, and every Region needs its own address to publish.

The pattern

Section titled “The pattern”

AWS Global Accelerator provides two static anycast IPv4 addresses (four for a dual-stack accelerator, or your own range under BYOIP) announced from AWS edge locations worldwide. Client traffic enters the AWS network at the nearest edge and travels the AWS backbone to a Regional endpoint, rather than crossing the public internet end to end.

  • A listener on the accelerator matches the port and protocol the application uses — TCP or UDP.
  • An endpoint group per Region holds the endpoints in that Region. Application Load Balancers, Network Load Balancers, EC2 instances and Elastic IP addresses can all be endpoints.
  • Global Accelerator health-checks the endpoints continuously and routes traffic only to healthy ones, reacting to a change in health or configuration without waiting on DNS.
flowchart TB Users["Global users"] GA["AWS Global Accelerator<br/>2 static anycast IPs · Layer 4"] ALB1["ALB — Region 1"] ALB2["ALB — Region 2"] ASG1["Auto Scaling group<br/>EC2 instances"] ASG2["Auto Scaling group<br/>EC2 instances"] Users --> GA GA -->|health-checked| ALB1 GA -->|health-checked| ALB2 ALB1 --> ASG1 ALB2 --> ASG2

Why it fits

Section titled “Why it fits”
  • Failover is deterministic and fast, because it happens inside the AWS network at the edge rather than through DNS resolution.
  • The entry points are fixed, so allow-lists are two addresses regardless of how many Regions sit behind them, and the addresses stay with the accelerator for its lifetime.
  • It is protocol-agnostic at Layer 4, so UDP workloads are supported — this is the property that rules out CloudFront and ALB-based approaches for game traffic and for MQTT or SIP.
  • Most of the path is the AWS backbone, which is both lower-latency and less variable than the public internet.

When not to reach for it

Section titled “When not to reach for it”

Global Accelerator is a per-accelerator hourly charge plus data transfer, on top of the Regional infrastructure. For an HTTP application with a single-Region deployment and no static-IP requirement, CloudFront or a Regional load balancer with Route 53 latency routing does the job for less. The cases where Global Accelerator earns its cost are non-HTTP protocols, a hard static-IP requirement, and multi-Region deployments where failover speed is part of the specification.

Reference

Section titled “Reference”