Global Accelerator and Anycast

By the end of this lesson you will be able to

• Explain why users far from a Region suffer on the public internet (hops, congestion, jitter, loss), and how Global Accelerator moves their traffic onto the AWS global network at the nearest edge location.
• Tell unicast from anycast, and explain what the two static anycast IP addresses of an accelerator give you: one fixed entry point, the nearest edge, and no DNS caching problem.
• Build an accelerator from its parts: listeners (TCP, UDP, ports), endpoint groups (one per Region) and endpoints (ALB, NLB, EC2 instance, Elastic IP), public or private.
• Predict how health checks, failover, traffic dials and endpoint weights move traffic, including what happens to open connections and when nothing is healthy.
• Decide when the endpoint sees the real client IP address, and how Global Accelerator fits with Shield, security groups and firewall allow lists.
• Choose between Global Accelerator, CloudFront and Route 53 latency routing for a scenario, and justify the choice.

#Global users, one Region

#Why the public internet is slow and unsteady

Your application runs in one Region, but your users are everywhere. When a player in Dhaka connects to a game API in us-east-1 (Virginia), the packets cross a chain of networks that belong to other companies: the home ISP, one or more transit providers, undersea cables, more transit, and finally AWS. Each of these networks decides on its own where to send the packet next, usually by business agreements (BGP policy), not by what is fastest for you.

That causes three problems:

• Latency. Every hop adds delay, and the path is often longer than the map suggests. A round trip from Dhaka to Virginia of 250 ms or more is normal.
• Jitter. On a busy link, packets wait in queues of changing length, so the delay goes up and down from one packet to the next. For a game or a voice call, unsteady delay hurts as much as high delay.
• Loss. A congested link drops packets. TCP notices and resends, but only after a timeout, and the resend crosses the whole path again. UDP does not resend at all: a lost game update is simply lost.

The slides draw it as users in America, Europe, India and Australia all reaching one public ALB across many internet hops. The wish is simple: get onto the AWS network as early as possible, and stay on it.

#What Global Accelerator does

AWS Global Accelerator is a global networking service that pulls your users’ traffic off the congested public internet at the AWS edge location nearest to them, and carries it over the AWS global network (the AWS backbone) to your application in one or more Regions. The result, as the notes put it: more speed, lower latency and less jitter.

• It works at layer 4: it carries TCP and UDP, on any port. It does not understand or change HTTP.
• It gives you two static anycast IP addresses (next section) as the fixed entry point for your application.
• It caches nothing. Every packet goes to your endpoint; Global Accelerator only makes the road better and picks the healthiest, nearest destination.
• At the edge it terminates the TCP connection and, almost at once, opens a new one to your endpoint. The client’s handshake and any resends only cover the short distance to the edge.

#Unicast and anycast

#Unicast: one address, one place

On the normal internet every IP address belongs to exactly one machine, a 1:1 relationship. This is unicast. If your server 198.51.100.10 is in New York, a user in Tokyo reaches it by crossing the Pacific and North America; a user in London crosses the Atlantic. Wherever the user is, the address leads to the one place where it lives, and far users pay with latency.

#Anycast: one address, many places

With anycast, the same IP address is announced from many places at once, a 1:many relationship. Each location tells the internet with BGP “I can reach 192.0.2.10”. Routers everywhere learn several paths to that address and keep the shortest, so every user is carried to the nearest location that announces it. If one location stops announcing (it fails, or is taken out for maintenance), routers forget that path within seconds and users are carried to the next nearest one, without any change on their side.

The slides draw the difference with two pictures: in unicast each server holds its own address, in anycast all servers hold the same one and the client is routed to the nearest. Anycast is not new or special to AWS: the DNS root servers, Route 53’s own name servers (lesson 8.5) and many CDNs use it.

#The two static IP addresses

When you create an accelerator, Global Accelerator gives it:

• Two static IPv4 addresses, both anycast from the AWS edge network. Each is served from a separate network zone (an isolated unit, like an Availability Zone for the edge network) and a different IP subnet, so if one address is unreachable from some client network, the client can retry on the other.
• With a dual-stack accelerator, two static IPv6 addresses as well: four in total. (Side note: IPv6 support arrived in 2022 for ALB endpoints and was extended to EC2 and NLB endpoints in 2023; it costs nothing extra.)
• A DNS name like a1234567890abcdef.awsglobalaccelerator.com that resolves to the static IPs (plus a dualstack name for dual-stack). You usually point your own domain at it with a Route 53 Alias record (lesson 8.2).
• Instead of Amazon’s addresses you can bring your own IPv4 range (BYOIP) and assign addresses from it.

The addresses stay assigned as long as the accelerator exists, even while it is disabled and routes no traffic. When you delete the accelerator, the addresses are gone for good. Protect production accelerators against deletion with IAM (for example tag-based permissions).

Because the addresses never change, two problems disappear:

• No client cache problem. The slides put it this way: the IP does not change, so it does not matter what clients, resolvers or apps have cached. When you add Regions, replace load balancers or fail over, the address in front stays the same.
• Easy allow lists. A customer’s firewall needs exactly two addresses (four with IPv6) to reach your whole multi-Region application.

#How an accelerator is built

#Listeners, endpoint groups and endpoints

The endpoint types of a standard accelerator are exactly four:

• Application Load Balancer: internet-facing or internal.
• Network Load Balancer: internet-facing or internal.
• EC2 instance: in a public or a private subnet.
• Elastic IP address.

So the slides’ “public or private” is literal: an internal ALB or an instance in a private subnet with no public IP can sit behind an accelerator. The accelerator becomes the only public entry point, and nobody on the internet can reach the endpoint directly. The VPC must still have an internet gateway attached (it marks the VPC as accepting internet traffic), but the subnet needs no route to it and the endpoint needs no public address.

Things that are not endpoints: S3 buckets, CloudFront distributions, API Gateway APIs and Lambda functions. (To reach an API Gateway through static IPs, AWS shows a pattern with an NLB or ALB in front of a VPC endpoint.)

A listener can also override ports (for example, accept 443 and send it to 8443 on the endpoints), and set client affinity: None (the default, each connection hashed on the full 5-tuple, so one client’s connections may land on different endpoints) or Source IP (hashed on source and destination IP, so a client keeps reaching the same endpoint, useful for stateful apps).

#Standard and custom routing accelerators

• A standard accelerator chooses the endpoint for you: the nearest healthy endpoint group, then an endpoint by weight. This is what the rest of the lesson describes and what the exam means by “Global Accelerator”.
• A custom routing accelerator lets your application logic decide: each static IP and port on the accelerator maps to one specific EC2 instance and port in a VPC subnet. A matchmaking service puts four players into the same session on one game server, or a VoIP service assigns callers to one media server. There are no health checks and no failover (you chose the destination), the client IP is always preserved, and only IPv4 is supported.

#Connections and timeouts

Global Accelerator keeps sending an established connection to the endpoint it chose until the connection ends or goes idle. The idle timeouts are fixed: 340 seconds for TCP and 30 seconds for UDP, and TCP keep-alive packets do not count as activity (send at least one byte of data). An endpoint is chosen again only for a new connection or after an idle timeout. Keep this in mind for failover, below.

Two smaller facts that confuse people in tests: the edge answers ICMP ping itself, so ping to the static IP measures only the distance to the edge, never your application; and all Global Accelerator API calls go to us-west-2 (Oregon), whatever Regions your endpoints are in.

#Health checks and fast failover

#How Global Accelerator decides that an endpoint is healthy

A standard accelerator sends traffic only to healthy endpoints, and a new endpoint must pass a health check before it gets any traffic.

• ALB and NLB endpoints use the load balancer’s own target health checks (configured in ELB, lesson 6.2). An ALB counts as healthy when every target group has at least one healthy target; an NLB when at least one Availability Zone has a healthy target in all its target groups.
• EC2 instance and Elastic IP endpoints use the health check settings of the endpoint group: protocol TCP (default), HTTP or HTTPS, a port (default: the listener port), a path for HTTP(S) (default /), an interval of 10 or 30 seconds (default 30), and a threshold of 1 to 10 consecutive results (default 3).
• On a UDP listener with EC2 or Elastic IP endpoints, the health check uses TCP on the listener port, so the endpoint must also run a TCP server on that port, or it is marked unhealthy however healthy the game is.
• The checks come from the Route 53 health checker IP ranges, so for EC2 endpoints your security groups and firewalls must let those ranges in.

