What is AWS Global Accelerator? Routing, Anycast, and multi-region failover explained

What is AWS Global Accelerator?

AWS Global Accelerator is a networking service that routes your application traffic through AWS's private global network instead of the public internet. It provides two static Anycast IPv4 addresses — or optionally a dual-stack IPv6 address — that serve as a fixed entry point for your application globally, regardless of which AWS region your backend actually runs in.

The key distinction from CloudFront is often misunderstood. CloudFront caches content at edge locations — it is a CDN for static assets, APIs, and dynamic web content. Global Accelerator doesn't cache anything. Its job is purely routing: get traffic off the public internet and onto AWS's backbone as early as possible, then carry it to your backend over AWS-managed infrastructure with better performance characteristics than the open internet.

If your users are close to your AWS region, Global Accelerator will do almost nothing for you. If your users are intercontinental — Asia-Pacific users hitting a us-east-1 backend, for example — the improvement can be substantial.

How Global Accelerator works

The mechanism is straightforward:

1. A client does a DNS lookup for your application. The DNS name resolves to two static Anycast IPv4 addresses announced from all AWS edge Points of Presence (PoPs) globally.
2. The client connects to the nearest AWS edge PoP. Because the IPs are Anycast, BGP routing delivers the connection to whichever PoP is closest to the client.
3. From that edge PoP, traffic travels over AWS's private backbone to your endpoint region — not the public internet.
4. Traffic reaches your Application Load Balancer, Network Load Balancer, EC2 instance, or Elastic IP in the target region.

The public internet leg — client to AWS edge — is as short as possible. The rest of the path is AWS-controlled infrastructure with dedicated capacity and no congestion from public internet traffic.

Typical latency improvement for intercontinental traffic: 20–60%. For users in the same region as your backend, improvement is negligible.

Components

Accelerator — the top-level resource. It gets two static Anycast IPv4 addresses and optionally an IPv6 address. These IPs don't change regardless of failovers or region shifts, which is the point.

Listener — defines the protocol (TCP or UDP) and port range(s). One accelerator can have multiple listeners. For a web app, you'd typically have one listener on TCP/443.

Endpoint group — one per AWS region you want to serve. Contains endpoints in that region and has a traffic dial setting (0–100%) that controls what percentage of traffic this region receives. This is your primary tool for weighted routing and traffic shifting.

Endpoint — the actual backend resource: an ALB, NLB, EC2 instance, or Elastic IP. Each endpoint has a weight (0–255) for traffic distribution within its endpoint group. Health checks run against each endpoint independently.

When Global Accelerator helps — and when it doesn't

Strong use cases:

• Users geographically far from your AWS region. A user in Tokyo hitting a us-east-1 backend traverses a lot of unpredictable public internet. Global Accelerator eliminates most of that variability.
• Latency-sensitive applications: online gaming, real-time communication, financial trading systems where a 50ms improvement matters.
• Multi-region active-active or active-passive failover without DNS TTL delays. Because the Anycast IPs are static, failover doesn't involve DNS changes.
• Static IP requirements. If your clients use IP whitelisting on their corporate firewalls, you can give them two IPs and they never change.

Weak use cases:

• Users close to your AWS region. If most of your users are in us-east-1 and your app runs in us-east-1, the routing optimization has nothing to work with.
• Applications well-served by CloudFront. If you're serving cacheable content or standard HTTPS APIs, CloudFront's edge caching will have a bigger impact at lower cost.
• Internal applications. VPC endpoints, PrivateLink, or Transit Gateway are the right tools for traffic that stays inside AWS.

Setting up Global Accelerator with the AWS CLI

Global Accelerator is a global service but the API endpoint is always us-east-1. Every CLI command needs --region us-east-1.

# Create accelerator
aws globalaccelerator create-accelerator \
  --name prod-accelerator \
  --ip-address-type IPV4 \
  --enabled \
  --region us-east-1

# Note the AcceleratorArn from the output, you'll need it for all subsequent calls

# Create a TCP listener on port 443
aws globalaccelerator create-listener \
  --accelerator-arn arn:aws:globalaccelerator::123456789012:accelerator/abcd1234-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --protocol TCP \
  --port-ranges FromPort=443,ToPort=443 \
  --region us-east-1

# Create endpoint group for us-east-1 with an ALB as the endpoint
aws globalaccelerator create-endpoint-group \
  --listener-arn arn:aws:globalaccelerator::123456789012:accelerator/abcd1234/listener/efgh5678 \
  --endpoint-group-region us-east-1 \
  --traffic-dial-percentage 100 \
  --endpoint-configurations \
    EndpointId=arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/prod-alb/xxxx,Weight=128 \
  --region us-east-1

# Check accelerator status (wait for DEPLOYED)
aws globalaccelerator describe-accelerator \
  --accelerator-arn arn:aws:globalaccelerator::123456789012:accelerator/abcd1234-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --region us-east-1 \
  --query 'Accelerator.Status'

Provisioning takes 2–5 minutes. Once status is DEPLOYED, the static IPs are active.

Terraform example

resource "aws_globalaccelerator_accelerator" "main" {
  name            = "prod-accelerator"
  ip_address_type = "IPV4"
  enabled         = true

  attributes {
    flow_logs_enabled   = true
    flow_logs_s3_bucket = aws_s3_bucket.ga_logs.bucket
    flow_logs_s3_prefix = "global-accelerator/"
  }
}

