Amazon ANS-C01: Content Delivery and Edge Networking — Study Guide
Part of the AWS Advanced Networking Specialty ANS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Core concepts
Content delivery and edge networking separate two related responsibilities: transporting client traffic with low latency and acting as a distributed cache/compute layer near end users. CloudFront is an HTTP(S) CDN and edge compute platform that caches HTTP responses, terminates TLS at the edge, and can run code at edge locations using Lambda@Edge (full Lambda runtime replicated to regions) or CloudFront Functions for lightweight JavaScript at viewer request/response. CloudFront’s behavior is driven by distribution configuration objects created with CreateDistribution and tuned using CachePolicy and OriginRequestPolicy objects. Cache policy fields such as DefaultTTL, MinTTL and MaxTTL and the set of headers, cookies and query strings included in the cache key determine cache hit ratio and origin load. Origin controls include S3 OAC/OAI for private S3 origins (CreateCloudFrontOriginAccessControl) and signed URLs or signed cookies (CreateKeyGroup, CreatePublicKey, and the signed URL signing process) to protect private content.
Global Accelerator and Anycast operate below the HTTP layer. Global Accelerator announces two static anycast IP addresses from the AWS edge network and routes TCP/UDP flows to healthy regional endpoints (Network Load Balancers, Application Load Balancers, EC2 instances, or Elastic IPs). Because Global Accelerator is L3/L4, it preserves end-to-end TLS when configured for TCP pass-through and improves global routing by using the AWS internal backbone for the “last mile” to regional endpoints. For non-HTTP protocols or when true end-to-end encryption and mutual TLS (mTLS) must be preserved between client and backend, a TCP pass-through path using Global Accelerator fronting a Network Load Balancer (NLB) is the canonical pattern: NLBs operate at L4, scale to millions of connections, and can register IP targets for pods or nodes in Amazon EKS.
Lambda@Edge functions are associated with CloudFront behaviors and must be deployed (CreateFunction with Publish) and associated in the distribution’s LambdaFunctionAssociations for viewer-request, origin-request, origin-response and viewer-response triggers. Because Lambda@Edge replicates to multiple edge regions, versions and publishing semantics are important; use versioned Lambda objects and manage deployments carefully to avoid inconsistent behavior during updates.
Key services and configuration
CloudFront distribution configuration relies on three tightly coupled objects: the distribution itself (CreateDistribution / UpdateDistribution), CachePolicy objects that determine the cache key and TTLs (CreateCachePolicy), and OriginRequestPolicy objects that determine which headers/cookies/query strings are sent to the origin (CreateOriginRequestPolicy). For private S3 content use CreateCloudFrontOriginAccessControl or the legacy origin access identity, and protect accesses further with signed URLs / signed cookies using CreateKeyGroup and CreatePublicKey; the SDK or cloudfront-signing utilities generate the signed URL or policy document and RSA signature. Invalidation operations are performed with CreateInvalidation to purge cached objects selectively.
Global Accelerator configuration is created via create-accelerator, create-listener, and create-endpoint-group API calls. The listener can be TCP:443 for gRPC or any TCP port and will forward flows to endpoint groups that point to a regional NLB or ALB. When Global Accelerator is used for TCP pass-through to preserve end-to-end TLS and mTLS, pair it with a Network Load Balancer that has TCP listeners on 443 and target groups that register pod IPs (target type ip) or node ports. In Kubernetes EKS this is typically achieved by creating a Service of type LoadBalancer with annotations such as service.beta.kubernetes.io/aws-load-balancer-type: “nlb” and service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, or by using the AWS Load Balancer Controller to create an NLB with target type ip. Preserve client source IP for logging by setting externalTrafficPolicy: Local on the Service or by using NLB passthrough which keeps the original source IP.
Network-level enforcement between Global Accelerator and regional endpoints uses AWS-managed prefix lists to reduce administrative overhead. The AWS CLI call aws ec2 describe-managed-prefix-lists lists managed prefix lists; the one named com.amazonaws.globalaccelerator can be referenced in security group rules (AuthorizeSecurityGroupIngress with –source-prefix-list) to allow only accelerator-originated traffic to an ALB/NLB. Where ALB terminates TLS, use X-Forwarded-For headers for client IP logging; when using NLB passthrough with Global Accelerator, client IPs are preserved natively and the backends must handle TLS termination/mTLS.
Design patterns and trade-offs
When the requirement is content caching plus edge compute and low-latency HTTP responses, CloudFront is the right tool. CloudFront should terminate TLS at the edge when origin confidentiality is not required; use CachePolicy and OriginRequestPolicy to minimize origin requests by excluding headers and cookies from the cache key where safe. For dynamic personalization that still benefits from caching, use cache key normalization (vary on a minimal set of headers or signed cookies) and design for cache invalidation via versioned object keys rather than frequent CreateInvalidation calls.
For protocols that require end-to-end TLS, HTTP/2 and gRPC flows that must not be decrypted until the backend (for mTLS), put a TCP/L4 path in front using Global Accelerator + NLB with TLS passthrough. The trade-off is losing CloudFront’s HTTP caching and edge compute abilities; however, Global Accelerator gives anycast static IPs, improved routing and regional failover. ALB supports HTTP/2 and gRPC when the ALB terminates TLS, which enables application-layer routing (host/path-based) and WAF integration, but termination at the ALB breaks end-to-end mTLS and places certificate management at the load balancer. For massive concurrent connections, NLBs scale better at L4 — NLBs are optimized for connection rate and preserve source IP, whereas ALBs are designed for HTTP-level routing and features like listener rules for host/path-level routing and integration with Cognito/OIDC.
Security controls and regional isolation patterns require careful selection between shared VPC peering, Transit Gateway, PrivateLink, and Load Balancer endpoints. PrivateLink provides granular service-level access controls and scales well for many consumers because each consumer creates an interface endpoint in their VPC. Transit Gateway is appropriate for high-bandwidth centralization but lacks the per-service granular controls and SNI/host-level visibility that a PrivateLink endpoint provides. Design must consider routing limits, cross-account permissions, and the ability to apply security groups at the service boundary.
Common pitfalls and decision criteria
A frequent error is mixing cache controls incorrectly: letting origin-set Cache-Control headers drive edge caching while CloudFront cache policies also apply can create unexpected TTLs; prefer explicit CachePolicy objects and do not depend solely on origin headers unless deliberate. Another pitfall is selecting ALB when end-to-end TLS or millions of simultaneous TCP connections are needed; ALB-terminated TLS prevents mTLS and can become the bottleneck for very high connection concurrency. Security configurations that attempt to restrict access to an internet-facing ALB often forget to lock down access by using the Global Accelerator prefix list or a WAF rule; without explicit allow rules, the ALB will remain reachable via its public DNS. Finally, Lambda@Edge deployments that do not use versioned Lambda functions can cause inconsistent behavior during rollouts because the association in the distribution ties to a specific published version.
Practical Problem: Use-Case Scenario
Company: AcmeTelemetrics — challenge: global fleet of IoT vending machines uses gRPC over TCP:443 to a backend in us-east-1 running on Amazon EKS; requirement is end-to-end mutual TLS (mTLS) so traffic is never decrypted in transit, support thousands of concurrent connections, and static IPs must be programmed into machines.
Approach:
- Create a Global Accelerator (aws globalaccelerator create-accelerator) with two static anycast IPs and a TCP listener on port 443 (create-listener). Configure an endpoint group that targets a regional Network Load Balancer in us-east-1 (create-endpoint-group).
- Provision an NLB in us-east-1 with TCP listener on 443 and a target group of type ip. In Kubernetes create a Service of type LoadBalancer with annotations service.beta.kubernetes.io/aws-load-balancer-type: “nlb” and service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, set externalTrafficPolicy: Local, and register pod IPs as targets so TLS is passed through directly to pods.
- Deploy the gRPC servers in EKS and terminate TLS/mTLS in the pod processes. Store certificates and trust material in Kubernetes Secrets; configure the server to require client certificate verification for mutual TLS.
- Lock down direct access to the NLB so only Global Accelerator can reach it by updating the NLB’s security group to allow ingress only from the AWS-managed Global Accelerator prefix list (discover via aws ec2 describe-managed-prefix-lists and reference that prefix list in security group rules), preventing machines from bypassing the accelerator and hitting the NLB directly.
- Monitor connection concurrency and scaling by configuring Kubernetes HorizontalPodAutoscaler and Cluster Autoscaler, and ensure the NLB target-group slow start and deregistration delay are tuned for graceful scale-in (modify-target-group-attributes). Use CloudWatch metrics from Global Accelerator, NLB and EKS to watch connection counts and health.
AWS rationale: Global Accelerator provides static anycast IPs required by vending machines and routes TCP flows over the AWS backbone to the regional NLB, improving reliability and latency. NLB preserves the original client TCP connection and source IP and supports massive concurrent connections, enabling pods to perform mTLS termination without intermediate TLS termination. Using the Global Accelerator managed prefix list in security group rules prevents direct bypass of the accelerator and enforces that traffic arrives only via the anycast IPs. This combination satisfies end-to-end encryption, mTLS, large concurrency, static IPs, and autoscaling in EKS.
← Network Security and Compliance · All domains · Network Performance and Monitoring →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →