AWS Global Accelerator Step by Step - Two Static Anycast IPs in Front of Load Balancers in Two Regions, Listeners, Endpoint Groups, Traffic Dials, Weights, Client IP Preservation and Pricing (Part 23)

Part-22 kept traffic inside AWS with PrivateLink. This Part-23 is about the opposite direction: users on the public internet, anywhere in the world, reaching an application that runs in more than one region - and reaching the closest healthy copy through one fixed pair of IP addresses.

I build it the way I did in the video: a VPC, a subnet, an internet gateway, an EC2 web server and an Application Load Balancer in Mumbai and the same again in Frankfurt, then one AWS Global Accelerator in front of both. The whole build is 66 minutes on camera; the post has every step, the screens that matter, and the numbers I could not fit into the video.

TL;DR

• Global Accelerator gives you two static anycast IP addresses that never change. Users connect to the nearest AWS edge location, and from there traffic rides the AWS backbone to the closest healthy endpoint. My accelerator was assigned two IPs and a DNS name within about a minute of clicking Create.
• It is Layer 4, not a CDN. It forwards TCP and UDP to Application Load Balancers, Network Load Balancers, EC2 instances or Elastic IPs in any region. It caches nothing; use CloudFront for that.
• The structure is accelerator, listener, endpoint group, endpoint. One listener on TCP port 80, one endpoint group per region (ap-south-1, eu-central-1) with a traffic dial (default 100%), and one ALB per group with a weight (default 128, range 0 to 255).
• In the demo a request from Europe came back from Frankfurt (Hostname: ip-31-0-1-23, IP Address: 31.0.1.23), exactly like a request straight to the Frankfurt ALB, while Mumbai stayed ready as the second endpoint group.
• What it costs: a fixed fee of $0.025 per hour per accelerator (about $18 a month) plus a Data Transfer-Premium of, for example, $0.015 per GB from North America to Europe or $0.035 per GB to Asia Pacific, on the dominant direction of traffic only.
• Timeouts to know: 340 seconds idle for TCP, 30 seconds for UDP. Health checks fail an endpoint over to the next healthy one for new connections; existing connections stay until the idle timeout.

Table of Content

1. What Global Accelerator does, and what it is not
2. The vocabulary - accelerator, listener, endpoint group, endpoint
3. Step 1 - A VPC, subnet, internet gateway and route table in each region
4. Step 2 - An EC2 web server per region with user data
5. Step 3 - An Application Load Balancer per region
6. Step 4 - Create the accelerator and the listener
7. Step 5 - Endpoint groups, traffic dials and endpoints
8. Step 6 - Test it - which region answers
9. Traffic dials and weights in practice
10. Global Accelerator vs Route 53 vs CloudFront
11. What it costs and the limits
12. What broke when I ran this
13. Conclusion

1. What Global Accelerator does, and what it is not

A user in Europe who opens an application hosted in Mumbai travels most of the way over the public internet, with every hop chosen by whoever runs the networks in between. Global Accelerator changes where that journey leaves the internet: the user connects to the nearest AWS edge location on one of two static anycast IP addresses, and from the edge the traffic rides the AWS global network to the region. AWS's own description is on the what is Global Accelerator page.

Three things make it different from the other two services people compare it with:

• It works at Layer 4 (TCP and UDP). It does not cache, does not terminate TLS for you and does not look at HTTP at all. A game server, a VoIP service or an API that needs a fixed IP for a customer's firewall allowlist are the typical users.
• The IP addresses are static for the life of the accelerator. DNS-based routing (Route 53) hands out different answers that clients and resolvers cache; Global Accelerator moves traffic between regions without any DNS change.
• Failover is in seconds, not TTLs. Health checks run against each endpoint; when one goes unhealthy, new connections go to the next healthy endpoint, by proximity. The how it works page adds the detail that existing connections keep flowing to the old endpoint until the idle timeout.

2. The vocabulary - accelerator, listener, endpoint group, endpoint

There are two accelerator types. Standard routes each connection to the best endpoint by proximity, health and weight - that is this post. Custom routing maps each user deterministically to one EC2 instance and port, for things like game sessions; the accelerator types page explains when you want it. Everything in a Standard accelerator is described per region on the endpoint groups page.

3. Step 1 - A VPC, subnet, internet gateway and route table in each region

Each region gets the same minimal network. I used two deliberately different CIDRs so it is obvious in every screen which region you are looking at:

In each region, in order: create the VPC with "VPC only" and its CIDR, create one public subnet, create an internet gateway and attach it to the VPC, and add a 0.0.0.0/0 route to the internet gateway in the subnet's route table. Enable auto-assign public IPv4 on the subnet so the instances get a public address. If any of that is new, Part-5 builds the same VPC in detail, and the VPC Subnet Planner gives you the CIDRs for a bigger layout.

4. Step 2 - An EC2 web server per region with user data

One Ubuntu instance per region in the public subnet, with a security group that allows port 80 from anywhere and port 22 from my IP, and this user data script so I can tell the two servers apart from a browser:

