Cargando...
Cargando...
Cache it or accelerate it — know exactly which AWS edge service to reach for and why
CloudFront caches content at the edge; Global Accelerator routes TCP/UDP traffic over the AWS backbone
| Feature | CloudFront CDN that caches and delivers content | Global Accelerator Network accelerator for TCP/UDP traffic |
|---|---|---|
Primary Purpose This is the #1 distinction. CloudFront = Layer 7 (HTTP/HTTPS) caching CDN. Global Accelerator = Layer 3/4 (TCP/UDP) network routing accelerator. If the question mentions caching, it's CloudFront. | Content Delivery Network (CDN) — caches and distributes static/dynamic web content at edge locations worldwide | Network-layer traffic accelerator — routes TCP/UDP packets over the AWS global backbone network to optimal regional endpoints |
OSI Layer Global Accelerator is protocol-agnostic at Layer 4 — it can accelerate non-HTTP workloads like gaming (UDP), IoT, VoIP. CloudFront cannot. | Layer 7 (Application Layer) — understands HTTP, HTTPS, cookies, headers, query strings | Layer 3 / Layer 4 (Network/Transport Layer) — works with TCP and UDP at the IP level |
Caching Capability CRITICAL TRAP: If a scenario asks for reduced origin load or faster delivery of static assets, CloudFront wins. Global Accelerator NEVER reduces origin calls. | YES — full caching at 600+ edge locations. Configurable TTLs, cache behaviors, cache policies, origin shield | NO — zero caching. Every request is proxied through to the origin. It only optimizes the network path. |
IP Address Type CRITICAL: If the exam scenario mentions 'static IP', 'IP whitelisting by clients', 'firewall rules requiring fixed IPs', or 'non-HTTP protocol' — the answer is Global Accelerator, not CloudFront. | Dynamic IPs — CloudFront edge locations use a large, rotating pool of IP addresses. Not suitable for IP whitelisting by clients | Static Anycast IPs — provides exactly 2 static IPv4 addresses (Anycast) per accelerator that never change |
Anycast Routing Anycast means the same IP is announced from multiple locations — the internet routes to the closest one automatically. No DNS TTL delays with Global Accelerator. | No traditional Anycast — uses DNS-based routing (GeoDNS) to direct users to nearest edge POP | YES — true Anycast. Both static IPs are advertised from all AWS edge locations simultaneously; traffic enters the AWS network at the nearest POP |
Protocols Supported Gaming servers (UDP), real-time IoT, custom TCP protocols = Global Accelerator. Web apps, APIs, streaming = CloudFront. | HTTP, HTTPS, WebSocket (limited support), HTTP/2, HTTP/3 (QUIC) | TCP, UDP — any application running over these protocols (HTTP, HTTPS, gaming, VoIP, custom protocols) |
Failover / Health Checks Global Accelerator's failover is faster and more granular — it monitors endpoint health and can shift traffic between regions, AZs, or individual EC2/ALB/NLB endpoints. | Origin failover via origin groups — primary/secondary origins. Failover triggered on HTTP 5xx errors or timeout | Built-in health checks with near-instant failover (under 30 seconds) across regions. Traffic automatically rerouted to healthy endpoints |
Traffic Distribution / Weighted Routing Traffic dials in Global Accelerator are powerful for migrations and A/B testing at the network level without DNS changes. | No native weighted routing between origins (use Route 53 weighted records behind CloudFront for this) | YES — traffic dials (0–100%) per endpoint group allow weighted routing for blue/green deployments, canary releases, or gradual migrations |
DDoS Protection For WAF integration and Layer 7 DDoS mitigation (application-level threats), CloudFront is the answer. Global Accelerator protects at the network layer only. | AWS Shield Standard included (free). AWS Shield Advanced available. WAF integration for Layer 7 protection (SQL injection, XSS, rate limiting) | AWS Shield Standard included (free). AWS Shield Advanced available. No WAF integration — operates at Layer 3/4 only |
WAF Integration Any scenario requiring WAF rules, bot protection, or HTTP-level filtering at the edge = CloudFront. | YES — AWS WAF fully integrated. Can block IPs, filter HTTP headers, rate-limit, use managed rule groups | NO — WAF cannot be attached to Global Accelerator directly. WAF must be placed on the downstream ALB/CloudFront |
Lambda@Edge / CloudFront Functions Edge compute (URL rewrites, A/B testing, auth at edge, header manipulation) = CloudFront + Lambda@Edge or CloudFront Functions. Global Accelerator has zero compute capability. | YES — Lambda@Edge (Node.js/Python, up to 5s timeout on origin-facing events) and CloudFront Functions (JS, sub-millisecond, viewer-facing only). Run code at edge locations | NO — no compute at the edge. It is purely a network routing service. |
Origin Types Supported S3 as a direct origin = CloudFront only. Global Accelerator cannot front S3 directly. | S3 buckets, ALB, NLB, EC2, API Gateway, MediaPackage, any public HTTP/HTTPS endpoint, custom origins | ALB, NLB, EC2 instances (Elastic IPs), and other Global Accelerator accelerators. Does NOT support S3 directly. |
Geographic Restrictions (Geo-blocking) Content licensing, GDPR country-level blocking, regional compliance = CloudFront geo-restriction. | YES — native geo-restriction by country (allowlist or denylist). Can also use Lambda@Edge for more granular control | NO — no native geo-restriction capability |
HTTPS / SSL/TLS Termination CloudFront offloads TLS handshake to the edge, reducing latency and origin CPU. Global Accelerator passes TLS end-to-end — the origin must handle it. | TLS terminated at the edge POP. Supports SNI, custom SSL certificates via ACM, legacy dedicated IP SSL (additional cost). Viewer and origin protocols independently configurable | TLS is NOT terminated at the edge — it passes through to the origin endpoint (ALB/NLB). The endpoint handles TLS termination. |
Custom Domain / CNAME Both support custom domains, but the mechanism differs. CloudFront uses CNAME aliasing; Global Accelerator clients typically use the static IPs for whitelisting. | YES — alternate domain names (CNAMEs) fully supported with ACM certificates | YES — supports custom DNS names, but clients connect via the 2 static Anycast IPs or a provided DNS name (e.g., xxxxxxxx.awsglobalaccelerator.com) |
Pricing Model Global Accelerator has a fixed hourly cost regardless of traffic — it's more expensive for low-traffic workloads. CloudFront has a free tier. For high-volume static content, CloudFront is almost always cheaper. | Pay for: (1) Data transfer out to internet (per GB, tiered by region), (2) HTTP/HTTPS requests (per 10,000), (3) Invalidation requests (first 1,000 paths/month free), (4) Lambda@Edge/CloudFront Functions invocations. Free tier: 1 TB data transfer + 10M requests/month for 12 months | Pay for: (1) Fixed hourly charge per accelerator (~$0.025/hr per accelerator = ~$18/month), (2) Data transfer premium (DT-Premium) — a per-GB surcharge on top of standard data transfer rates, varying by source/destination region. No free tier. |
Use Case: Static Website / S3 S3 static website + CDN = CloudFront, always. | IDEAL — cache S3 objects at edge, OAC/OAI for private S3, custom error pages, compression, HTTPS for S3 static sites | NOT SUITABLE — cannot front S3 directly, no caching benefit |
Use Case: Gaming / Real-time UDP Any exam question about online gaming, real-time UDP, or non-HTTP protocol acceleration = Global Accelerator. | NOT SUITABLE — HTTP/HTTPS only | IDEAL — accelerates UDP traffic over AWS backbone, reduces jitter and packet loss for gaming servers |
Use Case: Multi-Region Active-Active Multi-region active-active with automatic failover and traffic splitting = Global Accelerator. | Possible but limited — origin failover via origin groups, not designed for active-active multi-region load balancing | IDEAL — distribute traffic across multiple regions with endpoint groups, traffic dials, and health-based routing |
Use Case: API Acceleration Cacheable API = CloudFront. Non-cacheable dynamic API needing global low-latency = Global Accelerator. Both are valid — context determines the winner. | Good for cacheable API responses. Can cache GET responses, use Lambda@Edge for auth. Not ideal for non-cacheable, stateful APIs | Good for non-cacheable, dynamic API traffic that benefits from backbone routing without caching |
Number of Edge Locations CloudFront has a much larger edge footprint optimized for caching. Global Accelerator uses AWS edge network nodes as entry points to the backbone. | 600+ Points of Presence (POPs) including edge locations and regional edge caches worldwide | Uses the same AWS global network edge infrastructure (100+ cities in 50+ countries) but the count is not the same as CloudFront POPs |
Data Transfer Rate Quota The 150 Gbps CloudFront limit is from the official AWS docs (2026). Note: This quota does NOT apply to distributions subscribed to CloudFront flat-rate pricing plans. | 150 Gbps per distribution (default, can be increased via Service Quotas or AWS Support) | Not specified as a hard per-accelerator limit in the same way — refer to AWS documentation for current quotas |
Requests Per Second Quota Both services have soft limits that can be increased. Always check Service Quotas console for current values rather than relying on memorized numbers. | Per-distribution RPS limit exists (check Service Quotas console for current value — can be increased) | Per-accelerator connection limits apply — consult AWS Service Quotas console for current values |
Shield Advanced Integration Both integrate with Shield Advanced. For comprehensive protection (L3-L7), combine Global Accelerator + CloudFront + WAF + Shield Advanced. | YES — Shield Advanced provides enhanced DDoS protection, cost protection, 24/7 DRT access, and real-time attack visibility | YES — Shield Advanced supported. Provides network-layer DDoS protection for the accelerator endpoints |
IPv6 Support Both support IPv6. Not a common differentiator on exams. | YES — supports IPv6 for viewer connections (can be enabled per distribution) | YES — supports dual-stack (IPv4 and IPv6) endpoints |
Monitoring & Observability CloudFront's cache hit ratio metric is unique and important — it tells you how effectively your caching is working. No equivalent in Global Accelerator. | CloudWatch metrics (requests, bytes, error rates, cache hit ratio), access logs to S3, real-time logs to Kinesis Data Streams, CloudFront console reports | CloudWatch metrics (new flows, processed bytes, healthy endpoint count), flow logs to S3 or CloudWatch Logs |
Invalidation Cache invalidation is a CloudFront-only concept. Invalidation does NOT delete objects from S3 — it only removes them from CloudFront's cache. | YES — invalidate cached objects by path (wildcard supported). First 1,000 invalidation paths per month are free; additional paths charged per path | NOT APPLICABLE — no caching means no invalidation needed |
Summary
Use CloudFront when you need to cache and deliver HTTP/HTTPS content (static files, web pages, APIs, video) at scale with edge compute capabilities, WAF integration, and cost-effective global distribution. Use Global Accelerator when you need static Anycast IPs, sub-30-second multi-region failover, non-HTTP protocol support (TCP/UDP), or network-level acceleration for dynamic/non-cacheable workloads. The services are complementary — Global Accelerator can sit in front of CloudFront for static IP requirements while still leveraging CloudFront's caching.
🎯 Decision Tree
Does the workload use HTTP/HTTPS AND benefit from caching? → CloudFront. Does the client require static/fixed IP addresses for whitelisting? → Global Accelerator. Is the protocol non-HTTP (UDP, custom TCP, gaming)? → Global Accelerator. Need WAF or Lambda@Edge at the edge? → CloudFront. Need sub-30s multi-region failover with traffic dials? → Global Accelerator. Need to front an S3 bucket directly? → CloudFront. Need both static IPs AND caching? → Global Accelerator in front of CloudFront.
Static IP requirement = Global Accelerator. CloudFront uses dynamic IPs — you cannot whitelist CloudFront by IP on a firewall. Any scenario mentioning 'fixed IP', 'static IP', 'IP whitelisting', or 'firewall rules' for a globally distributed application points to Global Accelerator. This is the #1 differentiator tested across all cert levels.
Caching = CloudFront, NEVER Global Accelerator. Global Accelerator has zero caching capability — every request hits the origin. If a scenario asks how to reduce origin load, improve cache hit ratio, serve static assets faster, or lower origin costs through caching, the answer is CloudFront. Global Accelerator only optimizes the network path.
Non-HTTP protocols (UDP, gaming, VoIP, IoT) = Global Accelerator. CloudFront only supports HTTP/HTTPS/WebSocket. Any scenario involving UDP traffic, online gaming servers, real-time applications using custom TCP/UDP protocols, or 'protocol-agnostic' global acceleration = Global Accelerator. This is frequently tested on SAA-C03 and SAP-C02.
WAF can ONLY attach to CloudFront (at edge), ALB, API Gateway, or AppSync — NOT directly to Global Accelerator. If a scenario requires WAF rules at the global edge, the answer involves CloudFront. If you need both static IPs AND WAF, architect Global Accelerator → CloudFront → WAF → ALB.
Multi-region active-active with fast failover = Global Accelerator. Route 53 health checks + failover routing can achieve multi-region failover, but Global Accelerator's Anycast routing + health checks provide sub-30-second failover without DNS TTL delays. On SAA-C03/SAP-C02, when the scenario emphasizes 'fast failover' and 'multi-region', Global Accelerator beats Route 53 failover routing.
CloudFront Functions vs Lambda@Edge: CloudFront Functions run at viewer events only (viewer request/response), are JavaScript-only, have sub-millisecond execution, and are much cheaper. Lambda@Edge supports all 4 event types (viewer + origin request/response), supports Node.js and Python, allows up to 30s timeout on origin events, and can make network calls. Match the requirement to the right tool.
Cost trap: Global Accelerator charges a fixed hourly fee (~$0.025/hr) PLUS a data transfer premium on top of normal data transfer costs. CloudFront has a free tier (1 TB + 10M requests/month for 12 months) and no fixed baseline cost. For cost-optimization questions, CloudFront is almost always cheaper for HTTP workloads.
The #1 exam trap: A scenario describes a globally distributed application that needs 'faster performance worldwide' and asks you to choose between CloudFront and Global Accelerator. Candidates incorrectly choose CloudFront for ALL such scenarios. The correct approach: if the content is cacheable HTTP/HTTPS → CloudFront; if the requirement mentions static IPs, non-HTTP protocols, or dynamic non-cacheable traffic with multi-region failover → Global Accelerator. Many candidates also incorrectly believe Global Accelerator can front S3 directly or that CloudFront provides static IPs for firewall whitelisting — both are false.
CertAI Tutor · CLF-C02, SAP-C02, SAA-C03, DVA-C02, DEA-C01, DOP-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns