Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS Global Accelerator provides a fixed, globally distributed entry point for applications running in one or more AWS Regions. It improves network performance by moving users onto the AWS global network at a nearby edge location and can redirect traffic to a healthy regional endpoint when a failure occurs.
Global Accelerator is not a caching service. It accelerates traffic to the application origin rather than serving cached content from the edge.
Key Concepts
How Global Accelerator routes traffic
A typical architecture places application endpoints in multiple Regions, such as:
- An Application Load Balancer or Network Load Balancer in
us-east-1 - Another load balancer in
eu-west-1 - Application servers behind each load balancer
- A Global Accelerator in front of the regional endpoints
Users connect to the accelerator using two static anycast IP addresses. DNS can map an application hostname to the accelerator’s DNS name, which resolves to those addresses.
The traffic flow is broadly:
- The client resolves the application hostname.
- The client connects to one of the accelerator’s static anycast IP addresses.
- Internet routing directs the client to a nearby AWS edge location.
- Traffic enters the AWS global network as early as possible.
- Global Accelerator selects an appropriate healthy endpoint and carries traffic to that AWS Region.
This reduces the portion of the journey that depends on the variable performance of the public internet.
Anycast IP addresses
An anycast IP address can be advertised from multiple network locations. The same address is therefore reachable through different AWS edge locations, and internet routing generally directs a client to an appropriate nearby entry point.
This differs from a conventional unicast address, which identifies a particular network destination. For exam purposes, remember that Global Accelerator’s static IPs provide a stable client-facing entry point while the underlying endpoint and network path can change.
AWS global network versus the public internet
Global Accelerator attempts to receive traffic at an AWS edge location close to the client. From there, traffic travels across the AWS global network toward the selected endpoint.
The main benefit is not that every packet necessarily takes the shortest geographic route. The benefit is that AWS controls more of the path after ingress, which can improve latency consistency, throughput, and resilience compared with relying entirely on internet routing.
Health checks and endpoint failover
Global Accelerator performs health checks against configured endpoints. If the preferred endpoint or Region becomes unhealthy, traffic can be directed to another healthy endpoint.
This supports architectures such as:
- Active-active deployments across Regions
- Active-passive regional failover
- Disaster recovery configurations with a standby Region
Health checks must reflect actual application availability. A server that accepts TCP connections but cannot serve valid application requests may require a more meaningful health-check configuration at the endpoint or load balancer layer.
Layer 4 traffic acceleration
Global Accelerator operates at Layer 4 and supports both:
- TCP
- UDP
It can therefore support applications that are not limited to web traffic, including gaming, voice and video workloads, IoT protocols, and custom TCP or UDP services.
It can also accelerate HTTP and HTTPS applications, but it does not provide the HTTP-aware caching and request-processing behavior associated with CloudFront.
Global Accelerator compared with CloudFront
Both services use AWS edge locations, but they solve different problems:
| Capability | Global Accelerator | CloudFront |
|---|---|---|
| Primary function | Network acceleration and endpoint failover | Content delivery and edge caching |
| OSI focus | Layer 4 | Layer 7 HTTP/HTTPS |
| Protocols | TCP and UDP | HTTP and HTTPS |
| Static anycast IPs | Yes | No fixed anycast IPs for customer use in the same way |
| Caching | No | Yes, for cacheable content |
| Suitable for custom ports | Yes | No; CloudFront is for HTTP/HTTPS viewer traffic |
| Typical origins | ALB, NLB, EC2, Elastic IP-based endpoints | S3, ALB, API Gateway, and other HTTP origins |
Use CloudFront when the main requirement is caching, HTTP content delivery, TLS termination at the edge, or web request behavior. Use Global Accelerator when the main requirement is static IP addressing, TCP/UDP support, improved network paths, or rapid regional failover.
Exam-Relevant Takeaways
- Global Accelerator provides two static anycast IP addresses as a stable front door for an application.
- It uses AWS edge locations to bring clients onto the AWS global network quickly.
- It improves network performance but does not cache application content.
- It supports TCP and UDP, unlike CloudFront’s HTTP/HTTPS-only viewer model.
- Health checks allow traffic to be redirected away from unhealthy endpoints.
- Global Accelerator is a strong choice for multi-Region applications that need fast failover without changing client-facing IP addresses.
- CloudFront is generally the better choice when caching and HTTP content delivery are the primary requirements.
- Global Accelerator can front regional endpoints such as Application Load Balancers, Network Load Balancers, EC2 instances, and Elastic IP-based resources.
Architecture Decision Guide
| Requirement | Recommended service or design | Reason |
|---|---|---|
| Cache static or dynamic HTTP content at edge locations | CloudFront | Provides caching and HTTP-aware delivery |
| Accelerate TCP or UDP traffic | Global Accelerator | Supports Layer 4 protocols |
| Provide fixed public IPs for a globally accessed application | Global Accelerator | Supplies static anycast IP addresses |
| Automatically move traffic between healthy Regions | Global Accelerator | Uses endpoint health checks and traffic distribution |
| Route users based on DNS policies such as latency or geography | Route 53 routing policies | DNS makes the endpoint selection decision |
| Reduce latency for uncached, non-HTTP application traffic | Global Accelerator | Uses edge ingress and the AWS global network |
| Serve content from an origin close to users through caching | CloudFront | Edge caching reduces origin requests |
Common Exam Traps
- Confusing Global Accelerator with CloudFront: Global Accelerator does not cache files or responses. It accelerates the network path to the origin.
- Assuming CloudFront supports arbitrary TCP or UDP ports: CloudFront is designed for HTTP and HTTPS viewer traffic; Global Accelerator supports TCP and UDP.
- Treating anycast IPs as fixed regional server addresses: The IPs are stable client-facing addresses, but routing to the AWS edge location and regional endpoint can change.
- Assuming Global Accelerator automatically makes an application multi-Region: The application must have endpoints deployed in multiple Regions and configured with suitable traffic distribution and health checks.
- Ignoring endpoint health: Regional failover depends on health checks and endpoint configuration. A deployment with only one healthy endpoint has no meaningful failover target.
- Using Global Accelerator when caching is the main objective: If the requirement is to reduce origin load by serving cached objects globally, CloudFront is usually the appropriate service.
- Assuming DNS alone provides immediate failover: DNS-based failover can be affected by resolver and client caching. Global Accelerator provides a stable IP front door and can change the selected endpoint without requiring clients to obtain a new application IP.
Real-World Engineer Notes
- Design the application endpoints for independent regional operation if Global Accelerator is expected to provide regional failover.
- Use an ALB when the workload is HTTP-aware and requires Layer 7 routing. Use an NLB when preserving Layer 4 behavior, supporting high-performance TCP/UDP traffic, or exposing static IPs at the load balancer layer is important.
- Make health checks meaningful. Checking only whether a port is open may allow traffic to reach an application that is technically reachable but functionally unavailable.
- Global Accelerator improves the network path, but it does not solve application-layer problems such as slow database queries, overloaded instances, or cross-Region data consistency.
- Multi-Region acceleration introduces operational complexity. Consider deployment automation, data replication, regional capacity, failover testing, and observability before enabling active-active or active-passive designs.
- Global Accelerator is a paid service. The latency and resiliency benefits should be weighed against simpler options such as Route 53 latency-based routing or CloudFront, depending on the protocol and workload.
Quick Reference Summary
- Service type: Global network traffic accelerator
- Network layer: Layer 4
- Protocols: TCP and UDP
- Client entry point: Two static anycast IP addresses
- Traffic path: Client → nearby AWS edge location → AWS global network → healthy regional endpoint
- Caching: None
- Failover: Health-check-based endpoint selection and traffic redirection
- Best for: Multi-Region applications, static IP requirements, TCP/UDP workloads, and low-latency global access
- Primary alternative: CloudFront for HTTP/HTTPS caching and content delivery
Flashcards
- What is the primary purpose of AWS Global Accelerator?
To improve global application network performance and availability by providing static anycast IPs and routing traffic through the AWS global network.
- Does Global Accelerator cache application content?
No. It forwards traffic to application endpoints rather than serving cached objects.
- What type of IP addresses does Global Accelerator provide?
Static anycast IP addresses that provide a stable global entry point.
- At which OSI layer does Global Accelerator operate?
Layer 4.
- Which protocols does Global Accelerator support?
TCP and UDP.
- Why are AWS edge locations involved in Global Accelerator?
They allow traffic to enter the AWS global network close to the client.
- How does Global Accelerator respond to an unhealthy endpoint?
It can stop directing traffic to that endpoint and route clients to another healthy endpoint.
- When is CloudFront a better choice than Global Accelerator?
When the main requirement is HTTP/HTTPS content delivery, caching, or reducing origin requests.
- When is Global Accelerator a better choice than CloudFront?
When the application requires static IPs, TCP/UDP support, custom ports, or network-level regional failover.
- Does Global Accelerator by itself create a multi-Region application?
No. The application owner must deploy and operate endpoints in multiple Regions.
Practice Questions
Question 1
A gaming company operates a real-time service that uses UDP. Players are distributed globally, and the company wants stable public IP addresses, improved network performance, and failover to a second AWS Region if the primary Region becomes unavailable. Which solution best meets these requirements?
Correct answer: AWS Global Accelerator with endpoints in both Regions.
Explanation: Global Accelerator supports UDP, provides static anycast IP addresses, uses the AWS global network, and can redirect traffic based on endpoint health. CloudFront is not appropriate because the workload is not HTTP/HTTPS content delivery.
Question 2
A company wants to reduce latency for a globally distributed website by caching images, JavaScript, CSS, and API responses at edge locations. Which AWS service should be the primary solution?
Correct answer: Amazon CloudFront.
Explanation: The requirement is edge caching and HTTP/HTTPS content delivery. Global Accelerator can improve the network path to the origin, but it does not cache objects.
Question 3
An enterprise has an HTTPS application deployed behind Application Load Balancers in two Regions. Client integrations require a fixed set of public IP addresses that will not change during regional failover. The application does not need edge caching. Which service should be placed in front of the load balancers?
Correct answer: AWS Global Accelerator.
Explanation: Global Accelerator provides static anycast IP addresses and can distribute traffic across healthy ALB endpoints. It is appropriate when fixed IPs and regional failover matter more than caching.
Question 4
A company configures Global Accelerator with endpoints in two Regions. During testing, traffic continues reaching the primary endpoint even though the application behind it is returning errors. The endpoint’s health check only verifies that a TCP port is accepting connections. What is the most likely improvement?
Correct answer: Configure a health check that validates meaningful application availability.
Explanation: A successful TCP connection does not prove that the application can process requests correctly. Health checks should test an appropriate application endpoint or otherwise reflect the failure conditions that should trigger traffic removal.
Question 5
A solutions architect recommends Global Accelerator for an application solely because it will cache frequently requested content at AWS edge locations. What should be changed?
Correct answer: Use CloudFront for the caching requirement, optionally combining it with Global Accelerator only if separate network acceleration or static-IP requirements justify both services.
Explanation: Global Accelerator does not cache content. CloudFront is the AWS service designed to cache and deliver HTTP/HTTPS content from edge locations.