#Failover between Regions

The rules, in order:

1. Traffic goes to the endpoint group nearest to the client (after applying traffic dials), and inside it to healthy endpoints in proportion to their weights.
2. If an endpoint becomes unhealthy, new connections go to the other healthy endpoints of the group at once.
3. If a group has no healthy endpoint with a weight above 0, Global Accelerator fails over to the next nearest group that has one, ignoring traffic dials (a group dialled to 0 can still receive failover traffic).
4. If the three closest groups have no healthy endpoint, it fails open: it sends traffic to a random endpoint in the closest group, on the basis that a broken health check is more likely than a whole planet of broken servers.
5. When a Region recovers, normal routing returns in about 30 seconds. Established connections are not moved in either direction; they continue until the client or server resets them or the idle timeout ends them, so clients should be able to retry.

The slides sum this up as “failover in less than 1 minute for unhealthy endpoints”: with a 10-second interval and a threshold of 3, an EC2 endpoint is declared unhealthy after about 30 seconds, and the switch itself is immediate. That is why Global Accelerator is good for disaster recovery: the standby Region is already behind the same IPs.

#Why this beats DNS failover

Route 53 can fail over too (failover routing, lesson 8.3, with health checks, lesson 8.4), but DNS has a weakness Global Accelerator does not: caching. After Route 53 switches its answer, every resolver, operating system and app that cached the old answer keeps sending users to the dead Region until its copy expires, and some keep it longer than the TTL. You cannot control those caches. With Global Accelerator, the answer never changes: the switch happens behind the static IPs, inside AWS, so there is nothing to go stale.

#Traffic dials and endpoint weights

Two controls change where a standard accelerator sends traffic, at two different levels:

Some details worth remembering:

• A dial is not a share of all traffic. With Mumbai at 30 %, Mumbai accepts 30 % of the connections that would have gone to Mumbai; users who are nearer to Singapore are not affected.
• A change applies to new connections only. Existing connections drain on their own.
• Health checks keep running whatever the dial says.
• Weights 1 and 255 send 1/256 (about 0.4 %) to the first endpoint. In some rare cases (for example, to avoid connection collisions when the client IP is preserved) Global Accelerator overrides weights to keep traffic flowing.

#Client IP address preservation

Because the edge terminates TCP and opens a new connection, the packets that reach your endpoint could carry an address of Global Accelerator as their source instead of the client’s. With client IP address preservation, the endpoint sees the client’s real address.

Why it matters, and what it changes:

• The application, its logs and AWS WAF on the ALB see the real client, so per-IP rate limits, geo decisions and fraud checks work. (An ALB also passes it on in X-Forwarded-For.)
• The endpoint’s security group must now allow the clients’ addresses (for a public service, the internet), not Global Accelerator’s.
• Preserved traffic arrives through Global Accelerator’s network interfaces in your subnet, so it bypasses network ACLs, Gateway Load Balancer inspection and AWS Network Firewall. Security groups still apply.
• A dual-stack accelerator only accepts endpoints with client IP preservation on.
• To move an Elastic IP endpoint to preservation, add the EC2 instance as an endpoint and shift the weights.

#Security: Shield and two addresses to allow

• DDoS protection. Global Accelerator is protected by AWS Shield Standard automatically and at no extra cost, at the edge where attacks are absorbed before they reach your Region. For larger targets, Shield Advanced can protect accelerators too (cost protection and the Shield Response Team). Depth is in chapter 21 (WAF, Shield, Firewall Manager).
• A smaller surface. With internal ALBs or private instances as endpoints, the accelerator is the only way in; the endpoints have no public address to attack.
• Allow lists. The slides: only two external IPs need to be whitelisted. A bank, a government office or a factory network that only allows outbound connections to listed addresses adds two entries for your whole global application, and never has to change them.
• What it does not do. Global Accelerator has no WAF of its own and does not inspect HTTP. Your security groups and AWS WAF rules on the ALB keep working as before.