1#!/bin/bash
2yes | sudo apt update
3yes | sudo apt install apache2
4echo "<h1>Server Details</h1><p><strong>Hostname:</strong> $(hostname)</p><p><strong>IP Address:</strong> $(hostname -I | cut -d" " -f1)</p>" > /var/www/html/index.html
5sudo systemctl restart apache2

The page prints the private hostname and IP, so ip-31-0-1-23 can only come from Frankfurt and ip-21-0-1-79 only from Mumbai. Opening the instance's public IP shows the page directly, which proves the VPC and security group before any load balancer is involved. The user data script and the two-step apt install are the same pattern as Part-4, launching an EC2 instance.

5. Step 3 - An Application Load Balancer per region

Global Accelerator can point at an EC2 instance directly, but an ALB is what you want in front of a real application, so each region gets one: internet-facing, IPv4, in the VPC, with two availability zones selected (an ALB needs at least two), a security group that allows port 80, and a target group containing the region's instance.

Once the state goes from Provisioning to Active, opening the ALB DNS name in a browser returns the Server Details page from that region's instance:

Keep both ALB DNS names open in two tabs; they are your reference for the final test. The ALB itself is covered in Part-18, ALB vs NLB.

6. Step 4 - Create the accelerator and the listener

Global Accelerator is a global service: the console switches to the "Global" region, and under the hood accelerators are managed from us-west-2 (the console URL shows it). Open the service, click Create accelerator, and fill in the basic configuration:

• Name: my-first-ga
• Accelerator type: Standard
• IP address type: IPv4 (dual-stack is available if you want IPv6 too)
• IP address pool: Amazon's pool; bring-your-own-IP is possible if your customers already allowlist a range you own

Then the listener. One listener for TCP on port 80. Client affinity stays at None for a stateless web page; "Source IP" would pin a client to one endpoint.

7. Step 5 - Endpoint groups, traffic dials and endpoints

An endpoint group is one region. Add one for ap-south-1 and one for eu-central-1, each with the traffic dial at 100:

Inside each group, add the region's ALB as an endpoint. The endpoint type list shows what a Standard accelerator accepts: Application Load Balancer, Network Load Balancer, EC2 instance, Elastic IP address. Weight stays at the default 128; the console reminds you the range is 0 to 255.

Note the Preserve client IP address box, ticked by default for an internet-facing ALB. With it on, the ALB sees the user's real IP, so security groups and access logs behave as if there were no accelerator; the client IP preservation page lists which endpoint types support it and the one consequence that matters: your security groups must allow the client IPs, not an AWS range.

Click Create accelerator. Mine was listed as Enabled with two static IPs and a DNS name of the form <id>.awsglobalaccelerator.com within about a minute, with the status still "In progress" while it deployed:

8. Step 6 - Test it - which region answers

Shortly afterwards the provisioning status was Deployed. I opened the accelerator's DNS name from my laptop in Europe:

1Server Details
2Hostname: ip-31-0-1-23
3IP Address: 31.0.1.23

Frankfurt answered, through the Frankfurt ALB, chosen because it is the closest healthy endpoint group to a user in Europe. A user in India opening the same DNS name or the same static IPs would be served by Mumbai, and if the Frankfurt ALB failed its health checks, new connections from Europe would go to Mumbai with no DNS change on the client side.

To see the other region from Europe without flying to India, use the traffic dial: set the eu-central-1 dial to 0, wait a minute, reload, and the page comes from ip-21-0-1-79.

9. Traffic dials and weights in practice

The two knobs look similar and work at different levels:

The dial only applies to traffic that proximity already sent to that region; it is not a global split. The traffic dial documentation gives the example of two regions both at 50%: a user near region A has a 50% chance of staying in A and otherwise goes to the next closest healthy region. Changing a dial affects only new connections; existing ones are not cut.

Weights are documented on the endpoint weights page. Two endpoints with weights 128 and 64 get two-thirds and one-third of the group's new connections; a weight of 0 drains an endpoint. The docs also note that Global Accelerator can override weights in rare cases to keep clients connected, for example when client IP preservation would otherwise cause a connection collision.

10. Global Accelerator vs Route 53 vs CloudFront

You can combine them: CloudFront for the website, Global Accelerator for the API or the WebSocket or UDP traffic, Route 53 to give both a friendly name. Route 53 routing policies are in Part-15.

11. What it costs and the limits

From the Global Accelerator pricing page:

AWS's own worked example on that page: 10,000 GB a month with 60% outbound is billed on 6,000 GB, costing $110 of DT-Premium plus the $18 fixed fee. For my demo the fixed fee was the whole bill; the two t2.micro instances and two ALBs cost more than the accelerator did, which is why I deleted everything right after recording.

Limits worth knowing from the docs: the TCP idle timeout is 340 seconds and UDP 30 seconds; a connection that sends nothing for longer is dropped, and TCP keep-alive packets do not count, at least one byte of data must flow. A disabled accelerator still costs the fixed fee; delete it to stop paying.

