AWS Global Accelerator: A Complete Guide to Reducing Latency for Global Users

What is AWS Global Accelerator?

AWS Global Accelerator is a network-layer (Layer 3/4) service that improves the performance, availability, and security of your applications by routing user traffic through the AWS global backbone network instead of the public internet.

When you create an accelerator, AWS assigns you two static anycast IPv4 addresses announced from over 100 edge locations worldwide. When a user connects to one of these IPs, their traffic enters the AWS network at the nearest edge location and traverses the private, congestion-free AWS backbone to reach your application endpoint.

Without Global Accelerator:
  User → ISP → Public Internet (multiple hops, congestion, packet loss) → Your App

With Global Accelerator:
  User → ISP → Nearest AWS Edge (short hop) → AWS Private Backbone → Your App

AWS reports an average latency reduction of 25-30%, with up to 60% improvement in some cases, particularly for users on congested or long-distance internet paths.

Key Characteristics

Global Accelerator vs. CloudFront: Know the Difference

One of the most common questions: "Why not just use CloudFront?"

Use Global Accelerator when:

• Your application is dynamic and session-driven (login portals, e-commerce)
• You need static IPs for firewall allowlisting
• You need non-HTTP protocol support (gaming, VoIP, IoT)
• You need instant failover without DNS propagation delays

Use CloudFront when:

• Your content is cacheable (images, CSS, JS, API responses)
• You need edge-side compute (Lambda@Edge, CloudFront Functions)

You can also use both together — CloudFront for cacheable assets, Global Accelerator for the dynamic application backend.

Standard vs. Custom Routing Accelerators

Standard Accelerator (Most Common)

Routes traffic based on geography, health, and configured weights. Supports ALB, NLB, EC2, and Elastic IP endpoints with automatic health checking and failover.

Traffic controls include:

• Traffic Dials: Set at the endpoint group (regional) level. A 50% dial means only half the traffic is accepted by that region; the rest overflows to other regions.
• Endpoint Weights: Set per endpoint within a group (0-255, default 128). Controls distribution across endpoints in the same region.

Custom Routing Accelerator

Deterministically maps each client connection to a specific EC2 instance and port. Designed for applications that manage their own session routing (multiplayer gaming, VoIP). No health checks, no automatic failover, VPC subnets only.

Pricing

Global Accelerator pricing has two components:

Fixed Fee

$0.025 per accelerator per hour (~$18/month). Charged whether the accelerator is enabled or disabled — only deleting it stops charges.

Data Transfer Premium (DT-Premium)

An incremental per-GB charge on top of standard AWS data transfer, based on the source region and destination edge location. You're billed on the dominant direction only (whichever direction has more data each hour).

Example: One accelerator with 50GB/month of traffic between Asia Pacific and Asia Pacific:

• Fixed: $18
• DT-Premium: 50 GB x $0.010 = $0.50
• Total: ~$18.50/month (plus standard AWS data transfer fees)

For moderate-traffic applications, Global Accelerator is remarkably cost-effective compared to alternatives like deploying proxy infrastructure in multiple regions.

Real-World Implementation: Accelerating a Vendor Portal for China Users

Here's a walkthrough of implementing Global Accelerator for a multi-account AWS environment where users in China need faster access to an application hosted in Singapore.

The Problem

A vendor portal running on ECS Fargate behind an ALB in Singapore (ap-southeast-1) was experiencing 5-15 second page loads for users in China. The traffic path traversed the public internet and China's Great Firewall, introducing unpredictable latency, packet loss, and occasional DNS resolution failures.

Before:
  China Users → Public Internet → Great Firewall → Singapore ALB → ECS Fargate
                                   (5-15s page loads, packet loss)

The Solution

Deploy a Global Accelerator that routes China users onto the AWS backbone at the Hong Kong edge location, bypassing the worst of the public internet path.

After:
  China Users → Short Public Hop → Hong Kong AWS Edge → AWS Backbone → Singapore ALB
                                    (anycast entry)      (private, fast)

Architecture Considerations

My setup involved two AWS accounts:

• Management account (111111111111): Where the Global Accelerator lives
• Application account (222222222222): Where the ALB and ECS application live

This required cross-account endpoint support, which adds a few extra steps.

Step 1: Create the Accelerator

In the Management account (111111111111), navigate to the Global Accelerator console:

1. Click Create accelerator
2. Name: vendor-portal-singapore
3. IP address type: IPv4
4. Accelerator type: Standard

This provisions two static anycast IPs (e.g., 75.2.100.10 and 99.83.200.20) and a DNS name (a1b2c3d4e5f6g7h8i.awsglobalaccelerator.com).

Step 2: Configure Listeners

Add two TCP listeners:

Use TCP (not HTTP/HTTPS) because Global Accelerator operates at Layer 4. The ALB behind it handles SSL termination.

Step 3: Configure Endpoint Groups

For each listener, create an endpoint group:

Step 4: Cross-Account Endpoint Setup

This is where things get interesting in a multi-account environment.

Common Mistake: Creating the Attachment in the Wrong Account

You might assume the accelerator owner creates the cross-account attachment. This is wrong. The attachment must be created by the resource owner — the account that owns the ALB.

An error occurred (InvalidArgumentException): The following resource must
belong to the attachment owner: arn:aws:elasticloadbalancing:ap-southeast-1:
222222222222:loadbalancer/app/my-alb/abc123

Correct Flow

In the Application account (222222222222):

1. Go to Global Accelerator → Cross-account attachments → Create attachment
2. Name: vendor-portal-alb
3. Principal: 111111111111 (the Management account that owns the accelerator)
4. Resource: Select your ALB from the dropdown

In the Management account (111111111111):

1. Go to your accelerator → listener → endpoint group → Add endpoint
2. Check "Add a resource specified in a cross-account attachment"
3. Select account 222222222222 as the attachment owner
4. Select the ALB endpoint
5. Weight: 128
6. Preserve client IP: Enabled (important so X-Forwarded-For headers work)

Verify the endpoint shows Healthy status.

Step 5: Handle SCP Region Restrictions

If your organization uses Service Control Policies to restrict AWS regions, you'll hit a blocker:

User is not authorized to perform: globalaccelerator:ListCrossAccountResourceAccounts
with an explicit deny in a service control policy

Global Accelerator's control plane runs in us-west-2. If your SCP only allows us-east-1, us-east-2, and ap-southeast-1, all GA API calls will be denied.

Fix: Update the SCP to exempt Global Accelerator using the NotAction pattern:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideAllowedRegions",
      "Effect": "Deny",
      "NotAction": [
        "globalaccelerator:*",
        "iam:*",
        "sts:*",
        "route53:*",
        "cloudfront:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-east-2",
            "ap-southeast-1"
          ]
        }
      }
    }
  ]
}

This is the AWS-documented approach. The NotAction + Deny combination means: "Deny everything EXCEPT these global services when the requested region is not in the allowed list." The GA data plane (actual traffic routing) is unaffected by SCPs — only management API calls are blocked.

Step 6: Update DNS with Geo-Based Routing

I used geo-based DNS routing so only Asia-Pacific users go through the Global Accelerator, while users in other regions continue hitting the application directly.

In my DNS provider, I created CNAME records for each hostname:

This ensures:

• Asia users hit the GA anycast IPs and ride the AWS backbone
• All other users go directly to the ALB (no GA overhead or cost)

Step 7: Verify from China

DNS Resolution

C:\Users\User> nslookup vendors.example.com
Name:    a1b2c3d4e5f6g7h8i.awsglobalaccelerator.com
Addresses: 75.2.100.10
           99.83.200.20
Aliases:  vendors.example.com

The China user resolves to the GA anycast IPs — the geo DNS is working.

HTTP Test Through GA

C:\Users\User> curl -v --resolve vendors.example.com:443:75.2.100.10 https://vendors.example.com/
* Connected to vendors.example.com (75.2.100.10) port 443
< HTTP/1.1 302 Found
< Location: https://vendors.example.com/sessions/new
< X-Runtime: 0.006450

A 302 redirect with a 6ms server runtime — the GA path is fast.

Important: GFW DNS Interference

China's Great Firewall can intermittently block DNS resolution to external authoritative servers. During testing, I observed:

• Default ISP DNS: Worked for some hostnames, timed out for others
• Public DNS (114.114.114.114): Timed out
• Alibaba DNS (223.5.5.5): Intermittently worked

Monitoring with CloudWatch

All Global Accelerator metrics live in CloudWatch under the AWS/GlobalAccelerator namespace. You must query us-west-2, regardless of where your endpoints are.

Key Metrics

Gotcha: Dimension Values

CloudWatch requires you to specify the exact dimensions a metric was published with. Common mistakes:

Wrong — using the DNS name:

aws cloudwatch get-metric-statistics \
  --dimensions Name=Accelerator,Value=a1b2c3d4e5f6g7h8i.awsglobalaccelerator.com
  # Returns empty datapoints!

Right — using the accelerator GUID:

aws cloudwatch get-metric-statistics \
  --namespace AWS/GlobalAccelerator \
  --metric-name NewFlowCount \
  --dimensions Name=Accelerator,Value=abcd1234-ef56-7890-abcd-ef1234567890 \
  --start-time 2026-03-03T00:00:00Z \
  --end-time 2026-03-04T00:00:00Z \
  --period 3600 \
  --statistics Sum \
  --region us-west-2

The accelerator GUID is the final segment of the accelerator ARN (e.g., arn:aws:globalaccelerator::111111111111:accelerator/abcd1234-ef56-7890-abcd-ef1234567890).

Multi-Dimension Queries

Some metrics are published with multiple dimensions (e.g., Accelerator + SourceRegion). You must specify all dimensions that the metric was published with:

aws cloudwatch get-metric-statistics \
  --namespace AWS/GlobalAccelerator \
  --metric-name NewFlowCount \
  --dimensions \
    Name=Accelerator,Value=abcd1234-ef56-7890-abcd-ef1234567890 \
    Name=SourceRegion,Value=AP \
  --start-time 2026-03-03T00:00:00Z \
  --end-time 2026-03-04T00:00:00Z \
  --period 3600 \
  --statistics Sum \
  --region us-west-2

Tip: If you're getting empty datapoints, run list-metrics first to see the exact dimension combinations:

aws cloudwatch list-metrics \
  --namespace AWS/GlobalAccelerator \
  --region us-west-2

Source Region Values

Health Checks and Failover

Global Accelerator continuously monitors endpoint health and provides instant failover — no DNS TTL propagation delays.

Failover Behavior

1. When an endpoint becomes unhealthy, new connections are immediately routed to the next healthy endpoint
2. Existing connections remain on the current endpoint until the idle timeout expires (340s for TCP, 30s for UDP)
3. If no healthy endpoints exist in an endpoint group, traffic overflows to healthy endpoints in other endpoint groups (other regions)
4. If there are no healthy endpoints anywhere, traffic is sent to all endpoints as a last resort

ALB-Specific Health Checks

When using ALB endpoints, health checks are managed through the Elastic Load Balancing console, not Global Accelerator. An ALB is considered healthy only if every target group has at least one healthy target.

Make sure your security groups and NACLs allow traffic from Amazon Route 53 health checker IP addresses on the health check port.

Integration with AWS Services

AWS Shield

• Shield Standard: Automatically included at no extra cost. Protects against known network/transport layer DDoS attacks.
• Shield Advanced: Provides customized detection based on your traffic patterns, near real-time attack visibility, and DDoS cost protection. Includes a stateless SYN proxy at the edge.

AWS WAF

When GA fronts an ALB, WAF rules on the ALB continue to work normally. GA passes traffic through at Layer 4; WAF inspects at Layer 7 on the ALB.

Infrastructure as Code

Fully supported in CloudFormation:

AWS::GlobalAccelerator::Accelerator
AWS::GlobalAccelerator::Listener
AWS::GlobalAccelerator::EndpointGroup
AWS::GlobalAccelerator::CrossAccountAttachment

CDK constructs available in aws_cdk.aws_globalaccelerator.

Best Practices

Architecture

1. Use ALBs as endpoints — the most common and recommended pattern. ALBs handle Layer 7 routing within a region; GA handles cross-region network routing.
2. Deploy endpoints in multiple regions for true multi-region high availability with instant failover.
3. Don't configure the same ALB behind multiple accelerators — this can cause connection collisions.

Traffic Management

4. Use traffic dials for controlled rollouts — start at 10-20% when onboarding a new region to limit blast radius.
5. Use endpoint weights for A/B testing within a region.

Monitoring

6. Set up CloudWatch alarms on UnhealthyEndpointCount and NewFlowCount for rapid detection of issues.
7. All monitoring must target us-west-2 — configure dashboards and alarms in Oregon regardless of endpoint regions.

Security

8. Enable Shield Advanced on accelerators for enhanced DDoS protection.
9. Exempt globalaccelerator:* in region-restriction SCPs — this is easy to forget and will break all GA management operations.

Cost

10. One accelerator per application is typical — avoid creating unnecessary accelerators ($18/month each).
11. Use geo-based DNS so only users who benefit from GA (long-distance or restrictive networks) are routed through it, keeping DT-Premium costs down.

Results

After deploying Global Accelerator with geo-based DNS routing for Asia-Pacific users:

The CloudWatch metrics confirmed traffic flowing from the AP (Asia-Pacific) source region through the accelerator within hours of the DNS update. The X-Runtime headers from the application showed server-side processing times of 6-14ms, confirming the GA path eliminates the network bottleneck.

Conclusion

AWS Global Accelerator is a simple, cost-effective solution for improving application performance for users on congested or long-distance internet paths. It's particularly valuable for:

• Users behind restrictive firewalls (like China's GFW) where the public internet path is unreliable
• Multi-account organizations that need centralized traffic management with cross-account endpoints
• Dynamic applications where CDN caching doesn't help

The key things to remember:

1. GA is Layer 3/4, not Layer 7 — no caching, no content awareness
2. Cross-account attachments must be created by the resource owner, not the accelerator owner
3. The control plane lives in us-west-2 — exempt it from region-restriction SCPs
4. CloudWatch metrics use the accelerator GUID as the dimension value, not the DNS name
5. Pair with geo-based DNS to route only the users who need it through the accelerator

For the cost of a few coffees per month ($18-25), you get a managed, globally distributed network acceleration layer with automatic health checks and instant failover. For my use case, it turned a frustrating 5-15 second experience into a responsive 1-3 second one — without deploying a single piece of infrastructure.

Further Reading

• AWS Global Accelerator Documentation
• Cross-Account Resource Support
• CloudWatch Metrics for Global Accelerator
• Global Accelerator Pricing
• Best Practices for Deployment