#Global Accelerator vs CloudFront

Both use the AWS global network and its edge locations, and both are protected by Shield. They solve different problems.

Two corrections to the simple version of this table in the notes:

• CloudFront is not only for static content. It also speeds up dynamic content and APIs (warm connections to the origin, TLS at the edge, WebSockets, gRPC since 2024). And Global Accelerator is not only for non-HTTP: the slides list HTTP apps that need static IPs or fast Regional failover as a good fit too.
• “CloudFront has dynamic IPs” is still the exam answer, but since November 2024 CloudFront offers Anycast Static IPs: a dedicated list of 21 static anycast addresses per account for allowlisting and zero-rating with mobile carriers, or 3 addresses for pointing an apex domain with A records. It needs approval from AWS and the “all edge locations” price class, and costs extra. For “the customer needs fixed IP addresses”, the exam still expects Global Accelerator.

#And Route 53 latency routing?

Route 53 latency-based routing (lesson 8.3) also sends users to the nearest Region, so it is the third option in many questions.

Try each scenario yourself before reading the reason:

#What goes wrong

#Global Accelerator in system design

• Multi-Region active/active. Endpoint groups in two or more Regions behind the same IPs; each user lands in the nearest healthy one, and weights and dials share the load. Data replication between the Regions (DynamoDB global tables, Aurora Global Database) is your job; Global Accelerator only moves connections.
• Active/standby disaster recovery. The standby Region’s group sits behind the same IPs at a low or zero dial; failover ignores the dial, so it takes over when the primary is unhealthy. Clients never re-resolve anything.
• Real-time games, voice and IoT. UDP or TCP listeners in front of NLBs or EC2 fleets, with custom routing when the application must pick the exact server.
• HTTP APIs with fixed IPs. Global Accelerator in front of ALBs gives partners two addresses, keeps ALB features (path routing, WAF, authentication), and adds fast Regional failover.
• Private applications with a public front door. Internal ALBs in private subnets, reachable only through the accelerator.
• Built into other AWS services. S3 Multi-Region Access Points route requests over Global Accelerator to the nearest bucket (lesson 10.9). S3 Transfer Acceleration, by contrast, uses CloudFront’s edge network (lesson 10.6).
• Together with CloudFront. Static files and pages through CloudFront, the game, chat or payment traffic through Global Accelerator. Each does what it is best at.
• Know the cost. About $18 a month per accelerator plus the per-GB premium. For a small app where DNS caching is acceptable, Route 53 latency routing is cheaper.

#Try it yourself

All Global Accelerator API calls go to us-west-2, even when the endpoints are elsewhere. The ARNs below are shortened examples.

# 1. Create an accelerator: two static IPv4 addresses are allocated at once
aws globalaccelerator create-accelerator --name shop-api --ip-address-type IPV4 \
  --region us-west-2
#   "IpSets": [{ "IpAddresses": ["192.0.2.10", "198.51.100.20"], "IpAddressFamily": "IPv4" }],
#   "DnsName": "a1234567890abcdef.awsglobalaccelerator.com"

# 2. A TCP listener on 443 (client affinity None is the default)
aws globalaccelerator create-listener --region us-west-2 \
  --accelerator-arn arn:aws:globalaccelerator::111122223333:accelerator/1234abcd \
  --protocol TCP --port-ranges FromPort=443,ToPort=443 --client-affinity NONE

# 3. One endpoint group per Region: Mumbai with an ALB, client IP preservation on
aws globalaccelerator create-endpoint-group --region us-west-2 \
  --listener-arn arn:aws:globalaccelerator::111122223333:accelerator/1234abcd/listener/0123vxyz \
  --endpoint-group-region ap-south-1 --traffic-dial-percentage 100 \
  --endpoint-configurations EndpointId=arn:aws:elasticloadbalancing:ap-south-1:111122223333:loadbalancer/app/shop-blue/50dc6c495c0c9188,Weight=128,ClientIPPreservationEnabled=true

