Study ANS-C01 edge network services for CloudFront, Global Accelerator, Route 53, WAF, Shield, public entry design, and global traffic traps.
Edge-networking questions on ANS-C01 are about the first controlled AWS decision point that public users touch. The exam is not merely asking whether you recognize Amazon CloudFront, AWS Global Accelerator, Amazon Route 53, AWS WAF, or AWS Shield. It is asking whether you can put the correct service at the correct layer of the public-entry path.
The current AWS task statement for this objective is to design a solution that incorporates edge network services to optimize user performance and traffic management for global architectures. That wording matters: performance, traffic management, failover, protocol fit, security controls, and operational visibility are all part of the same design.
Most edge stems contain several familiar AWS names. Strong ANS-C01 answers separate these roles before choosing:
| Role in the edge path | Strong first fit | What it controls |
|---|---|---|
| DNS name resolution and routing policy | Route 53 | Which name returns which answer, based on policy and health checks |
| HTTP or HTTPS edge delivery | CloudFront | Caching, TLS termination, HTTP behavior, origin selection, and edge security integrations |
| Static anycast entry and optimized path to regional endpoints | Global Accelerator | Network-layer entry, health-based regional endpoint routing, and faster failover than DNS-only designs |
| Layer 7 web protection | AWS WAF | HTTP request filtering and managed/custom web rules |
| DDoS-aware protection for supported resources | Shield Advanced | Enhanced DDoS detection, mitigation, visibility, and response support |
| Application entry after the edge | ALB, NLB, API Gateway, or another origin | Regional traffic handling after the global edge decision |
If the prompt says “global users,” do not jump straight to a service. First decide whether the problem is DNS steering, HTTP delivery, static anycast entry, security filtering, regional failover, or origin protection.
| Requirement in the stem | Prefer | Why |
|---|---|---|
| Cacheable web content, static assets, downloadable files, or origin offload | CloudFront | The point is HTTP edge delivery and cache behavior |
| Dynamic HTTP application needs edge TLS, WAF, origin controls, or multiple origins | CloudFront | CloudFront is still useful even when not every response is cacheable |
| TCP or UDP application needs static global IPs and fast regional failover | Global Accelerator | The point is network entry and health-based routing, not CDN behavior |
| HTTP API needs global performance but responses must not be cached | CloudFront with caching disabled or controlled by policy | The point may be edge TLS, WAF, and origin routing rather than object caching |
| Users need a friendly DNS name and routing policies | Route 53 | DNS decides name answers, not packet forwarding after the client connects |
| Public HTTP app needs request filtering | AWS WAF on CloudFront or the regional entry point | WAF handles web-layer filtering, not generic routing |
| Public endpoint is DDoS-sensitive and business-critical | Shield Advanced on supported resources | Shield Advanced is a protection and response layer, not a traffic router |
Use this model to avoid mixing DNS, edge, protection, and regional entry into one vague “global service” answer.
flowchart LR
U["Global users"] --> D["Route 53 DNS answer"]
D --> E["CloudFront or Global Accelerator"]
E --> P["WAF / Shield controls when applicable"]
P --> R["Regional entry: ALB, NLB, API Gateway, or origin"]
R --> A["Application and data tier"]
The exam may collapse this into one sentence. Your job is to expand the path mentally and ask which hop is actually failing or being optimized.
This is the most common edge trap.
| Question clue | CloudFront is stronger when… | Global Accelerator is stronger when… |
|---|---|---|
| Protocol | The workload is HTTP or HTTPS and benefits from edge HTTP behavior | The workload is TCP or UDP and needs global network entry |
| IP address requirement | DNS name is acceptable | Static anycast IP addresses are required |
| Caching | Cache behavior, cache key, TTL, invalidation, or origin offload matters | Caching is irrelevant or unsupported |
| Failover | Origin failover is framed around HTTP delivery or origin groups | Endpoint health and fast regional traffic shift are central |
| Security integration | WAF at the edge is a major clue | DDoS-aware static entry or regional endpoint routing is the clue |
| Typical endpoints | S3, ALB, API Gateway, custom HTTP origins, media origins | ALB, NLB, EC2 instances, Elastic IP addresses, or custom routing patterns |
CloudFront is not “static website only.” It can front dynamic HTTP origins too. But if the requirement is a non-HTTP protocol, static global IPs, or network-layer failover to regional endpoints, Global Accelerator is usually the better first answer.
Route 53 can be a strong part of the answer when the issue is name resolution, routing policy, latency-based answers, failover records, weighted rollout, private hosted zones, or hybrid DNS. It is weak when the requirement is to improve the live network path after the client has already resolved a name.
Route 53 decisions are DNS decisions. They are affected by resolver behavior, TTLs, cached answers, and health checks. Global Accelerator decisions are made at the AWS edge after the client connects to the accelerator IPs. CloudFront decisions are HTTP edge-delivery decisions after the viewer reaches the distribution.
That distinction is often enough to eliminate two plausible answers.
ANS-C01 expects you to think about protection placement, not just service names.
| Threat or control need | Stronger placement |
|---|---|
| HTTP request filtering, bot patterns, managed web rules, URI/header logic | AWS WAF associated with CloudFront or the regional web entry |
| DDoS protection for a public application using CloudFront, Route 53, Global Accelerator, ALB, or Elastic IPs | Shield Advanced on supported resources |
| Origin should not be directly reachable from the internet | Restrict origin access to the edge path, not just “add WAF” |
| Need forensic and operational evidence | CloudFront logs, WAF logs, Shield events, Route 53 health checks, load balancer metrics, and VPC Flow Logs where relevant |
Security answers are weaker when they protect the backend but leave a direct public bypass around the intended edge entry point.
| Architecture | Why it appears on ANS-C01 | Watch for |
|---|---|---|
| Route 53 to CloudFront to ALB | Global HTTP entry with edge controls and regional web routing | Origin exposure, cache key design, WAF placement, TLS, and health behavior |
| Route 53 to Global Accelerator to ALB or NLB | Static anycast entry with regional endpoint health and optimized AWS backbone path | Protocol fit, endpoint health, traffic dials, and client IP requirements |
| CloudFront to S3 origin | Static or cacheable content delivery | Origin access control, bucket public access, TTLs, invalidation, and signed access |
| CloudFront to API Gateway or ALB | Dynamic HTTP delivery with edge security | Cache disabled or selective caching, header/cookie/query forwarding, and WAF scope |
| Route 53 failover records to regional endpoints | DNS-level failover | TTL, resolver caching, health-check design, and whether DNS-only failover is fast enough |
Edge questions often hide the answer inside a failure condition.
| Symptom | First technical suspicion | Strong next thought |
|---|---|---|
| Global HTTP users have high latency and repeated origin load | Missing or poor CloudFront design | Check cache policy, origin request policy, TTLs, and origin placement |
| TCP application fails over too slowly during regional impairment | DNS-only failover may be too slow | Consider Global Accelerator with healthy regional endpoints |
| WAF rules are configured but origin can still be reached directly | Edge path can be bypassed | Restrict origin access and verify the intended entry path |
| Some users still reach an unhealthy region | Resolver caching or DNS TTL may be involved | Distinguish DNS failover from edge health-based routing |
| Static global IPs are required for allow lists | CloudFront DNS name may not satisfy the requirement | Consider Global Accelerator |
| Stem clue | Eliminate first | Keep in play |
|---|---|---|
| “cacheable content” or “reduce origin requests” | Global Accelerator as a CDN substitute | CloudFront |
| “TCP/UDP” plus “static anycast IPs” | CloudFront as the main service | Global Accelerator |
| “friendly domain name” only | Global Accelerator as mandatory | Route 53 |
| “web request filtering” | Security group as the only HTTP control | AWS WAF |
| “DDoS cost protection and response support” | WAF alone | Shield Advanced, plus WAF when HTTP filtering is also needed |
| “DNS answers must differ by policy” | CloudFront cache behavior | Route 53 routing policy |
| “origin must not be public” | Only adding edge caching | Origin access restrictions and network controls |
A company runs a latency-sensitive TCP application in two AWS Regions. Clients connect from many countries, and partner firewalls require a small set of static public IP addresses. The company also wants traffic to move away from unhealthy regional endpoints quickly. Which design is strongest?
Answer: Use Global Accelerator.
Why: The clues are TCP, static public IPs, global users, and fast regional endpoint failover. CloudFront is the wrong layer because the workload is not HTTP edge delivery. Route 53 can participate in naming, but DNS-only routing is weaker when fast health-based traffic movement and static anycast IPs are central. WAF is an HTTP request-filtering control and does not solve the TCP entry requirement.
When the scenario says HTTP delivery, cache behavior, WAF at the edge, or origin offload, start with CloudFront. When it says TCP/UDP, static anycast IPs, or fast regional endpoint failover, start with Global Accelerator. When it says routing policy for names, start with Route 53. When it says web request filtering, add WAF. When it says DDoS protection for supported public resources, evaluate Shield Advanced.
Continue with 1.2 DNS, Service Discovery, and Resiliency to handle name resolution, Resolver, routing policies, and hybrid DNS behavior.