Explained: AWS Global Accelerator

The failover drill was supposed to take five minutes. At 2:00 a.m. the team failed the primary region on schedule, the Route 53 health check noticed within seconds, and the DNS answer flipped to the standby site exactly as designed.

Twenty minutes later, the dashboards told a different story. Nearly half the clients were still connecting to the dead region. Nothing was misconfigured; every layer was doing exactly what it was built to do. The record's TTL said 60 seconds, but a JVM here, a corporate resolver there, and an ISP cache somewhere in between had all decided they knew better.

If you have lived through a version of that morning, you already understand half of what AWS Global Accelerator exists to fix. The other half is subtler: even on a good day, the public internet is a slow and unpredictable way to reach your application.

The two problems it solves

Start with the everyday one. When a user in Singapore connects to your application in us-east-1, their packets cross a dozen or more networks they have never heard of. Internet routing is driven by BGP, and BGP picks paths based on commercial peering relationships, not on latency. The result is a route that is rarely the fastest one available, changes without warning, and passes through congestion points nobody owns end to end.

The second problem is the one from the failover drill. The only public entry point to your application is an IP address, and the only way clients learn that address is DNS. When you need to move traffic somewhere else, changing the DNS answer is your one lever. As we will see, it is a weak lever, because you control the answer but not who keeps serving the old one.

Global Accelerator attacks both problems with the same move: it gives your application a fixed address at the edge of AWS's network, then handles everything behind that address itself.

What Global Accelerator actually is

Global Accelerator is a networking service that assigns your application two static anycast IP addresses. Anycast means the same IP address is announced from many places at once; every AWS edge location in the world advertises these two addresses simultaneously. When a client connects, internet routing naturally delivers the packets to the nearest edge.

From that edge onward, traffic travels on the AWS global network, the private fiber backbone that connects AWS edge locations and regions. The unpredictable, multi-carrier part of the journey shrinks to the short hop between the user and the nearest edge. Everything after that is a single, congestion-managed network that AWS operates end to end.

Two things Global Accelerator is not. It is not a CDN: it caches nothing and never looks inside your traffic. And it is not a DNS trick: it operates at the network layer, forwarding TCP and UDP as-is, which is why it works for protocols that CDNs cannot touch.

The static addresses come from dedicated AWS ranges, which matters more than it sounds. Enterprise customers can allowlist two addresses in their firewalls once, permanently, no matter how your backend evolves. If even that is too much change, you can bring your own IP ranges (BYOIP) and keep addresses your partners already trust.

How it works, piece by piece

An accelerator is the top-level resource that owns the two static IPs. Attached to it are one or more listeners, each defined by a protocol and port range, such as TCP on port 443. Each listener routes to endpoint groups, one per AWS region. Inside each group live the endpoints: Application Load Balancers, Network Load Balancers, EC2 instances, or Elastic IPs.

Two controls govern how traffic spreads. The traffic dial is a percentage on each endpoint group, letting you decide how much traffic a whole region receives. Endpoint weights do the same for individual endpoints within a group. Alongside both, Global Accelerator runs continuous health checks against every endpoint and stops sending traffic to anything that fails them.

Follow a single connection through. A client resolves your application's hostname and receives the two static IPs, an answer that will never change for the life of the accelerator. The client connects, and anycast routing lands the packets at the nearest edge location. For TCP listeners, Global Accelerator can complete the handshake right there at the edge, which noticeably speeds up connection setup for distant users. The edge then carries the traffic across the backbone to the chosen endpoint group, picks a healthy endpoint, and delivers it.

Failover is just a change in step four. If health checks fail for the active region, or if you turn its traffic dial to zero yourself, new connections flow to the other group. Nothing about the client-facing address changes, and the shift typically completes in well under a minute. For deliberate disaster recovery, the dials are the tool of choice: many teams keep automatic cross-region failover off and flip the dials from a runbook, so a flapping health check cannot trigger a surprise regional swing.

Why DNS failover disappoints, and what changes

Here is the comparison that makes Global Accelerator click. With Route 53 failover routing, a health check failure changes the answer Route 53 gives to new queries. That part works flawlessly. The problem is everyone who is not asking.

Between your application code and Route 53 sits a stack of caches. The JVM keeps its own DNS cache, controlled by networkaddress.cache.ttl, and under some configurations it caches a successful lookup forever. The operating system's resolver caches. The corporate DNS server caches, sometimes with an enforced minimum TTL. The ISP's resolver caches, and some of them treat your carefully chosen 60-second TTL as a suggestion. And clients with long-lived connection pools never re-resolve at all until a connection breaks.

Each layer serves the stale answer until its own timer expires. The practical result is a failover with a long, uneven tail: some clients move in a minute, some in twenty, and a few JVMs keep trying the dead address until someone restarts the process. You published a new answer; the internet kept handing out the old one.

Global Accelerator sidesteps the entire stack. There is no new answer to propagate, because the answer never changes. The failover happens on the far side of the static IPs, inside AWS's routing layer, where you hold the controls. Every client that connects or reconnects after the switch lands in the right region on the first try, whether its resolver stack is well behaved or hopeless.

One honest caveat: clients still have to reconnect. Established connections to a failed region die with it, and Global Accelerator cannot revive them. What changes is the bound on recovery time. It is now determined by your clients' reconnect and retry behavior, which you can measure and tune, rather than by resolver caches scattered across the internet, which you cannot.

Global Accelerator vs CloudFront

The two services get confused constantly because both use AWS edge locations and both make things faster. They solve different problems at different layers.

They are not competitors, and some architectures use both: CloudFront for the website, Global Accelerator for the TCP and UDP services behind it.

One variant deserves a mention. A custom routing accelerator maps specific ports on the static IPs deterministically to specific instances and ports, instead of load balancing. It exists for workloads like multiplayer game sessions or VoIP calls, where a particular user must reach one particular server, chosen by your own matchmaking logic.

Where you'll encounter it

• Multi-region disaster recovery. Active-passive setups where the failover must be fast, bounded, and immune to client-side DNS behavior; this is the scenario from the top of the post.
• Gaming, VoIP, and IoT. Latency-sensitive UDP traffic that CDNs cannot carry, where jitter on the public internet directly degrades the experience.
• Enterprise allowlisting. Partners who must add your addresses to firewall rules once and never again, regardless of how your infrastructure changes behind the scenes.
• Global APIs on load balancers. An NLB or ALB per region, fronted by one accelerator, so users worldwide get backbone routing and the closest healthy region automatically.
• Cross-region migrations. Traffic dials make it trivial to shift 5%, then 25%, then 100% of traffic to a new region and back out instantly if something goes wrong.

Cost is straightforward: a fixed fee of about $0.025 per hour per accelerator, roughly $18 per month, plus a data transfer premium that varies by route. For most teams evaluating it as DR infrastructure, that is a rounding error next to the cost of a failover that half works.

Wrapping up

Global Accelerator is best understood as a relocation of control. DNS-based failover leaves the critical moment of a disaster in the hands of resolver caches, JVM settings, and ISP behavior you will never see, let alone configure. Global Accelerator moves that moment behind two addresses that never change, into a routing layer where the switch is yours to flip and takes seconds.

The performance story follows from the same design: because clients always enter AWS at the nearest edge, their traffic rides a private backbone instead of the open internet. One service, one pair of IPs, and both of the hard problems of running a global application, speed and failover, get simpler at once.

Part of the Explained series — concepts in tech, clearly.