resource "aws_globalaccelerator_listener" "https" {
  accelerator_arn = aws_globalaccelerator_accelerator.main.id
  protocol        = "TCP"

  port_range {
    from_port = 443
    to_port   = 443
  }
}

resource "aws_globalaccelerator_endpoint_group" "us_east" {
  listener_arn              = aws_globalaccelerator_listener.https.id
  endpoint_group_region     = "us-east-1"
  traffic_dial_percentage   = 100

  health_check_interval_seconds = 30
  health_check_protocol         = "HTTPS"
  health_check_path             = "/health"
  threshold_count               = 3

  endpoint_configuration {
    endpoint_id                    = aws_lb.prod.arn
    weight                         = 128
    client_ip_preservation_enabled = true
  }
}

resource "aws_globalaccelerator_endpoint_group" "eu_west" {
  listener_arn              = aws_globalaccelerator_listener.https.id
  endpoint_group_region     = "eu-west-1"
  traffic_dial_percentage   = 0  # Standby — will receive traffic on primary failure

  health_check_interval_seconds = 30
  health_check_protocol         = "HTTPS"
  health_check_path             = "/health"
  threshold_count               = 3

  endpoint_configuration {
    endpoint_id                    = aws_lb.prod_eu.arn
    weight                         = 128
    client_ip_preservation_enabled = true
  }
}

Note the eu_west endpoint group has traffic_dial_percentage = 0. This is the passive region in an active-passive setup. Global Accelerator will still health check the eu-west-1 ALB. If the us-east-1 endpoint group becomes unhealthy (all endpoints fail health checks), GA automatically routes traffic to eu-west-1 regardless of the dial setting.

Multi-region failover

Global Accelerator performs health checks on each endpoint at configurable intervals (10 or 30 seconds) with a configurable failure threshold. When an endpoint becomes unhealthy, GA stops routing traffic to it. When an entire endpoint group becomes unhealthy, GA routes traffic to the next available group.

The critical advantage over DNS-based failover: because the Anycast IPs are static, there is no DNS change involved. Clients already connected to the IPs continue connecting; GA's internal routing shifts traffic to the healthy region. Failover completes in roughly 30 seconds (health check interval × threshold count).

Active-active pattern: Multiple endpoint groups, each with traffic dial > 0. Traffic is distributed across regions proportionally. All regions serve traffic simultaneously.

Active-passive pattern: Primary region at traffic dial 100%. Secondary region endpoints healthy but at lower weight or dial 0%. On primary failure, GA shifts automatically to secondary.

For the active-passive case with Terraform, you typically want the secondary dial at 100% with healthy endpoints waiting, not dial 0% — otherwise GA won't route to it automatically during failures. Set dial to 100% on both, and use endpoint weights to express preference.

Custom routing accelerators

Standard Global Accelerator load-balances traffic across endpoints. Custom routing accelerators work differently: they map traffic deterministically to specific EC2 instances in a VPC using port-to-instance mappings. A given source IP and port always reaches the same backend instance.

This is designed for stateful applications where a client must maintain affinity to the same backend — multiplayer game servers, real-time collaboration tools, VDI sessions. Traffic bypasses load balancers entirely and goes directly to the instance. You configure allowed ranges in the endpoint group, and GA allocates a port range per instance.

Pricing

Global Accelerator pricing has two components:

• Fixed fee: $0.025 per accelerator per hour — $18.25/month regardless of traffic
• Data transfer premium (DT-Premium): charged on top of standard AWS data transfer rates. Varies by source region. Roughly $0.015–$0.08/GB depending on origin geography.

A rough example: one accelerator, 10 TB/month of traffic from North America to us-east-1:

• Fixed: $18.25
• DT-Premium: ~$0.015/GB × 10,000 GB = $150
• Standard EC2 data transfer to internet: ~$0.09/GB × 10,000 = $900
• Total: ~$1,068/month

Compare with CloudFront for the same 10 TB: approximately $85/month at standard pricing, plus the EC2 outbound charge to CloudFront ($0.008/GB origin to CloudFront for the first 10 TB in same region). CloudFront is dramatically cheaper — but it caches, which is a fundamentally different capability. For non-cacheable TCP workloads, Global Accelerator is the right tool.

Global Accelerator vs CloudFront

The two services are complementary, not competing. A common architecture: CloudFront sits in front of your web application and REST APIs (caching + WAF), and Global Accelerator handles a separate WebSocket or gRPC tier that requires persistent TCP connections. You can also use Global Accelerator as the entry point for an NLB handling non-HTTP traffic while CloudFront handles your main web properties.

Visualizing Global Accelerator in your network topology

Global Accelerator sits outside your VPCs — it's a global overlay that routes to regional endpoints. When you have multiple endpoint groups across regions, understanding the traffic flow and failover relationships requires seeing the full picture: which ALBs are registered as endpoints, which regions are active vs standby, and how traffic dials are configured.

VizCon auto-discovers your Global Accelerator accelerators, listeners, and endpoint group configurations alongside your VPC topology, giving you a live view of how your global routing layer connects to your regional infrastructure — useful when verifying that endpoints are correctly registered and health checks are passing across regions.