#    …and Singapore, with health checks every 10 s, 3 failures to switch (used by EC2/EIP endpoints)
aws globalaccelerator create-endpoint-group --region us-west-2 \
  --listener-arn arn:aws:globalaccelerator::111122223333:accelerator/1234abcd/listener/0123vxyz \
  --endpoint-group-region ap-southeast-1 --health-check-interval-seconds 10 --threshold-count 3 \
  --endpoint-configurations EndpointId=i-0abcd1234example,Weight=128

# 4. Watch health, then dial Mumbai down for maintenance and back up
aws globalaccelerator describe-endpoint-group --region us-west-2 --endpoint-group-arn <arn>
aws globalaccelerator update-endpoint-group --region us-west-2 --endpoint-group-arn <arn> \
  --traffic-dial-percentage 0
aws globalaccelerator update-endpoint-group --region us-west-2 --endpoint-group-arn <arn> \
  --traffic-dial-percentage 100

# 5. Compare the paths: time to first byte directly and through the accelerator
curl -s -o /dev/null -w 'connect %{time_connect}s  first byte %{time_starttransfer}s\n' \
  https://shop-blue-123456789.ap-south-1.elb.amazonaws.com/health
curl -s -o /dev/null -w 'connect %{time_connect}s  first byte %{time_starttransfer}s\n' \
  https://a1234567890abcdef.awsglobalaccelerator.com/health -k
traceroute -T -p 443 192.0.2.10      # far fewer hops before you are inside AWS

# 6. Clean up: disable first (the IPs are kept while disabled), then delete (the IPs are lost)
aws globalaccelerator update-accelerator --region us-west-2 --accelerator-arn <arn> --no-enabled
aws globalaccelerator delete-accelerator --region us-west-2 --accelerator-arn <arn>

-k in step 5 is only because the certificate on the ALB names your domain, not the accelerator’s DNS name; in real use, point an Alias record for api.example.com at the accelerator. AWS also runs a public Speed Comparison Tool that downloads a file from several Regions directly and through Global Accelerator, so you can see the difference from your own connection. Remember the fixed fee: delete test accelerators when you are done.

#Summary

Key takeaways

• Users far from a Region suffer from internet hops, congestion, jitter and loss. Global Accelerator takes their traffic onto the AWS global network at the nearest edge location and carries it to your endpoints. It works at layer 4 (TCP and UDP), terminates TCP at the edge, and caches nothing.
• Unicast: one IP, one server (1:1). Anycast: one IP announced from many places (1:many); each user reaches the nearest, and a failed site is routed around automatically. Like the emergency number 999.
• An accelerator has two static anycast IPv4 addresses (plus two IPv6 when dual-stack, or BYOIP) and a DNS name. The IPs are kept while the accelerator exists, even disabled, and lost when it is deleted. No client cache problems; only two IPs to allowlist.
• Parts: listener (TCP/UDP, ports) → endpoint group (one per Region, traffic dial 0–100 %, health check settings) → endpoints (ALB, NLB, EC2, Elastic IP, public or private, weight 0–255, default 128). Custom routing accelerators map ports to specific EC2 instances.
• Health checks: ALB/NLB use ELB target health; EC2/EIP use TCP/HTTP/HTTPS every 10 or 30 s, threshold 3. Failover to the next nearest healthy Region, ignoring dials, well under a minute, behind the same IPs; nothing healthy → fail open. Open connections are not moved.
• Client IP preservation: always on for internal ALB and EC2, default on for internet-facing ALB, optional for NLB with security groups, not for Elastic IPs or NLB without security groups.
• Shield Standard protects it automatically; Shield Advanced can be added.
• vs CloudFront: CloudFront caches HTTP content at the edge (images, video, websites, also dynamic HTTP); Global Accelerator proxies TCP/UDP to Regions (gaming, IoT/MQTT, VoIP, static IPs, fast Regional failover). vs Route 53 latency routing: DNS only, public internet path, cache-dependent failover, but cheap.
• Pricing: $0.025 per accelerator-hour plus Data Transfer-Premium per GB in the dominant direction. The API is in us-west-2.

Self-check: Global Accelerator and Anycast30 questions