What Is AWS Global Accelerator? Pricing, Static IPs, Speed Test, Setup With ALB, vs CloudFront and Route 53, and Failover

AWS Global Accelerator gives your application two static anycast IP addresses that never change and that users everywhere reach through the nearest AWS edge location, after which their traffic travels on the AWS global network instead of the public internet to your load balancers or instances in one or more Regions. It works for any TCP or UDP traffic (APIs, games, VoIP, IoT, payment terminals), fails over between Regions in seconds without waiting for DNS, and lets you shift traffic with traffic dials. It costs a fixed $0.025 per accelerator-hour (about $18 a month), even when disabled, plus a Data Transfer Premium of $0.015 to $0.105 per GB on the dominant direction of your traffic, on top of normal data transfer out, plus the public IPv4 charge for its addresses (about $7.20 a month for the two). It is not a cache: for websites and downloads, CloudFront is usually the better and cheaper tool. Use Global Accelerator when you need fixed IPs, non-HTTP traffic or instant multi-Region failover, and check the gain first with the speed comparison tool. Below: what Global Accelerator is and how it works, standard vs custom routing, every price with worked examples, a step-by-step setup with an ALB, Global Accelerator vs CloudFront, Route 53 and NLB, failover and traffic dials, limits, and fixes.

The furniture store's payment provider sent a change notice: from next month, it would accept calls only from IP addresses on an allow-list, and the store's checkout API sat behind an Application Load Balancer whose IP addresses change whenever AWS scales it. At the same time, the owner wanted the API to keep working if a whole AWS Region had a bad day, because the new showroom in Montreal took card payments through the same API. Jake suggested writing the current IP addresses down and hoping. Ethan said hope is not a networking strategy, and opened AWS Global Accelerator.

New to AWS networking? The cards below cover CloudFront, Route 53, ALB vs NLB, data transfer costs and idle resource charges, the pieces you will compare Global Accelerator with.

What is AWS Global Accelerator?

When a user in Toronto calls an API hosted in Virginia, their packets normally cross the public internet: a dozen or more networks owned by different companies, each choosing its own route, with congestion and packet loss along the way. The further the user, the worse it gets, and DNS-based failover between Regions is slow because resolvers and clients cache the old answer.

AWS Global Accelerator changes the path. You get two static IPv4 addresses (and optionally two IPv6 addresses), announced from AWS edge locations around the world using anycast, so the same IP address is reachable at every edge location and each user's traffic enters AWS at the one nearest to them. From there it rides the AWS global network, private fiber AWS operates between its Regions and edge locations, to your application's endpoints: Application Load Balancers, Network Load Balancers, EC2 instances or Elastic IP addresses, in one Region or many.

What you get from that:

• Static IP addresses that never change for the life of the accelerator, for allow-lists, firewall rules, IoT devices and DNS-free clients, even when the load balancers behind them change.
• Better performance for distant users: fewer hops on the public internet, more consistent latency and less jitter. AWS's own speed comparison tool shows the difference from your location.
• Fast regional failover: health checks detect an unhealthy endpoint or Region and traffic moves to healthy ones within seconds, with no DNS change for clients to miss.
• Traffic control: traffic dials per Region and weights per endpoint, for blue/green deployments and gradual migrations.
• DDoS protection: the edge locations are protected by AWS Shield Standard, and attack traffic is absorbed at the edge.
• Client IP preservation for ALB and EC2 endpoints, so your application still sees the user's real address.

Jake: "So it's two phone numbers that always reach the store, whichever branch picks up."

Ethan: "And the call travels on our own private line for most of the way, instead of hopping between other people's networks."

Global Accelerator explained simply: think of your application as a shop with branches in two cities, and the internet as a road network. Without Global Accelerator, every customer drives the whole way on public roads to whichever branch their map app picked, through every traffic jam on the way. With it, the shop has two well-known phone numbers and a private express highway: customers join the highway at the on-ramp nearest their home, ride it to the closest open branch, and if one branch closes, the highway quietly sends them to the other. The phone numbers never change, so suppliers and partners can rely on them.

