This chapter provides a deep dive into AWS Global Accelerator and Amazon CloudFront, two AWS services that improve application performance and availability. Understanding the differences between these services is critical for the SAA-C03 exam, as questions on this topic appear in roughly 5-8% of the exam. You will learn the internal mechanics, use cases, and configuration details for each service, as well as how to choose between them based on workload requirements. By the end of this chapter, you will be able to architect solutions that optimally leverage both services for global traffic acceleration.
Jump to a section
Imagine you are a global company with a single headquarters in Virginia, and you have customers in Tokyo, London, and Sydney. Without any optimization, a customer in Tokyo requests a file from your headquarters: the request travels across the public internet, going through multiple routers and potentially congested links, and the response travels back the same way. This is like taking local roads with traffic lights and intersections — unpredictable and slow. Now, CloudFront is like building a network of local distribution centers (edge locations) in Tokyo, London, and Sydney. The first time a customer in Tokyo requests the file, CloudFront fetches it from Virginia (origin), stores a copy in Tokyo, and serves subsequent requests from that local cache — dramatically reducing latency for repeat requests. But the first request still suffers the long trip. AWS Global Accelerator, on the other hand, keeps the single headquarters but builds a dedicated express lane: it uses the AWS global network backbone (a private, high-capacity fiber network) to route traffic from Tokyo to Virginia. The request enters the AWS network at the closest edge location (Tokyo), then travels entirely within AWS's private network to the origin in Virginia — avoiding public internet congestion. The response also returns via the same optimized path. So CloudFront caches content to avoid the trip entirely for subsequent requests, while Global Accelerator makes every trip faster by using a better road. Both improve performance, but they solve different problems: CloudFront is for static or cacheable content, while Global Accelerator is for dynamic content, APIs, or any TCP/UDP traffic that cannot be cached.
What is AWS Global Accelerator?
AWS Global Accelerator is a networking service that improves the availability and performance of applications by directing user traffic over the AWS global network to the optimal regional endpoint. It works by providing two static Anycast IP addresses that serve as a fixed entry point to your application. These IP addresses are announced from multiple AWS edge locations simultaneously, so traffic from a user is routed to the nearest edge location via the public internet, then forwarded over the AWS backbone to the chosen regional endpoint (e.g., an Application Load Balancer, Network Load Balancer, or EC2 instance). This avoids the congestion and variability of the public internet for the majority of the path.
How Global Accelerator Works Internally
When a client connects to a Global Accelerator static IP, the client's DNS resolves the Anycast IP to the nearest edge location based on BGP routing. At the edge, Global Accelerator terminates the client connection (for TCP/UDP) and establishes a new connection over the AWS global network to the endpoint. This is called connection termination at the edge. The service maintains flow state and uses the AWS backbone for consistent, low-latency routing. If an endpoint fails, Global Accelerator can reroute traffic to a healthy endpoint in another region within seconds, using health checks. The service supports both TCP and UDP traffic and can handle millions of concurrent connections.
Key Components and Defaults
Static IP Addresses: Global Accelerator provides two static IPv4 addresses by default. These are Anycast addresses, meaning they are advertised from multiple edge locations. You cannot choose the IP addresses; they are assigned by AWS.
Endpoints: Endpoints can be Application Load Balancers (ALB), Network Load Balancers (NLB), EC2 instances, or Elastic IP addresses. For EC2 instances, you must attach an Elastic IP to use them as endpoints.
Endpoint Groups: You group endpoints by region. Traffic is directed to the endpoint group closest to the user, with optional traffic dials to control the percentage of traffic sent to each group.
Health Checks: Global Accelerator performs health checks on endpoints every 10 seconds by default (configurable). If an endpoint is unhealthy, traffic is rerouted.
Traffic Dials: You can set a percentage (0-100) for each endpoint group to control traffic distribution, useful for blue/green deployments or testing.
Accelerator: The main resource. You can have up to 10 accelerators per account by default, but you can request a limit increase.
Configuration and Verification
To create a Global Accelerator via AWS CLI:
aws globalaccelerator create-accelerator --name MyAccelerator --ip-address-type IPV4To add an endpoint group:
aws globalaccelerator create-endpoint-group --endpoint-group-region us-east-1 --listener-arn arn:aws:globalaccelerator::123456789012:listener/1234abcd --endpoint-configurations EndpointId=arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/1234567890abcdefTo verify traffic routing, you can use dig on the static IP or use traceroute to see the path.
What is Amazon CloudFront?
Amazon CloudFront is a content delivery network (CDN) that caches content at edge locations worldwide to deliver static and dynamic web content with low latency. It integrates with AWS services like S3, EC2, and Elastic Load Balancing, as well as custom origins. CloudFront supports HTTP/HTTPS protocols and can also handle WebSockets. It is optimized for cacheable content (images, CSS, JavaScript, video) but can also accelerate dynamic content by using origin shields and persistent connections.
How CloudFront Works Internally
When a user requests content, CloudFront routes the request to the edge location that best serves the user (based on latency or geographic proximity). At the edge, CloudFront checks its cache. If the content is cached and not expired, it serves it directly. If not, it forwards the request to the origin (e.g., an S3 bucket or HTTP server). CloudFront then caches the response at the edge for subsequent requests. The cache behavior is controlled by cache policies, origin request policies, and TTL settings. CloudFront uses a DNS-based routing system that maps the CloudFront distribution domain name (e.g., d123.cloudfront.net) to the optimal edge location via AWS's global DNS.
Key Components and Defaults
Distribution: A collection of settings that tell CloudFront how to deliver content. Two types: web distributions (for HTTP/HTTPS) and RTMP distributions (for streaming media, now deprecated).
Origins: The source of the content. Can be S3 bucket, ELB, EC2, or any HTTP server. You can configure multiple origins per distribution.
Cache Behaviors: Define how to process requests for a given URL path pattern. Each cache behavior has a path pattern (e.g., /images/*), a TTL, and allowed HTTP methods.
Edge Locations: Currently over 400 points of presence globally. These are not just cache nodes; they also support Lambda@Edge for serverless compute at the edge.
TTL (Time to Live): Default minimum TTL is 0 seconds, default maximum TTL is 31536000 seconds (1 year). You can set default TTL per cache behavior (typically 86400 seconds for static assets).
Invalidations: You can invalidate cached objects by path or wildcard, but this incurs a cost. Up to 1000 free invalidations per month.
Signed URLs/Cookies: Used to restrict access to premium content.
Origin Shield: An additional caching layer that reduces load on the origin by aggregating requests from multiple edge locations.
Configuration and Verification
To create a CloudFront distribution via AWS CLI:
aws cloudfront create-distribution --distribution-config file://dist-config.jsonA sample dist-config.json:
{
"CallerReference": "my-distribution",
"Aliases": {
"Quantity": 1,
"Items": ["www.example.com"]
},
"DefaultRootObject": "index.html",
"Origins": {
"Quantity": 1,
"Items": [
{
"Id": "myS3Origin",
"DomainName": "my-bucket.s3.amazonaws.com",
"S3OriginConfig": {
"OriginAccessIdentity": ""
}
}
]
},
"DefaultCacheBehavior": {
"TargetOriginId": "myS3Origin",
"ViewerProtocolPolicy": "redirect-to-https",
"DefaultTTL": 86400,
"ForwardedValues": {
"QueryString": false
}
},
"Enabled": true
}To verify, access the distribution domain name and check response headers for X-Cache: Hit from cloudfront or Miss from cloudfront.
How They Interact with Related Technologies
Both services can be used together. For example, you can place CloudFront in front of a Global Accelerator endpoint to cache static content while using Global Accelerator's optimized path for dynamic API calls. However, typically you would use CloudFront for caching and Global Accelerator for dynamic traffic. CloudFront can also use AWS WAF (Web Application Firewall) for security, while Global Accelerator integrates with AWS Shield for DDoS protection. Both services support IPv6 and custom domain names via SSL/TLS certificates (ACM or imported).
Performance Comparison
Latency: Global Accelerator reduces latency by 30-60% for dynamic content compared to public internet, especially for long-distance paths. CloudFront reduces latency for cacheable content by 50-90% after the first request.
Throughput: Global Accelerator can handle millions of concurrent connections and high throughput due to the AWS backbone. CloudFront's throughput is limited by cache hit ratio and origin bandwidth.
Connection Reuse: Global Accelerator reuses connections from edge to origin (persistent connections), reducing origin load. CloudFront also reuses connections from edge to origin but adds a caching layer.
Use Cases
Global Accelerator: Real-time applications, gaming, VoIP, IoT, APIs, and any TCP/UDP traffic that cannot be cached. Also used for failover across regions with health checks.
CloudFront: Static website hosting, video streaming, software downloads, API caching (with TTL), and content distribution with DDoS protection via AWS Shield.
Exam Tips
The exam often presents a scenario where you need to choose between CloudFront and Global Accelerator. Key differentiators: caching vs. not caching, HTTP/HTTPS only vs. any TCP/UDP, DNS routing vs. Anycast IP, and integration with AWS Shield for DDoS.
Remember that Global Accelerator does NOT cache content; it optimizes the network path. CloudFront caches content at the edge.
Global Accelerator provides static IP addresses, which is useful for whitelisting. CloudFront uses a domain name (though you can bring your own domain via CNAME).
Both services can be used together: CloudFront in front of Global Accelerator for a comprehensive solution (cache + optimized path for dynamic content).
For UDP traffic, you must use Global Accelerator; CloudFront only supports HTTP/HTTPS and WebSockets.
Global Accelerator supports endpoints in multiple regions and can failover across regions. CloudFront can also use multiple origins but does not have the same regional failover logic; it relies on origin health checks and can redirect to a secondary origin.
Client DNS Resolution
When a client initiates a connection to a Global Accelerator static IP, the client's DNS resolver queries for the Anycast IP. Because the IP is Anycast, BGP routing directs the client's packets to the nearest AWS edge location. This step typically takes less than 50ms. The client does not need to perform DNS resolution for the accelerator; it uses the static IP directly. For CloudFront, the client resolves the distribution domain name (e.g., d123.cloudfront.net) via DNS to the IP address of the nearest edge location. CloudFront uses a custom DNS service that returns the optimal edge IP based on latency and geographic location.
Connection Termination at Edge
Global Accelerator terminates the client TCP connection at the edge location. This means the client establishes a TCP three-way handshake with the edge, not with the origin server. The edge then initiates a new TCP connection to the origin over the AWS backbone. This separation allows Global Accelerator to optimize the path and use persistent connections to the origin. The client sees a consistent latency regardless of origin load. CloudFront also terminates the client connection at the edge, but it may serve the content from cache without connecting to the origin. If a cache miss occurs, CloudFront establishes a connection to the origin.
Traffic Routing Over AWS Backbone
For Global Accelerator, after terminating the client connection, the edge forwards the traffic to the selected endpoint over the AWS global network. The routing uses the AWS backbone, which is a private, high-capacity fiber network with multiple redundant paths. The edge selects the optimal endpoint group based on the client's location and traffic dials. The path is deterministic and avoids public internet congestion. The latency is typically 10-30ms better than public internet for cross-continent traffic. For CloudFront, if a cache miss occurs, the edge forwards the request to the origin over the public internet or via an origin shield, which may use the AWS backbone if the origin is an AWS service.
Health Check and Failover
Global Accelerator continuously monitors the health of endpoints using health checks (default interval 10 seconds, configurable). If an endpoint fails, Global Accelerator automatically reroutes traffic to healthy endpoints within seconds. The failover is transparent to the client because the client connection is terminated at the edge; the edge simply establishes a new connection to a healthy endpoint. CloudFront also performs health checks on origins, but it does not have the same granularity for failover. CloudFront can be configured to use a secondary origin if the primary fails, but the failover is based on HTTP response codes and may take longer.
Response Delivery
For Global Accelerator, the response from the origin travels back through the same edge location over the AWS backbone, then to the client via the public internet. The response path is optimized because the edge-to-origin path is over the private network. For CloudFront, if the content was cached, the edge sends the response directly from cache. If not, the origin sends the response to the edge, which then caches it and sends it to the client. The response headers include X-Cache to indicate hit or miss. CloudFront can also add custom headers for logging or security.
Enterprise Scenario 1: Global Gaming Platform
A gaming company with players worldwide uses Global Accelerator to reduce latency for real-time multiplayer game traffic. The game uses UDP for state updates and TCP for chat. The company deploys game servers in us-east-1, eu-west-1, and ap-southeast-1. They create a Global Accelerator with endpoints in all three regions. Players are automatically directed to the nearest region based on their location. When a region fails, traffic is rerouted within seconds. The company also uses CloudFront to distribute game patches and assets, caching them at edge locations. The combination ensures low-latency gameplay and fast downloads. Misconfiguration: If the health check interval is set too high (e.g., 30 seconds), failover is delayed, causing player disconnections. Also, if traffic dials are not balanced, one region may be overloaded.
Enterprise Scenario 2: E-commerce Platform with Dynamic APIs
An e-commerce site uses a microservices architecture with APIs hosted on ALBs in multiple regions. They use CloudFront to cache product images and static content, but the APIs are dynamic and cannot be cached. They place Global Accelerator in front of the ALBs to provide a static IP for API calls, which is whitelisted by third-party services. Global Accelerator also provides DDoS protection via AWS Shield. The platform handles millions of API requests per day. A common issue is that the origin shield in CloudFront is not used, causing high load on the ALB from multiple edge locations. They enable origin shield to aggregate requests, reducing ALB load by 40%. Another issue: if the Global Accelerator endpoint group is configured with an incorrect traffic dial, some users may experience high latency if routed to a distant region.
Enterprise Scenario 3: Media Streaming Service
A streaming service delivers live and on-demand video globally. They use CloudFront for video content, leveraging its support for HTTP Live Streaming (HLS) and MPEG-DASH. CloudFront caches video segments at edge locations, reducing load on the origin media server. For live streaming, CloudFront uses origin shield to reduce the number of connections to the origin. They also use Global Accelerator for the control plane API (e.g., user authentication, playlist generation) which requires low latency and cannot be cached. The API runs on EC2 instances behind an NLB. Global Accelerator provides static IPs for the API, which is important for client-side whitelisting. A misconfiguration: if the CloudFront TTL for video segments is too long, viewers may see stale content; if too short, origin load increases. For live streaming, the TTL should be set to 0 seconds to ensure freshness.
What the SAA-C03 Tests
This topic falls under Objective 2.5: "Design a resilient and high-performing architecture for a global user base." The exam expects you to understand the differences between Global Accelerator and CloudFront, and when to use each. Specific areas tested: - Use cases: Caching vs. no caching, HTTP/HTTPS vs. any TCP/UDP, static IP vs. DNS. - Integration: How each service integrates with AWS WAF, Shield, Lambda@Edge, and origins. - Performance: Which service reduces latency for dynamic content vs. static content. - Failover: Global Accelerator's regional failover vs. CloudFront's origin failover.
Common Wrong Answers and Why
"Use CloudFront for dynamic API traffic because it caches responses." Wrong: CloudFront caches only if the response is cacheable. For dynamic APIs with unique responses per user, caching is ineffective. Global Accelerator is better because it optimizes the network path without caching.
"Global Accelerator caches content at edge locations." Wrong: Global Accelerator does not cache; it only accelerates the network path. CloudFront caches.
"CloudFront provides static IP addresses." Wrong: CloudFront uses a domain name; you can bring your own domain but not a static IP. Global Accelerator provides static IPs.
"Both services support UDP traffic." Wrong: CloudFront only supports HTTP/HTTPS and WebSockets (which use TCP). Global Accelerator supports UDP.
Specific Numbers and Terms
Global Accelerator: 2 static Anycast IPs, health check interval default 10 seconds, up to 10 accelerators per account.
CloudFront: Over 400 edge locations, default TTL 86400 seconds, 1000 free invalidations per month, origin shield is an optional feature.
Common exam phrase: "Which service should you use to improve performance for a global user base accessing a dynamic API?" Answer: Global Accelerator.
Another phrase: "You need to provide a fixed IP address for whitelisting by third-party services." Answer: Global Accelerator.
Edge Cases and Exceptions
WebSockets: CloudFront supports WebSockets (since 2021), so for WebSocket-based applications, CloudFront can be used, but Global Accelerator also supports WebSockets over TCP.
Custom ports: Global Accelerator supports any TCP/UDP port; CloudFront only supports standard HTTP/HTTPS ports (80, 443) and custom ports for HTTPS (8443, etc.) but not arbitrary ports.
Origin types: CloudFront can use S3 as an origin with Origin Access Identity (OAI) for security. Global Accelerator cannot use S3 directly; you must use an ALB, NLB, EC2, or Elastic IP.
Cost: Global Accelerator charges per GB of data processed and per hour for the accelerator. CloudFront charges per GB of data transfer and per request. Both have regional data transfer rates.
How to Eliminate Wrong Answers
If the scenario mentions caching static content, eliminate Global Accelerator.
If the scenario mentions UDP, eliminate CloudFront.
If the scenario requires static IP addresses, eliminate CloudFront.
If the scenario requires HTTP/HTTPS only and caching, choose CloudFront.
If the scenario requires low latency for dynamic content without caching, choose Global Accelerator.
If the scenario requires both, consider using them together.
Global Accelerator uses Anycast IP addresses to route traffic to the nearest edge location, then over the AWS backbone to the origin.
CloudFront caches content at edge locations to reduce latency for static or cacheable content.
Global Accelerator supports both TCP and UDP; CloudFront only supports HTTP/HTTPS and WebSockets.
Global Accelerator does not cache; every request is forwarded to the origin.
CloudFront can be integrated with AWS WAF and Lambda@Edge; Global Accelerator integrates with AWS Shield.
For dynamic APIs that cannot be cached, use Global Accelerator for improved performance.
For static content distribution, use CloudFront to cache at edge locations.
Both services can be used together: CloudFront for caching and Global Accelerator for dynamic traffic.
These come up on the exam all the time. Here's how to tell them apart.
AWS Global Accelerator
Provides two static Anycast IP addresses that remain fixed for the accelerator's lifetime.
Optimizes network path for dynamic content (TCP/UDP) using the AWS backbone.
Does not cache content; every request goes to the origin.
Supports TCP and UDP traffic on any port.
Supports regional failover with health checks and traffic dials.
Amazon CloudFront
Provides a DNS-based domain name; no static IP (unless using custom domain with a CDN-specific IP, but not guaranteed).
Caches content at edge locations to reduce latency for cacheable content.
Caches responses based on TTL; subsequent requests may be served from cache.
Supports HTTP/HTTPS and WebSockets only (no UDP).
Can use multiple origins but failover is based on HTTP response codes; not as granular as Global Accelerator.
Mistake
CloudFront and Global Accelerator are interchangeable for improving application performance.
Correct
They serve different purposes: CloudFront caches content at edge locations to reduce latency for repeat requests, while Global Accelerator optimizes the network path for all traffic (including dynamic) using the AWS backbone. They are not interchangeable.
Mistake
Global Accelerator caches content at edge locations.
Correct
Global Accelerator does not cache any content. It only accelerates the network path by routing traffic over the AWS global network. Caching is a feature of CloudFront only.
Mistake
CloudFront provides static IP addresses that can be used for whitelisting.
Correct
CloudFront uses a domain name (e.g., d123.cloudfront.net). You can associate a custom domain, but the underlying IP addresses are dynamic and can change. Global Accelerator provides two static Anycast IP addresses that remain fixed for the lifetime of the accelerator.
Mistake
Both services support UDP traffic.
Correct
CloudFront only supports HTTP/HTTPS and WebSockets (which use TCP). Global Accelerator supports both TCP and UDP traffic.
Mistake
Global Accelerator cannot be used with an S3 bucket as an origin.
Correct
Global Accelerator cannot directly use an S3 bucket as an endpoint. However, you can place an ALB or NLB in front of S3 (using S3 as a target) or use CloudFront in front of S3. Global Accelerator endpoints must be ALB, NLB, EC2, or Elastic IP.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but it's not optimal. CloudFront can forward dynamic requests to the origin without caching, but it does not optimize the network path like Global Accelerator. For dynamic API calls, Global Accelerator provides better performance by using the AWS backbone and providing static IPs. However, CloudFront can still be beneficial if you need to add security headers or use Lambda@Edge.
Yes, Global Accelerator supports SSL/TLS termination at the edge by using a custom certificate from AWS Certificate Manager (ACM) or IAM. You can configure HTTPS listeners. CloudFront also supports SSL/TLS termination with custom certificates.
For real-time gaming, UDP is often used for state updates. Global Accelerator supports UDP, while CloudFront does not. Therefore, Global Accelerator is the correct choice. Additionally, Global Accelerator provides static IPs, which are useful for client whitelisting and DDoS protection via AWS Shield.
No, Global Accelerator endpoints must be an Application Load Balancer, Network Load Balancer, EC2 instance, or Elastic IP. To accelerate access to S3, use CloudFront with S3 as an origin, or place a load balancer in front of S3 and use Global Accelerator with that load balancer.
Global Accelerator charges per GB of data processed and per hour for the accelerator (starting at $0.025 per hour). CloudFront charges per GB of data transfer and per request (e.g., $0.085 per GB for US/Europe). Both have regional data transfer rates. Generally, CloudFront is cheaper for static content delivery, while Global Accelerator is more cost-effective for dynamic traffic that requires low latency.
Global Accelerator automatically fails over between endpoint groups based on health checks. You configure endpoint groups per region and set traffic dials (0-100%) to control traffic distribution. If all endpoints in a region are unhealthy, traffic is routed to the next closest region with healthy endpoints. You can also manually adjust traffic dials for blue/green deployments.
Yes, you can place CloudFront in front of Global Accelerator to cache static content while using Global Accelerator's optimized path for dynamic content. However, this adds complexity and cost. A common architecture is to use CloudFront for static assets and Global Accelerator for API endpoints, both pointing to the same origin.
You've just covered AWS Global Accelerator vs CloudFront — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?