AWS Global Accelerator
Key concepts
Anycast IP addresses
AWS global network
Endpoint groups
Health checks and failover
CloudFront vs Global Accelerator
Overview
AWS Global Accelerator is a networking service that improves the availability and performance of your applications for global users. It gives you two static anycast IP addresses (an anycast IP is a single address that is advertised from many AWS edge locations at once) that act as a fixed front door for traffic. User requests enter the AWS global network at the nearest edge location and travel over the AWS backbone to your application endpoints, avoiding the unpredictable hops of the public internet.
This topic is high-yield on the SAA-C03 exam in performance and resilience scenarios, especially questions about non-HTTP traffic (such as gaming, IoT, or VoIP), the need for static entry-point IP addresses, fast regional failover, and the choice between Global Accelerator and Amazon CloudFront. You should know what anycast IPs are, how the AWS global network reduces latency, how endpoint groups and traffic dials work, how health checks drive failover, and when to pick Global Accelerator over CloudFront.
Two Static IPs, Global Backbone Routing
Global Accelerator provides two fixed anycast IP addresses that route traffic onto the AWS global network at the closest edge location, then over the AWS backbone to healthy endpoints in one or more Regions. It improves performance for TCP and UDP workloads and provides fast cross-Region failover within seconds.
Pick Global Accelerator when you need static IP addresses, non-HTTP protocols (TCP/UDP such as gaming, VoIP, IoT, MQTT), or fast multi-Region failover. Pick CloudFront when you need to cache and serve HTTP/HTTPS content from the edge. Global Accelerator does not cache; it accelerates connections to your origin.
Key Concepts
Anycast IP Addresses
Static Anycast IP Addresses
When you create an accelerator, AWS assigns two static anycast IP addresses from the AWS edge network. Anycast means the same IP address is announced from many edge locations worldwide, so a user is automatically routed to the nearest entry point. These IPs never change for the life of the accelerator, so you can hardcode them in clients, firewalls, or DNS without rotation. You can also bring your own IP address range (BYOIP). The two addresses come from separate network zones, which are isolated units of the AWS network that give you redundancy if one zone has an issue.
AWS Global Network
Routing Over the AWS Backbone
The AWS global network is the private, congestion-controlled backbone that connects AWS edge locations and Regions. Once a user request reaches the closest edge location through an anycast IP, Global Accelerator carries it over this backbone to your application endpoint, rather than across the variable public internet. This reduces latency, jitter (variation in delay), and packet loss, and it improves consistency for users who are geographically far from your application Region.
Public Internet vs AWS Global Network
| Dimension | Public Internet Path | Global Accelerator Path |
|---|---|---|
| Entry point | Many ISP hops to the Region | Nearest AWS edge location |
| Transport | Public internet, variable | AWS private backbone |
| Latency and jitter | Higher and less predictable | Lower and more consistent |
| Front-door IPs | Region or load balancer DNS | Two fixed anycast IPs |
Listeners and Endpoint Groups
Listeners, Endpoint Groups, and Endpoints
An accelerator contains listeners that process inbound connections on a port or port range using TCP or UDP. Each listener has one or more endpoint groups, and each endpoint group maps to a single AWS Region. Inside a group you register endpoints such as Application Load Balancers, Network Load Balancers, EC2 instances, or Elastic IP addresses. Each endpoint group has a traffic dial (0 to 100 percent) that controls how much of the traffic directed to that Region is allowed through, which is useful for blue/green shifts or draining a Region. Within a group, endpoint weights distribute traffic across individual endpoints.
Accelerator Hierarchy
| Component | Scope | Purpose |
|---|---|---|
| Accelerator | Global | Owns the two static anycast IPs |
| Listener | Protocol and port | Accepts TCP or UDP connections |
| Endpoint group | One Region | Groups endpoints and sets the traffic dial |
| Endpoint | Single resource | ALB, NLB, EC2, or Elastic IP that serves traffic |
Client Affinity and Routing
Global Accelerator routes a request to the optimal endpoint group based on geographic proximity, the endpoint group traffic dial, and endpoint health. By default routing uses a 5-tuple (source IP, source port, destination IP, destination port, protocol) to spread flows. Setting client affinity to source IP keeps all connections from one client going to the same endpoint, which helps stateful applications that need a stable target.
Health Checks and Failover
Health Checks Drive Fast Failover
Global Accelerator continuously runs health checks against each endpoint. For ALB and NLB endpoints, it uses the load balancer existing health checks. For EC2 instances and Elastic IPs, you configure the protocol, port, path, interval, and threshold on the endpoint group. When an endpoint or an entire Region becomes unhealthy, Global Accelerator stops sending traffic there and routes to the next-best healthy endpoint group. Because the anycast IPs are static and failover happens at the network layer, recovery is typically within seconds and does not depend on DNS time-to-live (TTL) caching the way a DNS-based failover does.
Failover: Route 53 DNS vs Global Accelerator
| Dimension | Route 53 Failover | Global Accelerator |
|---|---|---|
| Mechanism | DNS record changes | Network-layer rerouting |
| Client dependency | Resolvers must respect TTL | No client DNS change needed |
| Front-door address | Changes per record | Same two static IPs |
| Typical recovery | Tied to DNS TTL | Within seconds |
CloudFront vs Global Accelerator
Choosing Between CloudFront and Global Accelerator
Both services use the AWS edge network, and they solve different problems. Amazon CloudFront is a content delivery network (CDN) that caches HTTP and HTTPS content at edge locations to serve cacheable web content, media, and APIs close to users. Global Accelerator does not cache; it accelerates and load-balances connections (including non-HTTP TCP and UDP) to your origin over the AWS backbone and gives you static anycast IPs with fast multi-Region failover. Use CloudFront for cacheable web delivery, and Global Accelerator for static IP requirements, non-HTTP protocols, or rapid Regional failover.
CloudFront vs Global Accelerator
| Dimension | Amazon CloudFront | AWS Global Accelerator |
|---|---|---|
| Primary purpose | Cache and deliver content | Accelerate connections to origin |
| Protocols | HTTP and HTTPS | TCP and UDP (any protocol) |
| Caching | Yes, at edge | No caching |
| Front-door address | Distribution domain name | Two static anycast IPs |
| Best for | Web, media, static and dynamic content | Gaming, VoIP, IoT, fast failover, static IPs |
Best Practices
1. Use the two static anycast IPs as a stable front door
└── Hardcode them in clients and firewall allowlists so they never need rotation
2. Put endpoints behind ALB or NLB inside each endpoint group
├── Reuse the load balancer health checks
└── Let the load balancer absorb intra-Region scaling and AZ failover
3. Run endpoint groups in multiple Regions for resilience
└── Health-based failover reroutes within seconds to a healthy Region
4. Use traffic dials for controlled traffic shifts
├── Lower a Region dial to drain it before maintenance
└── Use blue/green or gradual Regional cutovers
5. Reach for Global Accelerator on non-HTTP or static-IP needs
└── Choose CloudFront instead when content is cacheable HTTP/HTTPSCommon Pitfalls
Pitfall 1: Using Global Accelerator to Cache Web Content
Mistake: Expecting Global Accelerator to cache images, video, or API responses at the edge.
Why it fails: Global Accelerator accelerates connections over the AWS backbone and performs no caching, so cacheable content still travels to the origin on every request.
Correct Approach: Use Amazon CloudFront for cacheable HTTP and HTTPS content; use Global Accelerator for static IPs, non-HTTP protocols, or fast Regional failover.
Pitfall 2: Relying on DNS Failover When Seconds Matter
Mistake: Using Route 53 DNS failover alone for a latency-sensitive multi-Region application and expecting instant recovery.
Why it fails: DNS-based failover depends on resolver and client TTL caching, so some clients keep hitting the failed Region until cached records expire.
Correct Approach: Front the application with Global Accelerator so failover happens at the network layer behind the same static IPs, with recovery typically within seconds.
Pitfall 3: Registering Endpoints Without Working Health Checks
Mistake: Adding EC2 or Elastic IP endpoints and leaving health check ports or paths misconfigured.
Why it fails: If health checks cannot reach the endpoint, Global Accelerator marks it unhealthy and withholds traffic, or it sends traffic to a failing target if checks are too loose.
Correct Approach: Configure accurate health check protocol, port, path, and thresholds per endpoint group, or front endpoints with an ALB or NLB so its health checks are reused.
Pitfall 4: Assuming Source IP Is Preserved Automatically
Mistake: Expecting the original client IP at the application without enabling client IP preservation.
Why it fails: For some endpoint types the connection arrives from Global Accelerator addresses unless client IP preservation is enabled, which can break IP-based logic and security group rules.
Correct Approach: Enable client IP preservation where supported and adjust security groups to allow the Global Accelerator managed prefixes when preservation is off.
Test Your Knowledge
A multiplayer game uses UDP and needs the lowest possible latency for players worldwide, plus a fixed set of IP addresses that players can allowlist. Servers run on EC2 behind Network Load Balancers in three Regions. Which service best meets these needs?
An application is fronted by Global Accelerator with endpoint groups in us-east-1 and eu-west-1. The team must perform maintenance in us-east-1 and wants to gradually move traffic away from that Region without changing any client configuration. What should they adjust?
A company needs to cache and deliver static images and video to global users with the lowest origin load, and the content is served over HTTPS. Which service is the best fit?
Related Services
Quick Reference
Limits and Defaults
Global Accelerator Quick Facts
| Item | Value |
|---|---|
| Static IP addresses per standard accelerator | Two (separate network zones) |
| Supported endpoint protocols | TCP and UDP |
| Endpoint group per Region | One Region per endpoint group |
| Traffic dial range | 0 to 100 percent per endpoint group |
| Supported endpoints | ALB, NLB, EC2, Elastic IP |
| Caching | Not provided; use CloudFront for caching |
Common CLI Commands
# Create a standard accelerator (returns the two static IPs)
aws globalaccelerator create-accelerator \
--name prod-game-accelerator --ip-address-type IPV4
# Create a UDP listener on the accelerator
aws globalaccelerator create-listener \
--accelerator-arn arn:aws:globalaccelerator::123456789012:accelerator/abc123 \
--protocol UDP --port-ranges FromPort=5000,ToPort=5000
# Create an endpoint group in a Region with a traffic dial
aws globalaccelerator create-endpoint-group \
--listener-arn arn:aws:globalaccelerator::123456789012:accelerator/abc123/listener/def456 \
--endpoint-group-region us-east-1 \
--traffic-dial-percentage 100 \
--endpoint-configurations EndpointId=arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/game-nlb/aaaa,Weight=128
# List the static IP addresses assigned to the accelerator
aws globalaccelerator describe-accelerator \
--accelerator-arn arn:aws:globalaccelerator::123456789012:accelerator/abc123