What "anycast" means: normally one IP address belongs to one place. With anycast, AWS announces the same IP addresses from every edge location at once, and the internet's routing naturally delivers each user's packets to the nearest one. That is how one fixed address can be "local" to users on every continent.

How Global Accelerator works

1. You create an accelerator and get two static anycast IP addresses (or bring your own address range with BYOIP), plus a DNS name such as a1234567890abcdef.awsglobalaccelerator.com.
2. You add a listener for the protocol (TCP or UDP) and port ranges your clients use, for example TCP 443.
3. You add endpoint groups, one per AWS Region you serve from, each with a traffic dial (the percentage of that Region's share of traffic to accept) and health check settings.
4. You add endpoints to each group: ALBs, NLBs, EC2 instances or Elastic IPs, each with a weight.
5. A user connects to one of the static IPs; anycast brings the packets to the nearest edge location.
6. The edge location forwards the traffic over the AWS network to the closest healthy endpoint group, adjusted by traffic dials, and to an endpoint by weight; with client affinity on, a given user keeps reaching the same endpoint.
7. Responses return the same way, through the edge location, to the user.

Both static IPs serve the same accelerator from independent network zones, so clients and partners should allow-list and use both; if one address becomes unreachable on a network, the other still works.

Standard accelerators vs custom routing accelerators

• Standard accelerators (most uses) choose the best endpoint for each user automatically, based on proximity, health, traffic dials and weights. Endpoints are ALBs, NLBs, EC2 instances and Elastic IPs. Use them for APIs, websites behind ALBs, game lobbies, and any app where any healthy endpoint can serve any user.
• Custom routing accelerators let your application decide: they map ranges of the accelerator's ports to specific EC2 instances and ports in VPC subnets, so your matchmaking service can send two players to exactly the same game server, or a VoIP service can pin a call to a media server. Endpoints are VPC subnets, and your app looks up the port mapping to tell each client where to connect.

Both cost the same fixed hourly fee and DT-Premium. Custom routing is a niche tool; if you are not building multiplayer games, real-time media or similar session-pinned systems, you want a standard accelerator.

Global Accelerator speed test: how much faster is it?

The honest answer is "it depends on where your users are", and AWS gives you a way to see it. The Global Accelerator speed comparison tool, a public web page AWS runs, downloads test files from several AWS Regions twice from your browser, once directly over the internet and once through Global Accelerator, and shows the percentage difference for each Region. Users far from a Region, or on congested networks, typically see the largest gains; users in the same metro area as the Region often see little or none.

For your own application, measure before and after with real requests from the places your users are:

# Run from machines in each user location: compare the direct ALB name with the accelerator name
curl -o /dev/null -s -w "connect %{time_connect}s  tls %{time_appconnect}s  first byte %{time_starttransfer}s  total %{time_total}s\n" \
  https://checkout-alb-123456.us-east-1.elb.amazonaws.com/health

curl -o /dev/null -s -w "connect %{time_connect}s  tls %{time_appconnect}s  first byte %{time_starttransfer}s  total %{time_total}s\n" \
  https://a1234567890abcdef.awsglobalaccelerator.com/health

Run each test many times and compare medians and the slowest 5 percent, not single results: the biggest benefit of the AWS network is often consistency, fewer slow outliers, rather than a lower average. For TCP traffic, the connection handshake completes at the nearby edge location, which noticeably shortens connection setup for distant users, and long transfers avoid the packet loss that slows TCP down on long public-internet routes. Real-user monitoring (timings reported from your app's actual users) is the final word.

The store tested from Montreal, Chicago and a cloud VM in Europe: Montreal's connection setup fell by about a third, Chicago saw almost no change (it is close to Virginia), and Europe improved the most. For the store, the static IPs and the failover were the reason to buy; the speed was a bonus.

What Global Accelerator is used for

• Static IPs for allow-lists: partners, banks, payment providers and corporate firewalls that only accept fixed addresses, in front of ALBs whose IPs change.
• Multi-Region active-active or active-passive apps: one global entry point with automatic failover between Regions.
• Gaming: lower, steadier latency for players far from the game servers, over UDP or TCP.
• VoIP, video and real-time media: less jitter and packet loss on long routes.
• IoT and embedded devices with IP addresses burned into firmware or limited DNS support.
• APIs used from other continents, where the public-internet path adds tens of milliseconds and occasional loss.
• Blue/green and migrations, moving traffic between Regions or stacks gradually with traffic dials and weights.

AWS Global Accelerator pricing

• Fixed fee: $0.025 for every full or partial hour an accelerator exists, enabled or disabled, until you delete it: about $18 a month per accelerator.
• Data Transfer Premium (DT-Premium): a per-GB charge on traffic through the accelerator, calculated every hour on the dominant direction only (inbound or outbound, whichever is larger), and priced by the source Region and the destination edge location.
• Normal data transfer: DT-Premium comes in addition to the usual EC2 or load balancer data transfer out charges.
• Public IPv4 addresses: the accelerator's static IPv4 addresses are billed like other public IPv4 addresses, $0.005 per address per hour, about $7.20 a month for the two (IPv6 addresses are not charged; BYOIP addresses follow BYOIP rules).

DT-Premium rates from a source Region in the United States or Canada, by the destination edge location:

Destination edge location	DT-Premium per GB
United States, Mexico, Canada	$0.015
Europe, Israel and Türkiye	$0.015
Asia Pacific, South Korea, India, Philippines, Thailand, Vietnam	$0.035
Middle East	$0.035
South America	$0.040
South Africa, Kenya and Nigeria	$0.079
Australia and New Zealand	$0.105

Rates from other source Regions differ (traffic from Asia Pacific or South America Regions generally costs more), so check the table for your Regions. There is no free tier for Global Accelerator; accounts created from July 15, 2025 can use Free Tier credits.

Worked examples: what Global Accelerator really costs

Months are 720 hours. Normal data transfer out is shown separately at $0.09 per GB for the first 10 TB from a US Region.

Example 1: the store's checkout API. One accelerator in front of ALBs in two US Regions, 500 GB a month of mostly outbound traffic to users in North America: fixed fee $18 + DT-Premium 500 x $0.015 = $7.50 + two IPv4 addresses $7.20 = $32.70 a month, plus the $45 of normal data transfer out the store already paid without the accelerator.

Ethan: "Thirty-three dollars a month for two IP addresses the payment provider can allow-list forever, and failover between Regions."

Jake: "Cheaper than the phone call when the payments stop."

Example 2: a global API. 10,000 GB a month in total, 60 percent outbound to users, so 6,000 GB is billed: 5,000 GB to Europe at $0.015 ($75) and 1,000 GB to Asia Pacific at $0.035 ($35). DT-Premium $110 + fixed fee $18 = $128 a month, plus $7.20 for IPv4 and normal data transfer out.

Example 3: a game with players everywhere. 10 TB a month outbound from a US Region: 4 TB to North America ($60), 3 TB to Europe ($45), 2 TB to Asia Pacific ($70) and 1 TB to Australia ($105). DT-Premium $280 + $18 + $7.20 = $305.20 a month before normal data transfer, for noticeably lower and steadier latency for distant players.

Example 4: the forgotten test accelerator. Disabled, not deleted: $18 + $7.20 = $25.20 a month for nothing, every month. Our standing waste list covers this and its relatives; a billing alert catches it early.

Example 5: when CloudFront is cheaper. A website serving 10 TB of images and pages a month gets better performance from CloudFront caching (most requests never reach the origin) at CloudFront's own per-GB rates, which are usually lower than standard data transfer out plus DT-Premium. Global Accelerator wins only when the traffic cannot be cached or is not HTTP.

Set up Global Accelerator with an Application Load Balancer

1. Have your endpoints ready: an ALB (or NLB, EC2 instance or Elastic IP) in each Region you will serve from, with the same application deployed.
2. Open Global Accelerator in the console (it is a global service; the console works from any Region) and choose Create accelerator.
3. Name it and choose Standard. Choose IPv4 or Dual-stack (IPv4 and IPv6) for the IP address type, or bring your own IP range.
4. Add a listener: protocol TCP, port 443 (add 80 if you redirect HTTP), and client affinity None (or Source IP if users must stick to one endpoint).
5. Add endpoint groups: one for each Region, with a traffic dial of 100 percent for active Regions (or 0 for a standby Region), and health checks on the path and port your app exposes.
6. Add endpoints: choose the ALB in each Region, set weights (128 is the default), and turn on client IP address preservation so your app sees users' real IPs.
7. Create the accelerator. After a few minutes it is Deployed; note the two static IPs and the DNS name.
8. Point your traffic at it: create a Route 53 alias record (or a CNAME elsewhere) from api.example.com to the accelerator's DNS name, and give partners the two static IPs to allow-list.
9. Update security groups: with client IP preservation, your ALB's security group sees users' addresses, so keep allowing the client ranges you expect.

# Global Accelerator API calls go to US West (Oregon), whatever Region your endpoints are in
aws globalaccelerator create-accelerator --name store-checkout --ip-address-type IPV4 --region us-west-2

aws globalaccelerator create-listener --region us-west-2 \
  --accelerator-arn arn:aws:globalaccelerator::111122223333:accelerator/1234abcd-abcd-1234-abcd-1234abcdefgh \
  --protocol TCP --port-ranges FromPort=443,ToPort=443 --client-affinity NONE

aws globalaccelerator create-endpoint-group --region us-west-2 \
  --listener-arn arn:aws:globalaccelerator::111122223333:accelerator/1234abcd-abcd-1234-abcd-1234abcdefgh/listener/0123vxyz \
  --endpoint-group-region us-east-1 --traffic-dial-percentage 100 \
  --health-check-path /health --health-check-protocol HTTPS \
  --endpoint-configurations EndpointId=arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/checkout/abc123,Weight=128,ClientIPPreservationEnabled=true

A common surprise is the Region: all Global Accelerator API operations run in US West (Oregon), so scripts and CLI calls need --region us-west-2 even when every endpoint is in Virginia, and service quota increases are requested from US East (N. Virginia).

Global Accelerator with ALB, NLB and EC2 endpoints

• Application Load Balancer endpoints are the most common choice for HTTP APIs and websites: the ALB keeps doing TLS termination, routing rules, WAF and target health, and Global Accelerator adds static IPs, edge entry and multi-Region failover in front of it. Internal ALBs work too, so your ALB does not need to face the internet at all. Turn on client IP preservation so the ALB and your logs see users' real addresses.
• Network Load Balancer endpoints suit TCP and UDP services that need very high throughput or non-HTTP protocols. Since an NLB can already have static IPs in one Region, Global Accelerator adds value mainly for multi-Region routing, acceleration and failover. Client IP preservation behavior depends on the NLB's target type and settings.
• EC2 instance and Elastic IP endpoints fit small deployments, game servers and appliances; Global Accelerator health-checks them itself using the settings on the endpoint group.
• Global Accelerator vs a load balancer: they are not alternatives. A load balancer spreads traffic across targets inside one Region; Global Accelerator chooses the Region and gives the whole thing a global front door. Most production setups use both.

Cross-account endpoints: with cross-account attachments, an accelerator in a networking account can route to ALBs and NLBs owned by application accounts, which suits organizations that run a central edge.

Moving an existing app behind Global Accelerator without downtime

1. Create the accelerator with your existing ALB or NLB as the endpoint, alongside your current setup; nothing changes for users yet.
2. Test through the accelerator using its DNS name or static IPs, including TLS (your certificate must cover the hostname clients use, which stays your own domain).
3. Check security groups and logs: with client IP preservation on, confirm your app and firewall rules see and accept user IPs.
4. Lower the TTL on your DNS record a day ahead, then switch it to an alias (or CNAME) for the accelerator.
5. Watch both paths while caches expire; traffic shifts gradually to the accelerator.
6. Give partners the static IPs only after the switch is stable, and keep the old allow-list entries until they confirm.
7. Add the second Region as a new endpoint group at traffic dial 0, then test failover in a maintenance window.

Bring your own IP (BYOIP): if customers already allow-list a range you own, you can provision that IPv4 range (a /24 or larger) to Global Accelerator after proving ownership with a route origin authorization, then advertise it from AWS edge locations. The migration then becomes invisible to those customers: the same addresses, a new network behind them. BYOIP takes a few days of preparation with your regional internet registry, so start early.

Custom routing for games and real-time media, step by step

1. Create a custom routing accelerator and a listener with a port range large enough for all your sessions (for example 10,000 to 20,000).
2. Add endpoint groups per Region with destination port ranges and protocols your game servers use (for example UDP 7777 to 7800).
3. Add VPC subnets as endpoints; Global Accelerator builds a static mapping from accelerator ports to each instance IP and port in those subnets.
4. Allow traffic to specific destinations (or all of them) in the subnet; by default, custom routing denies all until you allow.
5. In your matchmaking service, call the API to look up which accelerator IP and port maps to the chosen game server, and send that to the players' clients.

Every player in a match then connects to the same server through their nearest edge location, with the network path between edge and server on AWS's backbone. That is something a standard accelerator, which chooses endpoints for you, cannot guarantee.

Failover, traffic dials, weights and client affinity

• Health checks: Global Accelerator checks each endpoint (for ALB and NLB endpoints, it uses the load balancer's own health) and stops sending traffic to unhealthy ones; if a whole endpoint group fails, traffic shifts to the next-closest healthy Region, usually within seconds to under a minute, without any DNS change.
• Traffic dials (0 to 100 percent per endpoint group) control how much of the traffic that would go to a Region actually goes there. Set a standby Region to 0 for active-passive, or turn a Region down to 10 percent to test a new deployment.
• Endpoint weights (0 to 255) split traffic between endpoints in the same Region, for example 90 percent to the current stack and 10 percent to the new one.
• Client affinity: None spreads connections freely; Source IP sends each client IP to the same endpoint, for stateful apps that cannot share sessions.
• Testing failover: set a Region's traffic dial to 0 during a maintenance window and watch traffic move, before you rely on it in an incident.

The store runs its checkout API in US East (N. Virginia) at 100 percent and US East (Ohio) at 0 percent as a warm standby. When an ALB health check failed during a deployment mistake, traffic moved to Ohio in under a minute, and the Montreal showroom's card machines never noticed.

Multi-Region apps: what Global Accelerator does not solve

Global Accelerator moves users between Regions in seconds, but it does not move your data. If both Regions must serve every request, each needs a current copy of the data, and that is a database decision:

• Aurora Global Database replicates a primary Region to up to several secondary Regions with typically under a second of lag; secondaries serve reads, and a managed failover promotes a secondary to take writes. Pair it with a Global Accelerator traffic dial so writes go to the primary Region.
• DynamoDB global tables replicate tables across Regions with active-active writes, which fits an active-active Global Accelerator setup.
• S3 Cross-Region Replication keeps object copies in each Region.
• Stateless app tiers (containers or Lambda behind ALBs) deploy to both Regions from the same pipeline.

The common pattern is active-passive: the primary Region at traffic dial 100, a warm standby at 0 with read replicas and scaled-down compute, and a runbook (or automation) that promotes the database and raises the standby's dial during a regional incident. Active-active needs a data layer that accepts writes in both Regions, and careful thought about conflicts.

WorkSpaces, Site-to-Site VPN and S3 use the same network

• Amazon WorkSpaces: WorkSpaces Personal on the DCV protocol can send its streaming traffic through Global Accelerator, so remote users far from the WorkSpaces Region get a steadier desktop. It is turned on per directory or per WorkSpace, at no extra charge up to an outbound data allowance per bundle, needs a recent WorkSpaces client, and cannot be used where FIPS or IP access control groups are enabled.
• Accelerated Site-to-Site VPN: VPN connections to a transit gateway can enter AWS at the nearest edge location instead of crossing the internet to the Region, using Global Accelerator's network for more stable tunnels from distant offices.
• S3 Multi-Region Access Points: give one global endpoint for buckets in several Regions and route requests over the AWS global network to the closest bucket; you do not put S3 behind an accelerator yourself.

Outages and status: Global Accelerator runs from many edge locations with two independent static IPs, which is why clients should use both. If you suspect a problem, check the AWS Health Dashboard for Global Accelerator and your endpoint Regions, look at endpoint group health in the console, and test both IPs directly; most "accelerator is down" reports turn out to be unhealthy endpoints or security groups behind it.

Global Accelerator vs CloudFront, Route 53, NLB and Direct Connect

	Global Accelerator	CloudFront	Route 53 latency or failover routing
What it does	Routes TCP/UDP over the AWS network to the best endpoint	Caches and serves HTTP(S) content at the edge	Answers DNS queries with the best Region's address
Protocols	Any TCP or UDP	HTTP and HTTPS (plus WebSocket)	Any (it is only DNS)
Static IPs	Yes, two anycast IPs	No (anycast static IPs only on special plans)	No
Caching	None	Yes	None
Failover speed	Seconds, no DNS involved	Origin failover per request	Depends on DNS TTLs and client caching
Price model	$18/month + DT-Premium + normal data transfer	Per GB and per request (or flat-rate plans)	Per hosted zone and per query
Best for	APIs, games, VoIP, IoT, allow-lists, multi-Region failover	Websites, media, downloads, cacheable APIs	Simple multi-Region routing on a budget

• Global Accelerator vs CloudFront: if your traffic is HTTP and much of it can be cached, CloudFront is faster and cheaper. If it is non-HTTP, uncacheable, needs static IPs, or needs instant cross-Region failover, use Global Accelerator. Many sites use CloudFront for the website and Global Accelerator for the API or game traffic.
• Global Accelerator vs Route 53: Route 53 latency-based routing also sends users to a nearby Region, but traffic still crosses the public internet, and failover waits for DNS caches to expire, which some clients ignore for hours. Global Accelerator changes nothing in DNS and fails over at the network layer. Route 53 is cheaper and enough for many apps.
• Global Accelerator vs a Network Load Balancer with Elastic IPs: an NLB can also have static IPs, but only in one Region, with no global routing or acceleration. See our ALB vs NLB guide for static IPs in a single Region.
• Global Accelerator vs Direct Connect: Direct Connect is a private line from your own offices or data centers into AWS; Global Accelerator speeds up internet users reaching your application.
• Global Accelerator vs Azure Front Door and Cloudflare: Azure Front Door is Microsoft's global HTTP entry point, combining a CDN, routing and a web application firewall, closer to CloudFront plus routing than to Global Accelerator; Azure's cross-region load balancer is the nearer match for anycast layer-4 routing. Cloudflare's network offers anycast proxying, caching and its Spectrum product for TCP and UDP. On AWS, Global Accelerator integrates natively with ALBs, NLBs, health checks and IAM, and keeps traffic on AWS's network to your Regions.

Using CloudFront and Global Accelerator together: a common design puts the website and static assets behind CloudFront (cached at the edge, cheap per GB) and the dynamic API, WebSocket, game or device traffic behind Global Accelerator (static IPs, fast failover). Each does the job it is best at, and users never see the difference.

Security, IP addresses and monitoring

• DDoS: edge locations are protected by AWS Shield Standard at no charge, and Shield Advanced can protect accelerators too. Put AWS WAF on the ALB endpoints to filter HTTP attacks (see our WAF guide).
• Private backends: endpoints can be internal ALBs and EC2 instances in private subnets; Global Accelerator reaches them through the AWS network, so they need no public IPs of their own.
• Dual-stack: choose dual-stack to get two IPv6 addresses alongside the IPv4 pair, for IPv6-only clients and networks.
• Bring your own IP (BYOIP): use your own IPv4 address range with Global Accelerator, so your customers' existing allow-lists keep working when you move to AWS.
• Flow logs: turn on flow logs (per accelerator, delivered to an S3 bucket and prefix you choose) to record each flow's client IP and port, the accelerator IP and port, the endpoint, protocol, packets and bytes, and whether it was accepted. Query them with Athena to answer "who is connecting from where" or to investigate unusual traffic; you pay only the S3 storage for the log files.
• CloudWatch metrics: NewFlowCount, ProcessedBytesIn and ProcessedBytesOut per accelerator, listener and endpoint group, plus endpoint health; alarm on unhealthy endpoint groups.

Global Accelerator limits and quotas

• Accelerators: 20 standard and 10 custom routing accelerators per account by default (adjustable).
• Listeners: 10 per accelerator (adjustable), each with up to 10 port ranges.
• Endpoint groups: up to 42 per accelerator across all listeners (listeners x endpoint groups cannot exceed 42).
• Endpoints: 10 per endpoint group by default for each endpoint type.
• Port overrides: 10 per endpoint group.
• Management: API calls in US West (Oregon); quota requests in US East (N. Virginia).
• Cross-account attachments: up to 10 principals and 500 resources per attachment.

These limits rarely bind for a single application: one accelerator with one or two listeners and an endpoint group per Region covers most designs. Organizations with many applications either use several accelerators (one per application, for clean ownership and cost tracking) or request higher accelerator quotas.

Common problems and fixes

• Charges after disabling: a disabled accelerator still costs $0.025 an hour plus its IPv4 addresses; delete it (disable first, then delete) to stop paying.
• "Could not connect to the endpoint URL" or calls fail from scripts: the CLI or SDK is pointed at another Region; use us-west-2 for every Global Accelerator API call.
• Traffic not reaching endpoints: the endpoint's security group does not allow the client traffic (with client IP preservation, it sees user IPs, not Global Accelerator's), the ALB or NLB is unhealthy, or the traffic dial is 0.
• Endpoint group shows unhealthy: the health check path, port or protocol is wrong for EC2 or Elastic IP endpoints, or the ALB's own target health checks are failing.
• Users stuck on one Region after recovery: long-lived TCP connections stay where they started; new connections follow the current routing. Client affinity also keeps a source IP on the same endpoint.
• No speed improvement: users close to the Region already have a short path; the benefit grows with distance and network quality. Measure with your real users and the AWS speed comparison tool before you commit.
• Bill higher than expected: DT-Premium applies on top of normal data transfer out; heavy traffic to Australia, Africa or South America costs the most. Put cacheable content behind CloudFront instead.

Best practices

• Allow-list both static IPs everywhere you use them, never just one.
• Use a Route 53 alias to the accelerator's DNS name for your own domain, so you keep a friendly name and the static IPs.
• Keep a standby Region warm and test failover with traffic dials regularly.
• Turn on client IP preservation for ALB and EC2 endpoints, and update security groups accordingly.
• Combine with CloudFront: cacheable content through CloudFront, dynamic API or non-HTTP traffic through Global Accelerator.
• Delete accelerators you no longer use, and tag the rest with an owner.
• Script with us-west-2 as the API Region in your infrastructure as code.

Keeping the bill small: the fixed fee is modest, so the levers are mostly about data. Route only the traffic that benefits (APIs, games, devices) through the accelerator and leave cacheable assets on CloudFront; watch the DT-Premium line by destination in Cost Explorer, since Australia, New Zealand, Africa and South America cost several times North America and Europe; use one accelerator per application rather than one per environment, and delete test accelerators the day the test ends; and consider whether nearby users need the accelerator at all, since a Region close to them may see no benefit while you still pay the premium on their traffic.

Finally, document the two IPs, the DNS name, the traffic dial settings and the failover runbook in one place. During an incident, nobody should be guessing which Region is the standby or how to move traffic to it.

Frequently asked questions

The payment provider allow-listed the two static IPs in an afternoon, and they have not changed since. The checkout API now runs active in Virginia with a warm standby in Ohio, and the one real failover, after a bad deployment, took under a minute. The Montreal showroom's card terminals connect through the nearest edge location in Canada, and payments feel a little snappier. The bill is about $33 a month on top of normal data transfer. Jake asked whether the static IPs could ever change. "Only if we delete the accelerator," Ethan said, "and the billing alert is set so that nobody does it by accident."

Revision note. Written October 21, 2026. Prices are list prices on that date. We will update this page when Global Accelerator prices or features change.