If you build for a global audience on AWS, the edge usually comes down to three services: CloudFront, Global Accelerator, and Route 53. Each sits at a different layer in the path from a user to your workload. The right mix improves first-byte time, cache hit ratio, and failover behavior. The wrong mix leads to stale DNS answers, slow origins, or sticky sessions that do not stay sticky.
Quick comparison at a glance
What each service actually does
Route 53 — the switchboard
Route 53 answers for your domains and applies routing policies such as latency, geolocation, geoproximity, weighted, and failover. Health checks guide those policies. Because resolvers cache answers, TTL settings shape how quickly changes are observed. Alias records let you point the zone apex or subdomains at AWS resources like CloudFront or an Application Load Balancer without managing IPs.
CloudFront — the application edge
CloudFront terminates viewers at the edge and proxies to your origins. It handles HTTP/1.1, HTTP/2, and HTTP/3, plus WebSocket and gRPC. Use AWS WAF for Layer 7 rules, Origin Access Control to keep S3 private, and Origin Shield to reduce origin load.
CloudFront supports origin failover for GET and HEAD. POST and gRPC do not participate in that mechanism. A 2025-era option is the ability to request Anycast static IPs for a distribution, including a three-IP set to point to an apex domain via A records. This has prerequisites such as IPv6 off and selecting all edge locations.
Global Accelerator — the network fast lane
Global Accelerator allocates two Anycast static IPs that anchor your public entry point. It routes packets over the AWS backbone to the nearest healthy Regional endpoint such as ALB, NLB, EC2, or an Elastic IP. You can steer exposure with traffic dials per Region, balance with endpoint weights, and keep flows sticky with client affinity. CloudFront is not a Global Accelerator endpoint type, so route with different hostnames when you need both.
When to pick what
How they fit together
For a content-heavy single-Region app, keep the zone in Route 53 and point www to CloudFront with an alias. CloudFront handles caching for assets, proxies dynamic paths, attaches WAF rules at the edge, and keeps S3 private with Origin Access Control. In this pattern, Global Accelerator is usually not required.
For a low-latency multi-Region API, place Global Accelerator in front of two Regional ALBs. Route 53 still publishes the names. Global Accelerator provides client affinity for stateful flows and lets you shift exposure gradually using traffic dials or endpoint weights. CloudFront can continue to serve the site’s static front end, while the API front door is Global Accelerator.
For a mixed stack with a website and real-time sockets or custom TCP or UDP, split by hostname in Route 53. Send the website and HTTP APIs to CloudFront, and send the real-time or non-HTTP service to Global Accelerator. This keeps protocols clean and lets each edge layer do the job well.
Static IPs and allowlists
When you need fixed Anycast IPs for a non-HTTP workload, Global Accelerator is the straightforward choice. Every accelerator exposes two static IPs by default, and BYOIP is available for tighter control. If the need is strictly for HTTP and you want fixed IPs or apex A records to CloudFront, request CloudFront Anycast static IPs and follow the prerequisites such as turning off IPv6 and selecting all edge locations. Use this only when a partner allowlist or apex mapping truly requires it.
Resilience, failover, and health checks
Cost signals you will feel
Route 53 is a control-plane cost made up of hosted zones, queries, and optional health checks. Keep TTLs short only when failover speed justifies the extra queries. CloudFront charges for data out and requests, with the option to add WAF at the edge. Solid caching and Origin Shield usually reduce origin egress and compute. Global Accelerator adds a steady hourly fee per accelerator plus Data Transfer-Premium for bytes that traverse the backbone, in addition to normal Regional egress, so plan for it on dynamic paths.
Setup snapshot
In Route 53, create records with policies that reflect recovery targets and choose TTLs that resolvers will refresh in time. Use alias records to target CloudFront or an Elastic Load Balancer.
In CloudFront, turn on HTTP/2 and HTTP/3, attach WAF, move S3 origins to Origin Access Control, place Origin Shield near the origin, and configure origin groups for GET and HEAD. In Global Accelerator, register Regional endpoints, set endpoint weights for controlled cutovers, adjust traffic dials for Region exposure, and turn on client affinity when sessions need stickiness.
Common gotchas
DNS failover is not instant because resolvers cache answers based on TTL. Shorten TTLs only if the extra query load is acceptable. Global Accelerator cannot front a CloudFront distribution. When you need both, route different hostnames with Route 53.
CloudFront does not fail over POST requests or gRPC streams. Use Route 53 policies or Global Accelerator for resilience on those paths. If your origin requires the client IP, validate what the backend expects. Global Accelerator can preserve it at Layer 4, while CloudFront forwards it in headers.
FAQ
Can Global Accelerator sit in front of CloudFront? No. Global Accelerator supports ALB, NLB, EC2, and Elastic IPs as endpoints. Use Route 53 to send one hostname to CloudFront and another to Global Accelerator.
Does CloudFront support WebSocket and gRPC? Yes. WebSocket works end to end. gRPC runs over HTTP/2, but it does not participate in CloudFront’s origin failover and bypasses mid-tier cache features.
Do I still need Route 53 when using CloudFront? Yes. Route 53 remains the source of truth for zones and policies. If you want apex A records to CloudFront, request Anycast static IPs and meet the prerequisites.
Will CloudFront fail over my POST API or a gRPC stream? No. Origin failover applies to GET and HEAD. For APIs that use POST or gRPC, handle resilience with Route 53 or Global Accelerator.
The T²C view
Across platform and product work, the simplest pattern holds up: use CloudFront for anything user-facing on HTTP, use Global Accelerator for stateful or non-HTTP flows and for strict IP needs, and keep Route 53 as the policy brain with health checks you can rehearse. That mix keeps latency low, failovers predictable, and costs under control without surprises during incident drills.
Top comments (0)