12. What broke when I ran this

Three things from the recording, made on 2025-02-26 and reviewed frame by frame on 2026-10-15.

1. I ended up running the "user data" by hand. On camera the Server Details script lives in a scratch file next to my resource names, and on both instances I ran it over SSH as root (sudo su, the echo ... > /var/www/html/index.html line, systemctl restart apache2) after the apt install finished, rather than relying on the boot-time user data. It works either way, but if you paste the script into the EC2 user data field, verify it with the instance's public IP before you build the load balancer: a quoting mistake in that long echo line is the usual reason the page shows the Ubuntu default instead.

2. Everything spends time in a waiting state. The Mumbai ALB sat in Provisioning with its DNS name already visible, and the accelerator showed In progress with its two IPs already listed. Opening either DNS name during that window gives a connection error that looks like a configuration mistake. Wait for Active on the ALB and Deployed on the accelerator; in the recording the accelerator reached Deployed well under 5 minutes after creation.

3. "Global" is really us-west-2. The console switched itself to the Global region, but the address bar showed us-west-2.console.aws.amazon.com, and the create page states that you must be in US West (Oregon) to create or update accelerators. The same applies to the CLI and Terraform: run aws globalaccelerator commands with --region us-west-2, whatever region your endpoints are in.

13. Conclusion

To summarise Part-23:

1. Global Accelerator puts two static anycast IPs in front of endpoints in any number of regions and routes each connection to the closest healthy one over the AWS network.
2. Build it as accelerator, listener (TCP 80), one endpoint group per region with a traffic dial, and an ALB per group with a weight.
3. A request from Europe was answered by Frankfurt (ip-31-0-1-23); the dial and the weights let you move that traffic without touching DNS.
4. It costs $0.025 per hour plus a per-GB premium on the dominant direction, and it is a Layer 4 service: pair it with CloudFront for websites, not instead of it.

Next, Part-24 covers AWS Control Tower, and the rest of the series is in the index below.

AWS step by step series -

1. Part-1 : AWS IAM user - create a user, group, policy, access keys and MFA
2. Part-2 : AWS Organizations - multi-account setup, OUs and SCPs
3. Part-3 : AWS assume IAM role - trust policy, switch role in console and CLI
4. Part-4 : How to launch an EC2 instance - key pair, security group, SSH
5. Part-5 : AWS VPC - public and private subnets, Internet Gateway, NAT Gateway, route tables
6. Part-8 : EC2 launch template - versions, default version, source template, SSM parameter AMI
7. Part-10 : EC2 Auto Scaling - launch template, Auto Scaling group, target tracking, ALB
8. Part-11 : AWS WAF - web ACL, managed rules, rate limiting, geo blocking
9. Part-12 : AWS VPC Peering - connect two VPCs, routes, security groups, DNS
10. Part-13 : AWS Transit Gateway - hub-and-spoke for many VPCs and on-premises
11. Part-14 : AWS NAT Gateway deep dive - public vs private, limits, cost, troubleshooting
12. Part-15 : Amazon Route 53 - hosted zones, records, alias, routing policies, health checks
13. Part-16 : AWS security groups - inbound and outbound rules, stateful, referencing, quotas
14. Part-16 : AWS Certificate Manager - free TLS certificates for ALB, CloudFront and API Gateway
15. Part-17 : AWS Lambda - function URLs, environment variables and layers
16. Part-18 : Network Load Balancer - setup, and ALB vs NLB
17. Part-19 : VPC endpoints - gateway and interface endpoints (PrivateLink) instead of NAT
18. Part-20 : AWS PrivateLink - publish your own service with an endpoint service and NLB
19. Part-20 : Amazon EBS volumes - types, attach, mount, resize, snapshots, encryption
20. Part-21 : VPC Flow Logs - CloudWatch Logs, S3, record format, Logs Insights, Athena
21. Part-21 : EC2 Spot Instances - pricing, interruptions, mixed instances groups
22. Part-23 : AWS Global Accelerator - static anycast IPs in front of ALBs in two regions, traffic dials, weights
23. Part-24 : AWS Control Tower - landing zone, controls, Account Factory, Identity Center

Networking fundamentals -

1. What is a VPC and a subnet? AWS networking in five minutes
2. What is CIDR? Calculate IP ranges for VPCs and subnets
3. What is NAT? Static NAT, dynamic NAT and PAT explained

More AWS guides -

1. What is AWS CloudFormation? Templates, stacks, change sets, drift, StackSets
2. Learn AWS S3 - the complete course
3. AWS API Gateway - REST API with Lambda, authorizers, Terraform
4. AWS Advanced Networking Specialty (ANS-C01) - course companion
5. AWS ECS and Fargate - how to deploy a Docker container
6. AWS S3 - how to host a static website
7. Terraform create EC2 instance on AWS
8. Terraform AWS IAM - users, roles and policies
9. Terraform and AWS multi-account setup
10. Terraform - setting up an ALB and SSL